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

[David Kastrup]

Arne Jørgensen <address@hidden> writes:

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

Seems like we have a communication problem.  My proposal was to
replace the currect calls to multi-prompt to a wrapper function call.
This wrapper function is defined at load-time, depending on whether
the crm functions are fboundp, to either use crm or multiprompt.  In
case multiprompt was used, appropriate autoloads would be defined.
Something like

(if (fboundp 'some-crm-function)
    (defun TeX-prompt-whatever (... (some-crm-function ...)))
  (autoload 'some-multiprompt-function 'multiprompt)
  (defun TeX-prompt-whatever (... (some-multiprompt-function ...))))

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

That would be solved in the above manner.  We'd still distribute
multiprompt, but it would get loaded only when crm was not available.

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

Not when it is not there.  And I think we should not actually try
providing it.  That's the problem of the XEmacs developers.  It is ok
to tell them that they should try including (and adapting) crm, and it
is ok to code in a manner that will use the crm functions if they or
autoloads for them exist.

Once the XEmacs developers deliver crm, AUCTeX will properly use it
then.  But Ralf is right in that it is not AUCTeX's job to integrate
stuff that really belongs into XEmacs proper.  Let us just keep
multiprompt for that purpose, it is at least not a degression, and
list this as one of the XEmacs disadvantages for now.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum