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

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

[Richard Stallman]

    ;;  You can get the standard Emacs "prefix" completion, instead of=0A=
    ;;  this "apropos completion", by using `TAB' instead of `S-TAB'.  You=0A=
    ;;  can cycle prefix-completion candidates by using the `up' and=0A=
    ;;  `down' arrow keys instead of `next' and `prior'.=0A=

That feature conflicts with a standard one.  `up' and `down' in the
minibuffer move thru the history; that works for all minibuffer
arguments, with or without completion.

So if we are to install this feature, it needs to be on other keys.

    ;;   C-h f  c h a r  S-TAB - display all function names that contain=0A=
    ;;   `char'.=0A=
    ;;=0A=
    ;;   M-*  d e l e t e  - narrow that set of names to those that also=0A=
    ;;   contain `delete'.=0A=

I wonder if it would be more convenient to interpret
some syntax for this, such as `char&delete'

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

[Richard Stallman]

    ;;  You can get the standard Emacs "prefix" completion, instead of=0A=
    ;;  this "apropos completion", by using `TAB' instead of `S-TAB'.  You=0A=
    ;;  can cycle prefix-completion candidates by using the `up' and=0A=
    ;;  `down' arrow keys instead of `next' and `prior'.=0A=

That feature has a conflict.  `Up' and `down' in the minibuffer move
thru the history; that works for all minibuffer arguments, with or
without completion.  So if we are to install this feature, it needs
to be on other keys.

    ;;   C-h f  c h a r  S-TAB - display all function names that contain=0A=
    ;;   `char'.=0A=
    ;;=0A=
    ;;   M-*  d e l e t e  - narrow that set of names to those that also=0A=
    ;;   contain `delete'.=0A=

I wonder if it would be more convenient to interpret
some syntax for this, such as `char&delete'.

Meanwhile, it seems to me that Icicles completion is something like
Dired, and it might be useful to generalize it to allow marking
completion alternatives and unmarking them, so then you can say
"Operate on all of these".  That could be a lot more convenient than
submitting them one by one as arguments using the multi-command
feature.

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

[Drew Adams]

>     ;;  You can get the standard Emacs "prefix" completion, instead of
>     ;;  this "apropos completion", by using `TAB' instead of
>     ;; `S-TAB'.  You can cycle prefix-completion candidates by using
>     ;;  the `up' and `down' arrow keys instead of `next' and `prior'.
>
> That feature has a conflict.  `Up' and `down' in the minibuffer move
> thru the history; that works for all minibuffer arguments, with or
> without completion.  So if we are to install this feature, it needs
> to be on other keys.

I am aware of that conflict.

There are multiple keys assigned to history next and previous. I see no
reason why there are so many keys (6) consecrated to this. `M-n' and `M-p'
are still available for the history in Icicles (as in vanilla Emacs). This
is anyway configurable in Icicles. If you want to use different keys, you
can.

The same thing arises for `next' and `prior'. There is no need for `M-n',
`down', and `next' to all be bound to `next-history-element'. There is no
need for `M-p', `up', and `prior' to all be bound to
`previous-history-element'. That is overkill and wastes precious bindings.

You don't do that for `next-matching-history-element' - it has only one
binding: `M-s'. The same should be true, IMO, for `next-history-element':
only `M-n' (or whatever).

FYI - Icicles also has an option that makes the completion type modal. That
is, TAB and S-TAB then determine which completion type (prefix or apropos)
is used for cycling. In that mode, only two keys (e.g. `up' and `down' - the
keys are configurable) are needed for cycling and for history traversal, not
six (`up', `down', `next', `prior', `M-n', and `M-p'). When this option is
on, `up' and `down' are for history except after you use TAB or S-TAB, in
which case they cycle to the next candidate for prefix (TAB) or apropos
(S-TAB) completion.

This is not the default Icicles behavior, and I don't want it to be, but I
offer it for users who prefer that behavior.

