[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 00:29:14 +0900

Aaron Ecay writes:

 > In this vein, it may be useful to think of the CompletionUI package
 > <http://www.emacswiki.org/emacs/CompletionUI>.  Quoting from the
 > EmacsWiki description, presumably written by the author: “Typically, a
 > lot of code in packages providing some kind of text completion deals
 > with the user interface. The goal of CompletionUI is to be the
 > swiss-army knife of in-buffer completion user-interfaces, which any
 > source of completions can plug in to, thus freeing completion package
 > writers to concentrate on the task of finding the completions in the
 > first place.”

+1 to that, but does CompletionUI achieve the goal?

 > Perhaps predictably <http://xkcd.com/927/>, the goal of other completion
 > package writers adopting this system seems to have gone unrealized.  But
 > maybe if a similar system were “blessed” by being included in emacs core
 > (tied to the existing completion-at-point-functions) things might go
 > better.

"Blessing" does help, a lot, but the big problem with systems of this
kind is that they *don't* achieve the goal, for several reasons:

1. The various gadgets on a Swiss Army knife are most useful if you
   don't have access to a workbench with fullsize versions.  So while
   the "Swiss Army knife" metaphor is standard in this kind of thing,
   a more accurate metaphor is "Snap-On toolbox on casters".  Are the
   gadgets in CompletionUI Snap-On-quality professional tools?

2. Are they sufficiently customizable by apps, while providing
   sufficient capability with very simple usage so that they make
   sense for use in RAD prototypes, then tweaked as the prototype is
   converted to a full-blown app?

3. Is the customization user-oriented, so that the programmer just
   plugs them in once, and users can easily choose the styles they
   prefer?  Bonus points if it's easy for programmers to provide a
   suite of defaults without hardcoding them in API calls.

4. Are both the APIs and UIs well-documented?  This goes a long way to
   alleviating the issue in #1, as initial adopters quickly fix bugs,
   improve interfaces, and adding features.

reply via email to

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