unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: emacs-devel@gnu.org
Subject: Re: project--completing-read-strict breaks ada-mode project completion table
Date: Wed, 20 Feb 2019 21:00:43 -0500	[thread overview]
Message-ID: <jwv8sy9q5st.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: 86sgwi1bb1.fsf@stephe-leake.org

>> We definitely want to support the case where the collection works OK for
>> most/many/some styles, where it also wants to provide its own style, and
>> where we want the user to be able to override that (via
>> completion-category-oiverrides).  So even for those collections where
>> only its own style works, it makes sense to use that same (overridable)
>> mechanism rather than provide another.
>
> But then project backends that choose to provide a uniquify-file (or any
> other "broken") completion table won't "just work"; the user will have
> to set completion-category-default or -overrides to get completion to
> work (as illustrated by locate-uniquified-file; more below).

No, indeed we don't want that: we want that the
completion-table-provided style is used by default without the user
having to take any special steps.  But we also want it to be possible
for the user to specify some other style to use instead.

>>>> I don't understand this.  Why can't the completion style compute the
>>>> common-prefix?
>>> The root is _not_ the common prefix of the current matches;
>>
>> I don't mean "of the current matches" but "of the entire collection".
>> (try-completion "" collection) should return just that, so the
>> completion-style does have access to it (unless the collection doesn't
>> implement `try-completion` correctly for that case, but it seems that
>> in the present situation we have control over the collection so we can
>> make sure it works correctly).
> Yes, that would work, and be horribly inefficient.

Indeed, it would only work acceptably if either the backend special
cases the "" case or the style is able to do enough caching.

>> What I meant is that when we call uniq-file-get-data-string we already
>> know that the user string is a valid match, so there shouldn't be any
>> need to search in the completion table.  E.g. if it's
>> "foo-file1.text<Alice/alice-1/>" we should be able to just prepend the
>> hidden common prefix to the output of uniq-file-to-table-input, no?
> Yes, but that common prefix is only stored implicitly in the table.
> If we had a completion object, we could store it there.

Ah, OK, so it's an artifact of limitations of the current API, makes sense.

> I guess by "mixing with other styles" you mean processing a list of
> styles; if we had (basic uniquify-files), for <tab> on an empty string
> 'basic' would present a list of absolute file names, but for <tab> after
> a string that matches some basename 'uniquify-files' would present
> uniquified file names. That would be confusing, and I now realize that's
> why I only specify one completion style.

Exactly: they're mutually incompatible (not necessary in the sense that
something will break, but in the sense that the result makes no sense
for the user).

> It will probably require editing minibuffer.el, but I'll think about it.

Right, I'm thinking from the point of view that minibuffer.el can be
changed at will.  If/when we figure out a clean solution there, we can
maybe think about how to try and make it work with current
minibuffer.el.

> Note that uniq-file-completion-table is an optimization; the
> uniquify-file completion style does work with a list of absolute files,
> or any completion table function that returns such a list.

Indeed, thinking about the kind of manipulation done for your
uniquification, it seems like it pretty much requires to have the
complete list from the start (and to basically start by rewriting this
list from the data format to the user format on entry, then do normal
completion on this and then convert the final result back to data
format).


        Stefan




  reply	other threads:[~2019-02-21  2:00 UTC|newest]

