all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: <rms@gnu.org>
Cc: emacs-devel@gnu.org
Subject: RE: Icicles doc - file 1/2 (was: propose adding Icicles to Emacs)
Date: Sun, 17 Jun 2007 15:56:20 -0700	[thread overview]
Message-ID: <EIENLHALHGIMHGDOLMIMIEKJDCAA.drew.adams@oracle.com> (raw)
In-Reply-To: <E1I02cZ-0002tg-EW@fencepost.gnu.org>

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

  reply	other threads:[~2007-06-17 22:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <EIENLHALHGIMHGDOLMIMOEJADCAA.drew.adams@oracle.com>
2007-06-17 21:49 ` Icicles doc - file 1/2 (was: propose adding Icicles to Emacs) Richard Stallman
2007-06-17 21:49 ` Richard Stallman
2007-06-17 22:56   ` Drew Adams [this message]
2007-06-24 23:47     ` Richard Stallman
2007-06-25  2:59       ` Drew Adams
2007-06-24 23:47     ` Richard Stallman
2007-06-25  3:00       ` Drew Adams
2007-06-25 14:26         ` Icicles doc - file 1/2 Stefan Monnier
2007-06-25 15:23           ` Drew Adams
2007-06-25 15:46         ` Icicles doc - file 1/2 (was: propose adding Icicles to Emacs) Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=EIENLHALHGIMHGDOLMIMIEKJDCAA.drew.adams@oracle.com \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=rms@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.