auctex-devel
[Top][All Lists]
Advanced

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

Re: [AUCTeX-devel] Re: Make TeX-insert-macro behave intelligently on \us


From: Arne Jørgensen
Subject: Re: [AUCTeX-devel] Re: Make TeX-insert-macro behave intelligently on \usepackage
Date: Tue, 11 Oct 2005 15:05:25 +0200
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)

David Kastrup <address@hidden> writes:

> Arne Jørgensen <address@hidden> writes:
>
>> The inferior and carelessly modeled solution is `multi-prompt' I
>> think. I already have a implementation that does that
>> (http://arnested.dk/filer/usepackage.patch).
>
>> Now. What road to choose? I tend to prefer the solution with
>> multi-prompt because we don't have to double stuff. The inferior
>> usability of multi-prompt should be nagging enough (Ralf).
>>
>> On the other hand since multi-prompt is part of AUCTeX choosing the
>> other solution we could eliminate multi-prompt and only have the
>> superior functionality of crm/tex-crm?
>
> I think other parts of AUCTeX rely on multiprompt, and there might be
> some third-party packages as well.

A grep reveals only two places in latex.el.

> I'd prefer to keep multiprompt in the distribution, I think, though we
> might add a warning that it might be removed at a later point of time.
>
> Is the crm functionally a superset of multiprompt?  If it is, we could
> try to make wrapper functions that map to crm when available, and use
> multiprompt if not.

It looks as if multi-prompt and crm are trying to solve the same
problem. And crm in a far superior way.

It should be quite simple to replace multi-prompt with a wrapper
function that calls crm.

We would still need to solve the XEmacs case, though.

> It would seem to make sense to use either multiprompt or crm
> consistently, the way it sounds, but I think it is ok to make the
> decision at load time.

I prefer crm over multi-prompt any time.

Kind regards,

     /arne
-- 
Arne Jørgensen <http://arnested.dk/>




reply via email to

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