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