unofficial mirror of emacs-devel@gnu.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: Mon, 21 Sep 2015 11:46:50 -0500	[thread overview]
Message-ID: <861tdrwwhx.fsf@stephe-leake.org> (raw)
In-Reply-To: jwvsi6d6ddl.fsf-monnier+emacs@gnu.org

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

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> There is a desire to refactor this so that the only difference is inside
>> the completion table.
>
> I think the uniquification shouldn't be done in the completion table.
>
> All the fancy rewriting to make things shorter should be done in the
> completion-style, instead.  The style code can choose to return different
> kinds of results for completion-all-completions (which gets displayed
> in *Completions*, in Company, or in Icomplete-mode and where we should
> try and reduce redundancy) and for completion-try-completion.
>
> So completion-all-completions can return names like "foo<bar>" while
> completion-try-completion can return "~/src/file/foo/toto/bar.agda".

Attached is code that implements this, together with ert test code for
it (helpful in getting the details right).

This achieves the goal of moving all of the uniquification code out of
the completion table; that required advice on test-completion.

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.

Note that this does not handle completion on multiple fields (for
uniquifying directories); I was focusing on the changes to completion
needed to return an absolute file name. That will be added later, and
may require design changes

See the header comment in minibuffer-patches.el for some design notes.

This may be an acceptable implementation, but it would be better to
extend completion-style-alist to include slots for
completion-test-completion and completion-get-data-string. I think that
can be done in a backward-compatible way; if (nth 2
completion-style-alist) (for completion-test-completion) returns a
string, just call test-completion, and if (nth 3 completion-style-alist)
(for completion-get-data-string) returns nil just return the input
string.

Then we can change all uses of `test-completion' to call
`completion-test-completion'.

I'm not entirely sure where the call to completion-get-data-string
should be added; one place is in `completion--complete-and-exit', but
there may be others. (I didn't advise completion--complete-and-exit
directly because I didn't want to mix advice and signals).


To try this out, load minibuffer-patches, and call find-absfile
via M-: (find-absfile load-path).

Note that will not allow you to complete to ede/locate.el; that will
also be added later.

When you enter a string that does not match any filename, this gives an
error from one of the basic completion functions; I have not tried to
track that down yet.

--
-- Stephe

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

[-- Attachment #3: minibuffer-test.el --]
[-- Type: application/emacs-lisp, Size: 6721 bytes --]

  parent reply	other threads:[~2015-09-21 16:46 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 [this message]
2015-09-21 19:12         ` Stephen Leake
2015-09-21 19:51         ` Stefan Monnier
2015-09-22 15:21           ` Stephen Leake
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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=861tdrwwhx.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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).