From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Darth Emacs Newsgroups: gmane.emacs.help Subject: Re: Icicles [was: shell command completion gone] Date: Fri, 14 Jan 2011 18:32:33 -0700 Message-ID: References: <87pqs9cive.fsf@towardsfreedom.com> <87aajbxcz0.fsf@towardsfreedom.com> <9df7037c-e4d3-4a1b-9fcf-f130853de421@a10g2000vby.googlegroups.com> <447122d6-c509-4c05-b438-c80b8eb32039@m11g2000vbs.googlegroups.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=000e0cd32ada5d6a440499d886bb X-Trace: dough.gmane.org 1295104186 31203 80.91.229.12 (15 Jan 2011 15:09:46 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 15 Jan 2011 15:09:46 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: Drew Adams Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Jan 15 16:09:41 2011 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Pe7kH-0004yk-23 for geh-help-gnu-emacs@m.gmane.org; Sat, 15 Jan 2011 16:09:41 +0100 Original-Received: from localhost ([127.0.0.1]:47778 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pe7kA-00035M-6e for geh-help-gnu-emacs@m.gmane.org; Sat, 15 Jan 2011 10:08:42 -0500 Original-Received: from [140.186.70.92] (port=50813 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pdv0U-0000fF-5i for help-gnu-emacs@gnu.org; Fri, 14 Jan 2011 20:33:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pdv0N-0007IU-B0 for help-gnu-emacs@gnu.org; Fri, 14 Jan 2011 20:32:40 -0500 Original-Received: from mail-pw0-f67.google.com ([209.85.160.67]:60817) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pdv0N-0007H5-17 for help-gnu-emacs@gnu.org; Fri, 14 Jan 2011 20:32:35 -0500 Original-Received: by pwi3 with SMTP id 3so246268pwi.6 for ; Fri, 14 Jan 2011 17:32:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ojhWFpJipl/Lt/+ELM561Ahu7FkCIO+eLqHdR4Jz4PM=; b=rlQtCpVL6gSLFOaUAdH4P02akyxG03rbpWsJqN43Uam2PR1ULU5OFtGBdyuUXCsgth bQRv45HOej+my3k9MkFefygSxmt6oNi+f4SHPoXwnrIB5mSS1BoOh60DWvvu/KQbvmhh +vlTOMHiSVxtHEZuVveIL7MqWAN1eSmKskvpA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Z81Uh5OSrEPrEDYlXh/HCCPEOsRtRJhRSEllo2qUlAvNxBWA7pc8Oc+UbdQ45ucNGz SyiZRTV7G1Z5/hlL4Z86LQmEtXEy/4XtU+yCoXha8aHQ3n7C/RGGayvkmIj5bd62X4JA aX+aiQkeo+KA8UXC84NUjRoLYLkm9iqbXWoeA= Original-Received: by 10.142.229.16 with SMTP id b16mr1176309wfh.14.1295055153095; Fri, 14 Jan 2011 17:32:33 -0800 (PST) Original-Received: by 10.143.169.2 with HTTP; Fri, 14 Jan 2011 17:32:33 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Mailman-Approved-At: Sat, 15 Jan 2011 10:07:50 -0500 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:78472 Archived-At: --000e0cd32ada5d6a440499d886bb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Drew, By any chance could I talk you into posting your Icicles bindings. I would enjoy getting a feel of how you think Icicles works best. Best regards, Darth Emacs On Fri, Jan 14, 2011 at 9:48 AM, Drew Adams wrote: > > > 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 th= e > 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 remov= e > 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 plac= e > 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 som= e > reason Emacs now decides that it is the one it wants to display for you i= n > 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 Ema= cs > 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 exa= ct > recipe and I'll take a look - sounds like a call to `bury-buffer' might b= e > 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. > > > --=20 * Darth Emacs * =93Duct tape is like the force. It has a light side, a dark side, and it ho= lds the universe together. =94 --000e0cd32ada5d6a440499d886bb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Drew,
=A0
By any chance could I talk you into posting your Icicles bindings. I w= ould enjoy getting a feel of how you think Icicles works best.
=A0
Best regards,
Darth Emacs

On Fri, Jan 14, 2011 at 9:48 AM, Drew Adams <drew.adams@oracl= e.com> wrote:
> > By default, `up' and `down' (arrows) in= Icicles do not
> > cycle history entries. =A0They cycle com= pletion candidates...
>
> Yes I know
>
> > To cycle his= tory entries use `M-n' and `M-p' (or change the
> > keys t= o suit yourself). =A0This is all in the doc.
>
> Yes. I was jus= t 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. =A0I sai= d that if you use the usual keys in the minibuffer
then "you should= hardly notice being in Icicle mode." =A0To which I took the
trouble to point out that "`hardly' is not `never'", whic= h is a caveat
recognizing that there are some differences.

`M-n&#= 39; and `M-p' are standard keys for cycling history in vanilla Emacs. = =A0They
are the original keys for this, the most commonly documented keys for it, a= nd
they work on nearly every keyboard. =A0In Icicles too they cycle the = input
history.

It is true that vanilla Emacs also assigns `down&#= 39; and `up' for cycling history,
and Icicles assigns these keys, by default, to cycling candidates.

T= his is all documented. =A0I wrote a fairly lengthy mail, but if you want a = more
exact description then consult the doc. =A0It doesn't help anyo= ne to repeat such
details here, IMO.

But you say you already knew this about history c= ycling. =A0So perhaps your point
was that I am misrepresenting things.
I think my representation was a fair and accurate general statement a= bout a
typical user: if you stick to the usual keys in the minibuffer then you wil= l
hardly notice being in Icicle mode. =A0You are free to disagree.

> I see that the behavior is different than the la= st I saw. =A0The icicles
> completion buffer is still around

<= /div>The buffer has always been kept around. =A0The *Completions* window is= deleted,
that's all; the buffer is not killed. =A0(Vanilla Emacs does not even r= emove the
window.)

My uninformed guess is that you have upgraded = to a more recent Emacs version and
its choice of the buffer that is disp= layed 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 displ= ays *Completions* then - Icicles is not "bringing it
up". =A0*= 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 *C= ompletions* should be buried when its window is deleted, to
reduce the p= ossibility that it will be substituted for a killed buffer. =A0Please
send a step-by-step bug report starting with emacs -Q, including your Emacs=
version.

(I use a standalone *Completions* frame myself, so I do= n't see this problem.
And it has not been otherwise reported.)

> and still useless (bringing it up and clicking s= omething
> in it gives me minibuffer is not active for completion)
Of course. =A0There is no reason to click in it. =A0Icicles is n= ot "bringing it up".
It is just being shown in place of a buffer that you killed (IIUC). =A0What= you
want is for some other buffer to do that, not *Completions*. =A0Sen= d 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&#= 39;m confused. =A0I thought you were describing a regression in behavior bu= t
now it sounds like the behavior has actually improved. =A0Anyway, send me a= recipe
to reproduce what annoys you and I'll take a look.

> [Interestingly if I make the minibuffer active s= ay with a M-x and then
> click one of the (earlier) completion entrie= s 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 point= ed
out. =A0You should not expect behavior different from what you descri= be in this
regard. =A0On the other hand, if you hit TAB after M-x then *= Completions* should
be correctly updated to show the current candidates.

HTH.




--
=A0Darth Emacs
=A0

--000e0cd32ada5d6a440499d886bb--