auctex-devel
[Top][All Lists]
Advanced

[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
<URL:http://savannah.gnu.org/cgi-bin/viewcvs/auctex/auctex/tex-buf.el.diff?r1=1.225&r2=1.226>?
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'
argument.

> 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
present.

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
set.

> 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.

-- 
Ralf




reply via email to

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