RE: Icicles doc - file 1/2

[Drew Adams]

> > I won't use `&' in the version of Icicles that I maintain
> > outside Emacs, but you can use it if you decide to include
> > this Icicles feature in Emacs.  FWIW, I recommend that you
> > let users use `&' as a normal character for editing in
> > the minibuffer.
>
> Note that it's not nearly as bad as you make it sound: "foo&bar"
> does match the string "foo&bar" (as well as a few others).

That's not the point.

If the aim is to show how the current set of matching candidates was defined
(but why?), then that can be done, but it should not be shown in the
minibuffer, as if it were a match string.

In Icicles, the minibuffer contents are used to match candidates. `foo&bar'
as minibuffer input, which matches a certain set of candidates, is different
from `foo&bar' as an indication that you happened to define the current set
of matches by intersecting the matches of `foo' with the matches of `bar'.
`foo&bar' as input to match is different from `foo&bar' as
informative(really?) output.

Could such output be placed somewhere in the minibuffer, other than where
input occurs - as part of the prompt, perhaps, or in a way similar to
icomplete annotation? Sure. Should that be done? No, IMO. That info is not
helpful.

The most important reason is that how you happened to define the set of
matching candidates is irrelevant. A set can be defined in many different
ways.

Whether you chose the candidates one by one, performed a set union, a set
complement, a set difference, a set intersection, or some combination of
those operations is not important (why would it be?). What is important is
the resulting current match set, which you can see in *Completions*. Why
also show `foo&bar' or `(foo&bar)|toto' or `(~foo|bar)&(toto - titi)' to
indicate which set operations were performed? _If_ you demonstrate that such
info could sometimes be relevant, then it should be shown elsewhere (from
the minibuffer input area).

IMO, all printable characters should be available for editing in the
minibuffer and inclusion in minibuffer input. SPC, ?, &, whatever. The TAB
key is an exception, because it generally does not just insert the TAB
character in Emacs (and I didn't want to disrupt the conventional use of TAB
for completion). Likewise for newline (`C-j').

(Actually, I think maybe C-j should also be a normal character for
minibuffer input - I'll think about possibly making it so, for Icicles. It's
often the case that you need to input C-j in Icicles minibuffer input, to
match multiline candidates.)

Emacs 22 has finally started to allow SPC in minibuffer input, but only for
filenames. Eventually, if Emacs completion becomes more general, as it is in
Icicles, I expect that Emacs too will lighten up and let users match  SPC,
?, &, etc. (without quoting them with C-q).

IMO.