[Top][All Lists]

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

Re: [AUCTeX-devel] multi-file support

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

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

> Ralf Angeli <address@hidden> writes:
>> * David Kastrup (2005-05-06) writes:
>>> 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.

It's odd that you get asked for the master file if you use the menu
only for getting access to the documentation, for example.  Opening
the menu does not necessarily mean you want to change the file.

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

Well, it lets the application appear indeterministic.

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

I stand corrected.  I didn't know that `TeX-update-style' is called in
that situation.  Thanks for pointing me to it.

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

You mean by moving all the keywords for font locking defined in style
files into font-latex.el?  First, this will unnecessarily blow up the
regexps for searching and slow down font locking even further.
Second, this will make it harder to implement a unified scheme for
adding keywords for insertion, font locking, folding etc.  Thus, I am
not really in favor of such a solution.


reply via email to

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