[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
- [AUCTeX-devel] multi-file support, Richard Lewis, 2005/05/05
- Re: [AUCTeX-devel] multi-file support, Ralf Angeli, 2005/05/05
- Re: [AUCTeX-devel] multi-file support, David Kastrup, 2005/05/05
- Re: [AUCTeX-devel] multi-file support, Ralf Angeli, 2005/05/06
- Re: [AUCTeX-devel] multi-file support, David Kastrup, 2005/05/06
- Re: [AUCTeX-devel] multi-file support, Ralf Angeli, 2005/05/06
- Re: [AUCTeX-devel] multi-file support, David Kastrup, 2005/05/06
- Re: [AUCTeX-devel] multi-file support, Ralf Angeli, 2005/05/06
- Re: [AUCTeX-devel] multi-file support,
David Kastrup <=
- Re: [AUCTeX-devel] multi-file support, Ralf Angeli, 2005/05/06
- Re: [AUCTeX-devel] multi-file support, David Kastrup, 2005/05/06
- Re: [AUCTeX-devel] multi-file support, Ralf Angeli, 2005/05/06
- Re: [AUCTeX-devel] multi-file support, David Kastrup, 2005/05/06
- Re: [AUCTeX-devel] multi-file support, Ralf Angeli, 2005/05/07
- [AUCTeX-devel] Re: multi-file support, Richard Lewis, 2005/05/09
- Re: [AUCTeX-devel] Re: multi-file support, Ralf Angeli, 2005/05/09
- [AUCTeX-devel] Re: multi-file support, Richard Lewis, 2005/05/10
- [AUCTeX-devel] Re: multi-file support, Ralf Angeli, 2005/05/10
- [AUCTeX-devel] Re: multi-file support, Richard Lewis, 2005/05/13