Re: Re: Completing with anything

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> Hmm... good point, doing it in completion-choices is not reliable, tho
>> using as completion table something like:
>> 
>> (lambda (string pred action)
>> (let ((res (complete-with-action action completion-choices string pred)))
>> (if (and (eq action nil)
>> (assq (if (eq res t) string res) <expansion-alist>))
>> (cdr (assq (if (eq res t) string res) <expansion-alist>))
>> res)))
>> 
>> should work OK for prefix completion, but that means using the expansion
>> "by hand" rather than via expand-abbrev, which may not be an option.

> Yeah. That does not looks like a simple/good option.
> As it stands, I guess the bbdb solution to return a function doing the
> replacement rather than trying to return a list and conform with the
> (current) way of doing completion is really simpler, unfortunately. :(

While taking a look at adding the necessary functionality to
minibuffer.el, I bumped into a problem:

If you complete "ni" to "nic" which is a valid alias and you also have
a "nicolas" alias, running expand-abbrev after the completion may not be
right since it will prevent you from getting to "nicolas".

Now, this is a minor problem.  But the more general case is when the
user has set completion-cycle-threshold so that completion happened via
cycling: the string after completion is a valid abbrev (presumably) but
calling expand-abbrev on it will interfere with the cycling in a big way
(the details of what will happen depend on the way cycling is
implemented and what kind of abbrevs we're talking about).

So at least cycling-completion seems fundamentally incompatible with
this idea of abbrev-expansion-after-completion, at least if you want to
allow arbitrarily complex abbrevs like skeletons.

Could you give me an idea of what kind of abbrevs the code should try
to accommodate?


        Stefan