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: David Kastrup
Subject: Re: [AUCTeX-devel] Re: multi-file support
Date: Sat, 14 May 2005 21:46:59 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Ralf Angeli <address@hidden> writes:

> * Richard Lewis (2005-05-13) writes:
>
>> (Also, if you open just a master file and generate previews for the
>> whole document, the slave files are opened and you get asked for the
>> master file for each slave)
> [...]
>> As a workaround, how about forcing the buffer to be visible when the
>> question gets asked:
>>
>> --- tex.el   09 May 2005 16:27:10 +0100      5.512
>> +++ tex.el   13 May 2005 16:39:18 +0100      
>> @@ -1240,6 +1240,7 @@
>>  
>>       ;; For files shared between many documents.
>>       ((and (eq 'shared TeX-master) ask)
>> +      (pop-to-buffer (current-buffer))
>>        (setq TeX-master
>>              (TeX-strip-extension
>>               (let ((default (or (TeX-dwim-master) "this file")))
>
> 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.  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).  The TeX-master is a property of the editing
session more than of the actual file: we ask the question only when we
could not sensibly continue, not because we are eager to imprint each
file with that information.  And once we ask it, we record it so that
we need not ask again in the same situation.

The changes in tex-buf.el were inserted by me since it was simply
impossible to sensibly work with a 20-file document generated outside
of AUCTeX: all the time wrong buffers popped up, completely redundant
questions got asked, the wrong directories were chosen, non-existing
log files reverted and so on.

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

The alternatives are too much of a nuisance.

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.

But really, it is too painful to be useful.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

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