all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stephen Leake <stephen_leake@stephe-leake.org>
To: emacs-devel@gnu.org
Subject: Re: completing-read return meta-information?
Date: Tue, 22 Sep 2015 10:21:10 -0500	[thread overview]
Message-ID: <86oaguv5sp.fsf@stephe-leake.org> (raw)
In-Reply-To: <jwvbncvmu63.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Mon, 21 Sep 2015 15:51:18 -0400")

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.


This discussion points out that "user input string" and "display string"
have the same format; both can be passed to completion-try-completion and
completion-test-completion. The only difference is that the strings
returned by completion-all-completions all identifiy unique, valid
files. So I think I'll merge those two string types to "user string";
that should make this clearer.

> PS: Also, as a user, I think I'd rather see names like "dir/file" than
> "file<dir>".

You only need directory names when there are conflicting names; on many
paths, there will be none or few.

I mainly used that style because it meant the user string is a prefix of
all the completions, which some of the completion primitives expect, so
it made things simpler.

On the other hand, I use the postfix uniquify style for buffer names, so
I'm used to it :).

I'll try to implement directory completion in both styles; this should
be a user preference, just as it is in buffer names.

-- 
-- Stephe



  reply	other threads:[~2015-09-22 15:21 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-16 13:57 completing-read return meta-information? Stephen Leake
2015-09-16 15:00 ` Drew Adams
2015-09-16 17:06   ` Stephen Leake
2015-09-16 17:28     ` Drew Adams
2015-09-16 17:45   ` Stephen Leake
2015-09-17  1:38     ` Stefan Monnier
2015-09-17 12:52       ` Stephen Leake
2015-09-17 13:24         ` Stefan Monnier
2015-09-17 18:14           ` Dmitry Gutov
2015-09-18  0:54             ` Stefan Monnier
2015-09-21 16:46       ` Stephen Leake
2015-09-21 19:12         ` Stephen Leake
2015-09-21 19:51         ` Stefan Monnier
2015-09-22 15:21           ` Stephen Leake [this message]
2015-09-26 10:54             ` Stephen Leake
2015-09-27 15:45               ` Stefan Monnier
2015-09-28  5:50                 ` Dmitry Gutov
2015-09-28 15:59                 ` Stephen Leake
2015-09-28 16:13                 ` Stephen Leake
2015-09-28 19:42                   ` Stefan Monnier
2015-09-28  5:58             ` Dmitry Gutov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86oaguv5sp.fsf@stephe-leake.org \
    --to=stephen_leake@stephe-leake.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.