[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: completing-read return meta-information?

From: Stephen Leake
Subject: Re: completing-read return meta-information?
Date: Sat, 26 Sep 2015 05:54:52 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt)

Stephen Leake <address@hidden> writes:

> Stefan Monnier <address@hidden> 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: minibuffer-patches-2.el
Description: application/emacs-lisp

reply via email to

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