[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: |
Fri, 20 Dec 2013 23:58:06 -0500 |
User-agent: |
Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) |
On Sat, 21 Dec 2013 12:32:19 +0900 "Stephen J. Turnbull" <address@hidden>
wrote:
SJT> Ted Zlatanov writes:
SM> - what completion operations take place:
SM> - insert a few chars at point
SM> - bring up a list of candidates
SM> - ...
>>
>> I think this should be unified as much as possible into a single
>> operation that takes place in any context, outside of the user's
>> control. IOW this should be the place where Emacs standardizes to only
>> one completion/selection API, possibly through the `completion-*'
>> functions.
SJT> Please explain what you mean by "unify". If you mean
SJT> one-size-fits-all, I think that would be horrible. There are
SJT> completion contexts where I don't want a list at all (dabbrev), and
SJT> others where I really, really do (browser completion of long URLs from
SJT> long histories).
The context will be respected either by being a parameter or being
inferred from the invocation, or both. The idea is to have a single API
call for all contexts, not to make the operation's effect the same in
all contexts.
SJT> If you simply mean there should be one function to invoke the
SJT> completion system, or a small number of such functions, with a "small"
SJT> number of parameters, I agree.
Right, exactly.
SJT> I think this points out the need for a dispatching architecture,
SJT> where the completion function exposed in the API ends up
SJT> dispatching to several handlers: construct the candidate list,
SJT> filter it, prioritize it, optionally present it to the user, and
SJT> optionally edit the target text ("auto-complete" suggests that edit
SJT> will always happen, but it's not always what is desired of a
SJT> completion mechanism -- eg, something I've occasionally wished for
SJT> is a "uniquifying completer", so that I don't accidentally
SJT> duplicate identifiers -- "you can check out but you can never
SJT> leave" until the item is unique in scope :-).
See the company-mode frontend/backend split, for instance. This is a
common design. I don't have a strong opinion about the whole data flow,
I just want to improve the frontend right now, but perhaps these
opportunities will appear if the project takes off.
SM> - how to display the list of candidates:
SM> - in a separate buffer
SM> - at point, via clever overlay tricks
SM> - at point, via a special frame
SM> - at point, via a x-popup-menu
SM> - ...
>>
>> This should probably be customizable, but the default IMO should be
>> different between graphical and text mode, the way that `widget-choose'
>> does it.
SJT> If you architect the system as dispatching handlers to perform certain
SJT> tasks in sequence, you can postpone this decision (and, in fact, most
SJT> of the decisions you are discussing here, prematurely IMHO). It seems
SJT> to me that the custom "selectors" for instancing faces (or whatever
SJT> the "keys" in a defface are called) would be a good choice for
SJT> specifying completion "list display" handlers. Then you can start
SJT> with "one size fits all" with a selector of t and easily
SJT> generalize.
I think postponing these design decisions would not be optimal, but I
understand the temptation and will listen to advice when we get to that
point.
SJT> The only nasty task in this architecture would be if it becomes
SJT> necessary to split a handler into two. However, AFAICT from your
SJT> immediate agreement to the agenda Stefan set here, the three of us
SJT> (you, Stefan, me) agree 100% on what the options involved are, and I
SJT> suspect we could also agree quite quickly on what tasks deserve
SJT> separate handlers (some of the options probably need coordinated
SJT> decisions to avoid screwing each other up, so should not be in
SJT> separate handlers).
I still need a clear agreement from Stefan before proceeding. Then I
will try to get a team together and work outside of the normal Emacs
commit flow so we can iterate quickly.
SJT> That's only 3 people, but I think it's good evidence that agreement
SJT> is going to be widespread, given how disparate our opinions have
SJT> been on everything else in this thread.
Discussions of UI improvements are one of the rare occasions where
everyone has at least one strong opinion. I think this one has been
quite smooth, I've only thrown one keyboard out the window and AFAIK
I'm not yet in Stefan's killfile ;)
Ted
- Re: enabling company-capf support in cfengine.el, (continued)
- Re: enabling company-capf support in cfengine.el, Ted Zlatanov, 2013/12/22
- Re: enabling company-capf support in cfengine.el, Dmitry Gutov, 2013/12/22
- Re: Emacs completion matches selection UI, Stefan Monnier, 2013/12/22
- Re: Emacs completion matches selection UI, Dmitry Gutov, 2013/12/22
- 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 <=
- 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, 2013/12/23
- 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