From: "Drew Adams" <drew.adams@oracle.com>
To: "'rusi'" <rustompmody@gmail.com>, <help-gnu-emacs@gnu.org>
Subject: RE: Icicles [was: shell command completion gone]
Date: Fri, 14 Jan 2011 08:48:20 -0800 [thread overview]
Message-ID: <E9199FE9CCBE4AEDB94AE3FD989C9C03@us.oracle.com> (raw)
In-Reply-To: <447122d6-c509-4c05-b438-c80b8eb32039@m11g2000vbs.googlegroups.com>
> > By default, `up' and `down' (arrows) in Icicles do not
> > cycle history entries. They cycle completion candidates...
>
> Yes I know
>
> > To cycle history entries use `M-n' and `M-p' (or change the
> > keys to suit yourself). This is all in the doc.
>
> Yes. I was just pointing out that that is not vanilla emacs -- your
> earlier point was that simply using icy-mode without customizations
> gives you vanilla behavior.
I did not say that. I said that if you use the usual keys in the minibuffer
then "you should hardly notice being in Icicle mode." To which I took the
trouble to point out that "`hardly' is not `never'", which is a caveat
recognizing that there are some differences.
`M-n' and `M-p' are standard keys for cycling history in vanilla Emacs. They
are the original keys for this, the most commonly documented keys for it, and
they work on nearly every keyboard. In Icicles too they cycle the input
history.
It is true that vanilla Emacs also assigns `down' and `up' for cycling history,
and Icicles assigns these keys, by default, to cycling candidates.
This is all documented. I wrote a fairly lengthy mail, but if you want a more
exact description then consult the doc. It doesn't help anyone to repeat such
details here, IMO.
But you say you already knew this about history cycling. So perhaps your point
was that I am misrepresenting things.
I think my representation was a fair and accurate general statement about a
typical user: if you stick to the usual keys in the minibuffer then you will
hardly notice being in Icicle mode. You are free to disagree.
> I see that the behavior is different than the last I saw. The icicles
> completion buffer is still around
The buffer has always been kept around. The *Completions* window is deleted,
that's all; the buffer is not killed. (Vanilla Emacs does not even remove the
window.)
My uninformed guess is that you have upgraded to a more recent Emacs version and
its choice of the buffer that is displayed when you kill a buffer has changed,
so that now you are more often seeing *Completions* displayed in the place of
some buffer that you have killed.
It is not Icicles that displays *Completions* then - Icicles is not "bringing it
up". *Completions* is just one existing buffer among others, and for some
reason Emacs now decides that it is the one it wants to display for you in the
window of a buffer that you killed.
It's possible that *Completions* should be buried when its window is deleted, to
reduce the possibility that it will be substituted for a killed buffer. Please
send a step-by-step bug report starting with emacs -Q, including your Emacs
version.
(I use a standalone *Completions* frame myself, so I don't see this problem.
And it has not been otherwise reported.)
> and still useless (bringing it up and clicking something
> in it gives me minibuffer is not active for completion)
Of course. There is no reason to click in it. Icicles is not "bringing it up".
It is just being shown in place of a buffer that you killed (IIUC). What you
want is for some other buffer to do that, not *Completions*. Send an exact
recipe and I'll take a look - sounds like a call to `bury-buffer' might be
needed.
> but it seems to be 'buried' deeper than earlier so it does
> not get so much in the way.
Now I'm confused. I thought you were describing a regression in behavior but
now it sounds like the behavior has actually improved. Anyway, send me a recipe
to reproduce what annoys you and I'll take a look.
> [Interestingly if I make the minibuffer active say with a M-x and then
> click one of the (earlier) completion entries I get args out of range]
The old content of the *Completions* buffer is of course useless (except for
reference, to see what the candidates were for your last use), as you pointed
out. You should not expect behavior different from what you describe in this
regard. On the other hand, if you hit TAB after M-x then *Completions* should
be correctly updated to show the current candidates.
HTH.
next prev parent reply other threads:[~2011-01-14 16:48 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-07 6:45 shell command completion gone prad
2011-01-07 16:14 ` Drew Adams
2011-01-08 4:02 ` prad
[not found] ` <mailman.0.1294459339.1472.help-gnu-emacs@gnu.org>
2011-01-08 17:37 ` rusi
2011-01-08 22:11 ` prad
2011-01-11 4:54 ` Le Wang
2011-01-11 23:21 ` Icicles [was: shell command completion gone] Drew Adams
2011-01-12 7:17 ` Icicles prad
2011-01-12 15:45 ` Icicles Drew Adams
[not found] ` <mailman.2.1294788149.12535.help-gnu-emacs@gnu.org>
2011-01-12 5:10 ` Icicles [was: shell command completion gone] rusi
2011-01-12 15:45 ` Drew Adams
2011-01-14 7:30 ` Rustom Mody
2011-01-14 9:04 ` Drew Adams
[not found] ` <mailman.16.1294995951.15276.help-gnu-emacs@gnu.org>
2011-01-14 9:34 ` rusi
2011-01-14 16:48 ` Drew Adams [this message]
2011-01-15 1:32 ` Darth Emacs
2011-01-16 19:56 ` Drew Adams
2011-01-19 0:29 ` Darth Emacs
2011-01-17 3:59 ` rusi
2011-01-17 17:35 ` Drew Adams
[not found] ` <mailman.13.1294990220.15276.help-gnu-emacs@gnu.org>
2011-01-14 7:33 ` rusi
2011-01-21 4:12 ` rusi
2011-01-21 5:18 ` Le Wang
2011-01-21 15:48 ` Drew Adams
[not found] ` <mailman.10.1295587091.21031.help-gnu-emacs@gnu.org>
2011-01-21 5:24 ` rusi
2011-01-21 15:33 ` Drew Adams
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=E9199FE9CCBE4AEDB94AE3FD989C9C03@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=help-gnu-emacs@gnu.org \
--cc=rustompmody@gmail.com \
/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.