[Top][All Lists]

[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 16:05:24 +0200
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)

David Kastrup <address@hidden> skriver:

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

OK. Then I didn't understand you right. Sorry.

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

That's actually what I have at the moment.

(if (fboundp 'completing-read-multiple)
    (defalias 'TeX-completing-read-multiple 'completing-read-multiple)
  (defun TeX-completing-read-multiple
    (prompt table &optional predicate require-match initial-input
           hist def inherit-input-method)
    "Poor mans implementation of Emacs' `completing-read-multiple' for XEmacs."
    (require 'multi-prompt)
    (multi-prompt "," nil prompt table predicate require-match initial-input 

I just dicovered a difference in `multi-prompt' and `crm'.  If the
second argument of `multi-prompt' is non-nil the values you are
completing on are supposed to be unique and there is no way to specify
that in `completing-read-multiple' so we cannot replace the two
occurences of `multi-prompt' in latex.el with
`completing-read-multiple' without loosing that.

>> We would still need to solve the XEmacs case, though.
> That would be solved in the above manner. 


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


Kind reagrds,

Arne Jørgensen <>

reply via email to

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