Thread overview: 103+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20180922154639.23195.66360@vcs0.savannah.gnu.org>
     [not found] ` <20180922154640.9D58220310@vcs0.savannah.gnu.org>
2018-12-26  3:34   ` [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el Dmitry Gutov
2018-12-26 20:13     ` Stefan Monnier
2018-12-27  1:49       ` Dmitry Gutov
2018-12-27 14:39         ` Stefan Monnier
2018-12-28  3:45           ` Dmitry Gutov
2018-12-31 11:42             ` Dmitry Gutov
2018-12-31 15:12               ` Eli Zaretskii
2019-01-02 23:47                 ` Dmitry Gutov
2019-01-02  1:49               ` Stefan Monnier
2019-01-03  0:41                 ` Dmitry Gutov
2019-01-02 21:53               ` Juri Linkov
2019-01-02 23:02                 ` Dmitry Gutov
2019-01-03  0:37                   ` Juri Linkov
2019-01-03 11:45                     ` Dmitry Gutov
2019-01-03 20:53                       ` Juri Linkov
2019-01-06  1:22                         ` Dmitry Gutov
2019-01-07 23:22                           ` Dmitry Gutov
2019-01-07 23:27                             ` Dmitry Gutov
2019-01-08 14:21                             ` Michael Albinus
2019-01-08 23:06                               ` Dmitry Gutov
2019-01-09  8:10                                 ` Michael Albinus
2019-01-09 15:24                                   ` Dmitry Gutov
2019-01-09 14:57                             ` Dmitry Gutov
2019-01-09 23:15                               ` Juri Linkov
2019-01-10 10:20                                 ` Dmitry Gutov
2019-01-10 21:41                                   ` Juri Linkov
2019-01-12  1:48                                     ` Dmitry Gutov
2019-01-18  3:52                 ` Dmitry Gutov
2019-01-18 12:49                   ` Stefan Monnier
2019-01-18 19:28                     ` Dmitry Gutov
2019-01-18 21:11                       ` Stefan Monnier
2019-01-18 22:53                         ` Dmitry Gutov
2018-12-29  0:27           ` Dmitry Gutov
2018-12-29 17:09             ` Dmitry Gutov
2018-12-29 21:54               ` Juri Linkov
2018-12-30 23:06                 ` Dmitry Gutov
2019-01-02  1:48                 ` Stefan Monnier
2019-01-02 22:05                   ` Juri Linkov
2019-01-03  3:44                     ` Stefan Monnier
2019-01-03 20:45                       ` Juri Linkov
2019-01-12  1:10           ` Making project-files the "canonical" generic, was: " Dmitry Gutov
2019-01-12 18:53             ` Making project-files the "canonical" generic Stephen Leake
2019-01-13  0:54               ` Dmitry Gutov
2019-01-15  1:14                 ` Stephen Leake
2019-01-16 16:38                   ` Stefan Monnier
2019-01-17  2:23                     ` Dmitry Gutov
2019-01-17 13:25                       ` Stefan Monnier
2019-01-18  1:00                         ` Dmitry Gutov
2019-01-16 19:02                   ` project--completing-read-strict breaks ada-mode project completion table Stephen Leake
2019-01-16 22:02                     ` Stephen Leake
2019-01-17 23:17                       ` Stephen Leake
2019-01-18  2:04                         ` Dmitry Gutov
2019-01-19  3:35                           ` Stephen Leake
2019-01-19 22:05                             ` Dmitry Gutov
2019-01-20 19:34                         ` Stephen Leake
2019-01-17  2:21                     ` Dmitry Gutov
2019-01-17 13:55                       ` Stefan Monnier
2019-01-17 21:35                         ` John Yates
2019-01-18  2:19                         ` Dmitry Gutov
2019-01-18  3:05                           ` Stefan Monnier
2019-01-19  0:26                             ` Dmitry Gutov
2019-01-21 19:32                           ` Stephen Leake
2019-01-22  0:09                             ` Dmitry Gutov
2019-02-07  1:20                             ` Stephen Leake
2019-02-11 21:50                               ` Stefan Monnier
2019-02-12  1:31                                 ` Stephen Leake
2019-02-15 15:50                                   ` Stephen Leake
2019-02-15 22:47                                     ` Stephen Leake
2019-02-15 23:38                                       ` Stephen Leake
2019-04-19 17:49                                     ` Stephen Leake
2019-05-03  0:48                                       ` Dmitry Gutov
2019-05-04 10:39                                         ` Stephen Leake
2019-05-07 18:02                                           ` Stephen Leake
2019-05-07 22:35                                             ` Dmitry Gutov
2019-05-08  1:53                                               ` Stefan Monnier
2019-05-14  2:14                                                 ` Dmitry Gutov
2019-05-14  2:13                                             ` Dmitry Gutov
2019-02-19 17:45                                   ` Stefan Monnier
2019-02-20 19:58                                     ` Stephen Leake
2019-02-21  2:00                                       ` Stefan Monnier [this message]
2019-01-21 19:36                           ` Stephen Leake
2019-01-22  0:20                             ` Dmitry Gutov
2019-01-17  3:04                   ` Making project-files the "canonical" generic Dmitry Gutov
2018-12-27 20:33         ` [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el Juri Linkov
2018-12-27 23:31           ` Dmitry Gutov
2018-12-27 23:45             ` Juri Linkov
2018-12-28  6:04               ` Dmitry Gutov
2018-12-28 18:07           ` Stefan Monnier
2018-12-29  0:31             ` Dmitry Gutov
2018-12-29 22:02             ` Juri Linkov
2018-12-30 23:13               ` Dmitry Gutov
2019-01-02 22:11                 ` Juri Linkov
2019-01-02 23:23                   ` Dmitry Gutov
2019-01-03  0:44                     ` Juri Linkov
2019-01-03 11:52                       ` Dmitry Gutov
2019-01-03 15:35                         ` Stefan Monnier
2019-01-03 23:06                           ` Dmitry Gutov
2019-02-07 12:23                             ` Dmitry Gutov
2019-02-07 13:05                               ` Stefan Monnier
2019-02-14  1:11                                 ` Dmitry Gutov
2019-01-03 20:57                         ` Juri Linkov
2019-01-03 23:21                           ` Dmitry Gutov
2019-01-05 22:12                             ` Juri Linkov

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=jwv8sy9q5st.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --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).