[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs completion matches selection UI
From: |
Ted Zlatanov |
Subject: |
Re: Emacs completion matches selection UI |
Date: |
Mon, 23 Dec 2013 07:28:39 -0500 |
User-agent: |
Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) |
On Sun, 22 Dec 2013 20:59:49 -0500 Stefan Monnier <address@hidden> wrote:
>> I mean TAB (and its equivalent in-buffer keybinding) should be bound to
>> a single Elisp function, and the effect (list candidates, complete
>> immediately the single candidate, or cycle candidates depending on the
>> user preferences) should be consistent in any invocation context.
SM> Not sure what you feel is missing here. `completion-at-point' is
SM> basically it, AFAICT. But it's OK if different UIs provide other
SM> commands (or other ways, since completion can also happen as
SM> a side-effect of normal commands, as is the case with auto-complete and
SM> company-mode).
SM> The important point is that the completion command to use shouldn't
SM> depend on the "backend" (e.g. on the current major mode), and AFAIK
SM> we're almost there (the new completion code in Emacs-23 and subsequent
SM> bit-by-bit updates of major modes to make use of
SM> completion-at-point-functions was dedicated to this task).
SM> Can't remember what are the remaining exceptions, other than Eshell.
OK, is there a way to make a verification and testing plan for this? If
there was some automation around completion support, it would certainly
speed things up, but we need at least a list of currently non-compliant
modes in Emacs. How do you look for the exceptions, by searching for
old functions or testing manually?
SM> Hmm... Could you explain which parts are not consistent?
>> "Select with up/down" is not consistent between in-minibuffer and
>> in-buffer completion.
SM> AFAIK it is consistent: neither in minibuffer nor in in-buffer up/down
SM> is bound to a completion-related command. It's not what you want, but
SM> it's consistent w.r.t the completion UI.
Using `up' in the minibuffer goes back in the history currently, which
invalidates the current completion candidates, so it does have some
effect. But I agree it's not directly completion-related.
>> "Keep on editing" acts differently as well.
SM> Details?
Minor.
>> OK, so do we agree on this specific improvement? "Whether in the
>> minibuffer or in a buffer, typing more characters should narrow the list
>> of candidates without having to press TAB or other special keys."
SM> If you add the qualifier "when the completion list is displayed",
SM> I think I agree, yes (I actually hesitated to add that feature when
SM> wrote the new minibuffer.el code, but then decided to keep it for later,
SM> sine there was plenty of other behavioral changes introduced at that
SM> time already). You might want to make it configurable, but I think
SM> enabling it by default would be OK.
SM> Usually, if it works for in-buffer, it works as well in the
SM> minibuffer case.
>> Good point. But why not simply enter an auto-narrowing popup in both
>> contexts?
SM> Didn't I just agree in the previous paragraph?
OK.
>> The user has explicitly requested completion, right? I keep
>> thinking that if in both contexts we locked the user into a selection
>> popup, the up/down and motion issues would be easily solved. It would
>> also allow `C-1' through `C-9' (or some similar keys) to be used to
>> immediately select a candidate by position, like `widget-choose' does it.
SM> As I already said in earlier discussions, it might very well be
SM> acceptable to hijack those keys. But only experience can confirm it.
So auto-narrowing (customizable) and a graphical popup (customizable as
a frontend choice) are OK. Hijacking keys is to be tested further and a
demo is needed. All this will happen with `completion-at-point'.
SM> The API design should presumably make it possible to use company-mode's
SM> overlay-based popups, or widget-choose's popup, or good ol'
SM> *Completions* buffer.
As with company-mode, this can be a frontend choice (affecting
`display-completion-list', and see below for the suggested
`display-list' function). How about a defcustom
`completion-ui-frontend' with some choices?
SM> It should maybe also make it possible for the caller to provide some
SM> data that might influence which kind of popup to use (in case the
SM> kind of popup to use might depend on the context: not sure if that's
SM> really necessary), tho the ultimate choice should be with the user's
SM> config, of course.
For the user, a new defcustom `completion-ui-preferences'? And for the
caller, some kind of plist/alist passed to `completion-at-point' that
merges cleanly with `completion-ui-preferences'?
s/completion-ui/something-else/ as you see fit.
>> So let's say I'm inside gnutls.el and want to ask the user to select a
>> client certificate to present to the remote server. I have a list of 3
>> such certificates. I would say `(display-completion-list
>> list-of-certificates)' and expect the result to be nil or an element of
>> the list. Does that usage make sense?
SM> No. That would seem to call for a completely different API meant to
SM> generalize completing-read rather than display-completion-list.
I would like that, too, so choosing from a list of elements can use all
the improvements suggested here for `display-completion-list'. Could
this be a new `display-list' function, used to display both completion
selection (through `display-completion-list') and list selection?
Ted
- Re: Emacs completion matches selection UI, (continued)
- Re: Emacs completion matches selection UI, Stefan Monnier, 2013/12/23
- Re: Emacs completion matches selection UI, Stephen J. Turnbull, 2013/12/19
- Re: Emacs completion matches selection UI, Stephen J. Turnbull, 2013/12/19
- Re: Emacs completion matches selection UI, Stefan Monnier, 2013/12/20
- Re: Emacs completion matches selection UI, Ted Zlatanov, 2013/12/20
- Re: Emacs completion matches selection UI, Stephen J. Turnbull, 2013/12/20
- Re: Emacs completion matches selection UI, Ted Zlatanov, 2013/12/20
- Re: Emacs completion matches selection UI, Stefan Monnier, 2013/12/21
- Re: Emacs completion matches selection UI, Ted Zlatanov, 2013/12/22
- Re: Emacs completion matches selection UI, Stefan Monnier, 2013/12/22
- Re: Emacs completion matches selection UI,
Ted Zlatanov <=
- Re: Emacs completion matches selection UI, Stefan Monnier, 2013/12/23
- Re: Emacs completion matches selection UI, Ted Zlatanov, 2013/12/23
- Re: Emacs completion matches selection UI, Toby Cubitt, 2013/12/30
- Re: Emacs completion matches selection UI, Leo Liu, 2013/12/30
- Re: Emacs completion matches selection UI, joakim, 2013/12/31
- Re: Emacs completion matches selection UI, Dmitry Gutov, 2013/12/31
- Re: Emacs completion matches selection UI, Toby Cubitt, 2013/12/31
- Re: Emacs completion matches selection UI, joakim, 2013/12/31
- Re: Emacs completion matches selection UI, John Yates, 2013/12/23
- Re: Emacs completion matches selection UI, Stefan Monnier, 2013/12/23