See
http://www.emacswiki.org/cgi-bin/wiki/Icicles_-_Traversing_Minibuffer_Histor
ies about minibuffer history.

See
http://www.emacswiki.org/cgi-bin/wiki/Icicles_-_Customization_and_General_Ti
ps#icicle-cycling-respects-completion-mode-flag about the modal option for
cycling.

>     ;;   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 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. (Yes, I recognize that
`C-?' is not available in console mode, and that Emacs needs to also worry
about available console-mode keys.)

> Meanwhile, it seems to me that Icicles completion is something like
> Dired, and it might be useful to generalize it to allow marking
> completion alternatives and unmarking them, so then you can say
> "Operate on all of these".  That could be a lot more convenient than
> submitting them one by one as arguments using the multi-command
> feature.

It's not one or the other. Icicles is about completion; Dired is about file
management. Icicles is very general, so it is true that you can do some
things using Icicles completion that you can also do in Dired. In fact, I've
been told that some blind people prefer Icicles over Dired for some
file-management operations.

But Icicles is not Dired, and it should not try to be.

You can "mark" Icicles candidates and then act on those that are marked, if
you like. This was added recently, as I mentioned. You do that differently
in Icicles than in Dired. In Icicles, you hit `insert' to "mark" a
candidate. You can also "mark" all current candidates (that is, all that
match your current input).

"Marking" here really means saving the "marked" candidates to a variable
(or, optionally, to a cache file) - you retrieve the candidates when you
want to act on them (or on some of them). When you "mark" all of the current
candidates, you can choose to replace those already saved or add to them
with the new batch. When you "mark" an individual candidate, it is always
added to those already saved.

See http://www.emacswiki.org/cgi-bin/wiki/Icicles_-_Candidate_Sets about
"marking" and acting on selected candidates.

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

[Richard Stallman]

    > That feature has a conflict.  `Up' and `down' in the minibuffer move
    > thru the history; that works for all minibuffer arguments, with or
    > without completion.  So if we are to install this feature, it needs
    > to be on other keys.

    I am aware of that conflict.

    There are multiple keys assigned to history next and previous. I see no
    reason why there are so many keys (6) consecrated to this. `M-n' and `M-p'
    are still available for the history in Icicles (as in vanilla Emacs). This
    is anyway configurable in Icicles. If you want to use different keys, you
    can.

The reason for making UP and DOWN do this is for coherence with other
applications.  It is a valid and important reason.

So please look for other bindings for your new commands.

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

[Drew Adams]

>     > That feature has a conflict.  `Up' and `down' in the minibuffer move
>     > thru the history; that works for all minibuffer arguments, with or
>     > without completion.  So if we are to install this feature, it needs
>     > to be on other keys.
>
>     I am aware of that conflict.
>
>     There are multiple keys assigned to history next and
>     previous. I see no reason why there are so many keys (6)
>     consecrated to this. `M-n' and `M-p' are still available
>     for the history in Icicles (as in vanilla Emacs). This
>     is anyway configurable in Icicles. If you want to use
>     different keys, you can.
>
> The reason for making UP and DOWN do this is for coherence with other
> applications.  It is a valid and important reason.
>
> So please look for other bindings for your new commands.

I mentioned that this is configurable in Icicles. You can use any keys you
like for this Icicles feature, if you decide to add it to Emacs.

You can also decide, for instance, to adopt only the optional modal behavior
that some Icicles users prefer. In that case, you need only two keys for all
of: history cycling, prefix-completion cycling, and apropos-completion
cycling. The current mode determines the behavior of those two keys.

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

[Richard Stallman]

    >     ;;   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 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.

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

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

[Drew Adams]

>     >     ;;   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.

Re: Icicles doc - file 1/2

[Stefan Monnier]

> 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).


        Stefan

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.

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

[Richard Stallman]

    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 don't insist on this.  It's just a suggestion.

However, I am not going to bundle the deletion of the ? command
with the installation of these features.  If users generally would
prefer to turn ? into a normal character in completion, I will go
along with it, but that is a separate issue.