Re: completing-read return meta-information?

[Stefan Monnier]

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

That's right (tho only once it's unique).

>> I don't want that to be the display string.

I think that's a mistake.

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

No, you still don't have to type it, so you're not forced to care.
But yes, you get to see it, so you can (even sub-consciously)
double-check that it's indeed the one you want.

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

If the call to completing-read uses `require-match' (which I'd expect to
be the case), then hitting RET at any time should work fine since
if the file name is incomplete test-completion will return nil, so we'll
call completion-try-completion.

[ And depending on the exact value of `require-match' the
  expanded/absolute filename will be shown to the user or not.  ]

>          (cons 'path path))))

IIUC this variable `path' holds a file name, not a list of directories,
so the GNU Coding Standard would not want to use "path" here (since
this word is only used for a list of directories as in load-path).
You could use `filename' instead.


        Stefan