Re: completing-read return meta-information?

[Stephen Leake <stephen_leake@stephe-leake.org>]

[-- Attachment #1: Type: text/plain, Size: 1605 bytes --]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>
>>> It also achieves the goal of returning an absolute string from
>>> completing-read; that required advice on completing-read-default to call
>>> the new function completion-get-data-string.
>>
>> Why can't you make completion-try-completion return an absolute filename
>> when there's only one match?  
>
> The string returned from completion-try-completion is displayed in the
> minibuffer, as the completion prefix. I don't want that to be the
> display string.
>
> Part of the point of using path completion is that you don't care what
> directory the file is in. So having the absolute path displayed as the
> final completion feels like the system forcing you to care.
>
> More importantly, the user can type <ret> at any time; then
> test-completion should return t when it is passed the abbreviated
> display string from the first completion; that is known to be a unique
> valid completion.
>
> So this approach would require the user to always type tab, or go thru
> one more confirmation step after typing <ret>. I tried this approach
> early in this work, and could not make it work consistently.

I took another stab at this, and got it to work; attached.

The version with advice is cleaner, but not by a whole lot.

The completion function calls a deuniquify function, and the top level
client code calls `try-completion' after calling `completing-read'. The
user sees an absolute filename in the completion buffer only if they
type <tab> twice on a unique file.

-- 
-- Stephe

[-- Attachment #2: minibuffer-patches-2.el --]
[-- Type: application/emacs-lisp, Size: 13728 bytes --]