RE: [External] : Re: Updating *Completions* as you type

[Drew Adams]

> The reason they aren't distributed on GNU or
> NonGNU ELPA is that you overwrite built-in
> definitions

No, that's not the reason.  Not at all.

> > As I tried to make clear in my posts, their aim
> > was to mention various Icicles features I think
> > are relevant to this thread - not to advertise
> > Icicles or suggest its use.
> >
> > The point was to encourage consideration of such
> > or similar features as useful and perhaps worth
> > adding to vanilla Emacs.  Nothing more.
> >
> > Icicles is just a reference point here.  Its doc
> > about such features might hopefully provide some
> > food for thought.  _What users can do_ is the
> > point, not how such features can be implemented.
> >
> > It's good to see others coming around to similar
> > feature ideas now.  Knowledge that such features
> > work _in combination_, and they have done so for
> > quite a while, should be helpful, I hope.
> 
> I might be mistaken, but the reason I thought your
> were "advertising" Icicles, was that you usually
> respond to the suggestion to add some feature with
> something like "Icicles had this feature since 200X".

I don't know whether you're mistaken about
why you thought that.

But if what you mean is that you might be
mistaken about why I say that, then yes,
you're apparently mistaken about that.

The above text should make that "why" very
clear, so I wonder why you would still be
wondering.  Let me say it once more:

  such features might hopefully provide
  some food for thought.  _What users can
  do_ is the point

Many Icicles features have been adopted
(reinvented) for vanilla Emacs or other
completion libraries.  Other features
have not (yet).  I mentioned on-the-fly,
flexible interactive sorting as one, in
particular, because this thread broached
the question of sorting candidates.

The point in mentioning Icicles features
is that they might be of interest as
food for thought: _what_ they do, not
necessarily _how_ they do it.

If a user of vanilla Emacs or another
library can't do XYZ, and a user of
Icicles can, and if XYZ is a useful
thing to be able to do, then someone
might want to look at the feature in
Icicles, as food for thought.

It's not important that Icicles does
something, except that from Icicles you
can get a good description of a feature
and see the source code - if interested.

> > Wrt la petite histoire -
> >
> > To my knowledge, the first appearance of any
> > incremental completion was in icomplete-mode.
> > But that wasn't a completion whose result you
> > could _use_; it was only completion you could
> > _see_ (and only a few completions).  You could
> > use it only as a guide/preview of what you could
> > then type.  (Much later, completion of input was
> > finally added to icomplete-mode.)
> >
> > Next was IswitchB, which later became the model
> > for Ido.  Completion candidates were shown only
> > in the minibuffer (and again, only a few) - no
> > use of *Completions* to show candidates.
> >
> > Icicles came after icomplete-mode and IswitchB,
> > and before Ido.  It introduced incremental
> > completion showing candidates in *Completions*;
> > cycling among candidates (notion of "current"
> > candidate); on-the-fly sorting of them; etc.
> 
> The copyright files indicate this chronology:
> 
> icomplete: 1992
> icicles:   1995
> iswitchb:  1996
> ido:       1996

Please read what I said, which is about
incremental completion, not copyright of
the libraries.

Here's a very brief description of the
initial history of Icicles:

https://www.emacswiki.org/emacs/Icicles_-_La_Petite_Histoire

That doesn't specifically mention
incremental completion.  But the Change
Log in icicles-chg.el indicates it was
added in 2006 or before then.  Looking
at details in the log indicates it was
in 2005 or before (as "icompletion").

Icicles as such, with cycling of
matching candidates etc., really began
in 2005.  (The name dates from then.)

>From 1996 to 2005 it was essentially
elect-mbuf.el, which (1) never updated
the set of candidates to cycle among,
and (2) never tied cycling (current
candidate in *Completions*) to the
minibuffer content (no "current
candidate" there).  It didn't do much
at all, except let you see the initial
set of completion candidates.

[ BTW, #2 is similar to the situation
  with vanilla Emacs today wrt sorting:
  the sort order for *Completions*
  isn't necessarily the same as the
  sort order for the minibuffer content
  (`display-sort-function' versus
  `cycle-sort-function').

  I've asked for the reason why - why
  or when that might be useful, but
  I've not received any answer, ever.
  Until I do, I'll just consider it a
  misfeature or a missed opportunity. ]