[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AUCTeX-devel] Re: multi-file support

From: Ralf Angeli
Subject: Re: [AUCTeX-devel] Re: multi-file support
Date: Sun, 15 May 2005 11:42:42 +0200
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)

* David Kastrup (2005-05-14) writes:

> Ralf Angeli <address@hidden> writes:
>> That's too drastic.  My suggestion would be to include the file name
>> in the prompt for the master file in case the buffer is not visible.
> I disagree, actually, as you can see by the code I placed in
> tex-buf.el for error handling.

Which code?  The one in
It would be nice if you were more specific.  This way you could spare
people some of their little time.

> When a file gets loaded as part of
> processing a run on a known master file, its TeX-master variable
> should _silently_ get set to the known value (no local variable
> section hacking done).

How do you suppress processing the local variables specifications?
AFAICS there is no way of telling `find-file-noselect' such a thing.
It will call `after-find-file' with a nil value of the `nomodes'

> If the session already has different means to provide consistent
> information for the currently loaded files, we should make use of
> them.

In case of the question for shared files I need a way to distinguish
the file being opened by hand and programmatically in course of
document processing.  Functions opening files during processing could
temporarily set a variable for the master file (named
e.g. `TeX-transient-master' or `TeX-session-master') the presence of
which will be tested in `TeX-master-file' and used for `TeX-master' if

In the case of shared files being opened during a `preview-document'
call, the function `preview-parse-messages' may open files
programmatically.  That means somewhere down the line from
`preview-document' to that point a transient master would have to be

> Of course, I have not actually announced this general strategy at all,
> so I can hardly fault you for presenting a different strategy, one
> that we previously agreed on.

That's okay.  I am always grateful if somebody suggests a solution
more convenient or beneficial for the user.  You are right that it
would be foolish to prompt the user for information we can deduct from
a processing session.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]