Re: Emacs completion matches selection UI

[Stephen J. Turnbull]

chad writes:

 > To Stephens point, I think that theres a fairly large, demonstrated
 > desire for some sort of wheel that looks and works a lot like (for
 > example) auto-complete:

Conceded that there's demand.  I would argue that ac-mode is not good
enough for Emacs, because it's menu-based.  I assume from hints on the
page you linked that selection algorithm "learns" over time, but the
menu presented in the screenshot there is full of junk that almost
certainly is undesired.  By contrast, the trivial heuristic "it's in a
buffer somewhere in this Emacs instance" with in-place expansion
iterating over candidates with repeated invocations (dabbrev) is more
accurate, less obtrusive, and more Emacs-y IMHO (YMMV, of course).
And quite fast, even with several dozen buffers.

 > comparing Emacs and Eclipse. Im not %100 sure that this is what Ted
 > is asking after, but I think so. Id also like to see such a wheel
 > in Emacs, ideally built-in.

Unless auto-complete usually does a lot better than the menu in the
screenshot, I'd say no thanks to its algorithm in core.  The various
UIs should be expressed as standard APIs in core, with some sort of
mechanism for configuring them flexibly (the file handler system is
the mod4el I have in mind, although that's probably over-elaborate for
this task).

Traditional Emacs UIs as default would be my preference.

 > The recent iswitchb/icomplete/ido discussion and conversations with
 > several programmers (some current Emacs users, some ex-Emacs users)
 > suggests to me that this is a big deal for potential Emacs users.

It's still not obvious to me that we really need to cater to
"potential" Emacs users, for reasons I gave earlier.  The best way to
handle the issue (UI themes) isn't really available, except for
cua-mode.

 > * Can we get a solid consensus on whether or not this sort of thing
 >   is desirable in Emacs?

The necessary widgets (pretty popup menus, etc) should be in core for
the usual reasons that GUI toolkits provide them.  Even if core Emacs
developers don't particularly like them (including attempting to teach
new users to avoid them ;-), the demand is there, itches will be
scratched, and it's best if they're scratched consistently.

 > * If we think it’s a good idea to enable, should it be inside Emacs or
 >   in some external package?

Filtering and ordering algorithms don't seem to belong in core yet.
The screenshots of Emacs implementations and my experience with
non-Emacs implementations suggests there's a heck of a lot of
improvement needed.  Some API for plugging those into the completion
widgets would probably be a very good idea.