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 12:57:11 +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:
>>
>>> * 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.


You don't.  Insert environments is a submenu.  Only selecting this
submenu would ask the question.

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

Nonsense.  It asks information when it requires it.  Apart from which
people are perfectly fine with indeterministic applications, or
Windows would not have a market share of 90%.

This has been the behavior for AUCTeX from ancient history to 11.13 or
so, and nobody complained worth noting.

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

More or less.  This might possibly be done by automatic extraction,
like with autoloads.


> First, this will unnecessarily blow up the regexps for searching and
> slow down font locking even further.

The current slow down of font locking is not because we have too many
keywords, but because there are bugs at the moment.  font locking can
perfectly well support a large number of keywords, as a number of
other modes demonstrate.

And the right way of dealing with those bugs is not by crippling the
font locking until the bugs become nonobvious.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

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