[Top][All Lists]

[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 15:24:44 +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:
>>> 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.
> If you want to reach menu entries below the environment submenus you
> will normally move the mouse pointer from the top of the menu
> downwards and thereby open the environment submenus (especially if you
> are using a toolkit which does not have a delay on opening
> submenus).

This inconvenience is a problem of the toolkit.

>>> Well, it lets the application appear indeterministic.
>> Nonsense.  It asks information when it requires it.
> Look, I am arguing from a user's point of view, not from an
> application's point of view.
>> This has been the behavior for AUCTeX from ancient history to 11.13 or
>> so, and nobody complained worth noting.
> Not an argument.

Decide yourself.  If you are talking about the user's point of view,
it is absurd to discard user feedback as "not an argument".

>>> 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.
> Maintaining style-dependent keywords in style files was a design
> decision, not a reaction to deficiencies of font-latex.el.

Fine.  We still have other deficiencies to deal with.  I think it is a
sensible design decision to collect style specific information in
style files.  We already have tex-style.el going against that,
however.  It might make sense to construct a scheme with which we can
autoextract tex-style.el: the style files are in a .nosearch
directory, and so we can even just use autoload cookies for everything
that needs to go into tex-style.el.

David Kastrup, Kriemhildstr. 15, 44793 Bochum

reply via email to

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