RE: Icicles doc - file 1/2 (was: propose adding Icicles to Emacs)

["Drew Adams" <drew.adams@oracle.com>]

>     >     ;;   C-h f  c h a r  S-TAB - display all function names that
>     >     ;;   contain `char'.
>     >     ;;
>     >     ;;   M-*  d e l e t e  - narrow that set of names to those
>     >     ;;   that also contain `delete'.
>     >
>     > I wonder if it would be more convenient to interpret
>     > some syntax for this, such as `char&delete'.
>
>     I don't think so, but perhaps I don't fully see what you're
>     proposing. You can type `char S-SPC delete' to do the same
>     thing. A priori, I am against using printable characters such
>     as `&' for this kind of thing.
>
> I think it would be more convenient to use `char&delete'
> because that way the minibuffer contents would SHOW the search criterion.

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.

In Icicles, minibuffer input can be used for anything and everything - it's
not just about file names, buffer names, command names, and variable names
anymore. Every printable character will be something that you want to
include in minibuffer input sooner or later. And it would be a big mistake
(IMO) to make users remember a list of characters that you need to apply
`C-q' to in the minibuffer.

FWIW, I think that if you use Icicles a bit, you'll see that there is no
need to "SHOW the search criteria". The one, basic Icicles feature that all
users pick up right away and use all the time thereafter is this one, which
I call "progressive completion". There really is no need to see the
accumulated set-operation expression (e.g. char & delete, where & means
intersect). Instead, users see the set itself as it is shaped, and they
think directly in terms of it. Being interactive, it is easy to manipulate
and redo things, if you get the wrong expression at some point and thus end
up with a candidate set that you didn't expect.

FWIW2 - If it was nevertheless felt that users should be able to see a
breadcrumbs trace of the candidate-set operations they have performed so
far, then the place to show that is in another buffer, as a clear, formatted
display - not in the minibuffer as part of the user's input. IMO.

>     I avoid wasting normal editing keys and printable-character
>     keys in the minibuffer. In Icicles, for instance, `?' is
>     simply self-inserting (always) - it is `C-?' that brings up
>     Icicles help.
>
> I do not want to remove the minibuffer's binding of `?'.
> Adding one new feature is not a reason to delete another old feature.

Same answer as for `&'. In Icicles outside Emacs, I'll keep `?' as a normal,
self-inserting character for minibuffer editing. You can use whatever you
prefer for any Icicles features you adapt for inclusion in Emacs.

Again, Icicles uses completion a lot more than vanilla Emacs - for more
things in more contexts. There is no reason not to let users use keys such
as `&' and `?' (without escaping/quoting) in ordinary minibuffer editing,
i.e. in minibuffer input.

> Icicles makes many different changes which are logically independent,
> and each one needs to be judged separately.

Fine. I already stated the same thing. I said that many of the features are
not strictly logically interdependent, even when (I think) they belong
together because they complement each other and work well together. Please
judge them separately for possible adapted inclusion in Emacs as you see
fit.