auctex-devel
[Top][All Lists]
Advanced

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

Re: [AUCTeX-devel] multi-file support


From: David Kastrup
Subject: Re: [AUCTeX-devel] multi-file support
Date: Fri, 06 May 2005 11:02:48 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Ralf Angeli <address@hidden> writes:

> * David Kastrup (2005-05-06) writes:
>
>> Ralf Angeli <address@hidden> writes:
>>
>>> This would mean to revert to the behavior or pre-11.5x AUCTeX
>>> versions where the master file question popped up in quite random
>>> situations, e.g. when you clicked on a menu.  Not good.
>>
>> Uh, disagree.  The problem was not that the master file question
>> popped up when clicking on a menu (like "insert environment"):
>> that's exactly when the question needs to get resolved.
>
> Technically, yes.  But from a user's point of view it is likely to
> appear like a random point in time.

Disagree.

> I don't think that everybody will be able to associate the qestion
> popping up with the necessary update of the environment menus.

So what.

>> The problem was that we were not able to find code that did not
>> either break under Windows or XEmacs or some other circumstances.
>> Asking questions before opening a menu generated based on the
>> answer of those questions simply was not possible to do on the
>> current set of Emacsen we have chosen to support.  Maybe it helps a
>> bit that we have by now kissed 20.7 goodbye.
>
> Well, I rewrote the whole dynamic menu stuff which now uses proper
> menu filters.  So this might have improved the situation as well.

It was exactly with menu filters that the thing broke.  Ok, part of
the problem might have been that the filter routine changed the menus
itself.

> But the approach via the menu is flawed.  You can insert
> environments without clicking the menu.

Well, so what?  Then you got the question on the command line, at
least when you were using completion.

> So we'd need a more general scheme for detecting when the relevant
> styles have to be loaded, i.e. the master file question be asked.

This more or less worked in 11.13, except on some platforms, and only
by using awful code.  The scheme is not old.

> AFAICS we have two reasonable possibilities: (1) Ask the question
> when the file is being loaded or (2) when an event happens which
> requires all relevant styles to be loaded.  While I already
> expressed my concerns about alternative 2 above, alternative 1 has
> drawbacks as well, like the user being asked about the master file
> if she only wants to have a look at it without editing.

Yes.

> But there is no way avoiding this if we consider font locking which
> requires all relevant styles to be loaded even if you only want to
> look at the file in order to get fontification right.

Is there stuff that really requires the dynamic detection and can't be
hardcoded?

>> If it had been possible to get this working reasonably at the time
>> we tried it, then we could have introduced an extra value
>> ask-only-if-new for the current behavior without losing the old
>> behavior: while Reiner likes ask-only-if-new better, it is quite
>> problematic for a number of cases, and so making this a user
>> preference instead eat-or-die would be very much desirable.
>
> A change in `VirTeX-common-initialization' could make this possible
> as well.  But this will not restore the old behavior.  Instead the
> question will be asked on load.

And that is not good.  In particular since answering the question
implies changing the file.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

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