[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs completion matches selection UI

From: Stephen J. Turnbull
Subject: Re: Emacs completion matches selection UI
Date: Fri, 20 Dec 2013 12:06:42 +0900

Ted Zlatanov writes:

 > I don't think I ever said it should be different from all existing,
 > just that it should be a standard API we can all use and customize

Stefan has said this is a good idea.  Repeatedly.

 > I'm happy to have it look and behave more or less like
 > `widget-choose' as I said several times, or like a native widget.

And now you're wandering off into specifyinging behavior again, within
four lines of the same paragraph.  This is one important reason why
people are having trouble understanding just what you are proposing.

What I understand Stefan to want Now is a *single* API that can be
called for both at-point and in-minibuffer completion.  As I
understand it, he wants the first step to involve *decoupling* the
user-visible behavior from the completion API that the "rest of Emacs"
sees, allowing an array of *different* UIs (== "backend" behaviors) to
be attached to the *same* API ("frontend").  He seems to expect that
the *behavior* implemented initially will be based on (one of) the
existing at-point mechanisms available in core.

*I* believe that will make the contrast between old and new APIs for
developers of applications that use completion more clear, and
*perhaps* that is Stefan's rationale as well.  If such developers
prefer different behavior to the one (or few) initially implemented,
the first test of the value of the new API will be the ease with which
they can install such new behaviors.  The second test, of course, will
be the ease with which non-developer users can customize the UI (here
I mean "swap in different backends", not "GUI theming").

P.S. Note that I probably am using "frontend" and "backend" in a sense
reversed to what many people expect.  It's the same kind of thing as
the "client-server" reversal in the X Window System.  I'm taking that
point of view of the developer who is facing the completion API, and
therefore call the API "front".  After passing through the completion
implementation, he reaches the user-facing "back".

reply via email to

[Prev in Thread] Current Thread [Next in Thread]