Received: (at 11983) by debbugs.gnu.org; 20 Jul 2012 12:44:33 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 20 08:44:33 2012 Received: from localhost ([127.0.0.1]:52060 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1SsCZN-0004wL-0Y for submit <at> debbugs.gnu.org; Fri, 20 Jul 2012 08:44:33 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:49549) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <winkler@HIDDEN>) id 1SsCZK-0004wE-Tx for 11983 <at> debbugs.gnu.org; Fri, 20 Jul 2012 08:44:31 -0400 Received: from lukas.physics.niu.edu ([131.156.85.221]:53328) by fencepost.gnu.org with esmtpa (Exim 4.71) (envelope-from <winkler@HIDDEN>) id 1SsCTF-0000Po-LN; Fri, 20 Jul 2012 08:38:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20489.20788.573738.502819@HIDDEN> Date: Fri, 20 Jul 2012 07:38:12 -0500 From: "Roland Winkler" <winkler@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#11983: 24.1; Electric-command-loop broken? In-Reply-To: <jwvfw8mocza.fsf-monnier+emacs@HIDDEN> References: <87pq7s6b8q.fsf@HIDDEN> <jwv7gu0upar.fsf-monnier+emacs@HIDDEN> <20488.31825.986146.195944@HIDDEN> <jwvpq7qpz9d.fsf-monnier+emacs@HIDDEN> <20489.13911.18062.669102@HIDDEN> <jwvfw8mocza.fsf-monnier+emacs@HIDDEN> X-Mailer: VM 8.2 trial under 24.1.1 (x86_64-unknown-linux-gnu) X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11983 Cc: 11983 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -6.9 (------) On Fri Jul 20 2012 Stefan Monnier wrote: > > I do not know much about recursive-edit. How would you use it as a > > replacement for the above to be sure that after leaving > > recursive-edit cleanup-form is always executed? > > (unwind-protect > (recursive-edit) > (cleanup-form)) Ah, thanks, that's indeed not more complicated either. > The issue is not that the buffer is not reset when you return from > electric-buffer-list, but that during electric-buffer-list if you select > some other window you do not exit electric-buffer-list and the keys end > up behaving weird (e.g. typing "c" in a normal buffer will insert "c" > and then move to EOB or something like that). Once you exit from > electric-buffer-list, things are back to normal. In BBDB this issue has been address by making relevant commands electric: any command that is intended to quit the electric command loop (in the context of electric-buffer-list this could mean: you select another buffer to work with) will throw 'return-tag. Then you can continue normally. Of course, this means: the code needs to provide electric versions of all relevant commands. If the user still decides to do something else, the result is undefined. > What I'm saying is that it's tricky to use Electric-command-loop without > introducing bugs because Electric-command-loop presumes that all > operations will stay within the current buffer, but it does not (help > to) try to enforce it. So it's a poor API. I do not disagree here. I got into all this business because the Electric-command-loop has been present in old versions of BBDB. But I would not miss it, if it disappeared. (I do not even know whether any other BBDB user would miss it. I'll ask on the BBDB mailing list.) Roland
bug-gnu-emacs@HIDDEN:bug#11983; Package emacs.
Full text available.
Received: (at 11983) by debbugs.gnu.org; 20 Jul 2012 12:16:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 20 08:16:04 2012
Received: from localhost ([127.0.0.1]:52016 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1SsC7n-0004H7-FR
for submit <at> debbugs.gnu.org; Fri, 20 Jul 2012 08:16:03 -0400
Received: from chene.dit.umontreal.ca ([132.204.246.20]:53501)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <monnier@HIDDEN>) id 1SsC7l-0004Gj-Be
for 11983 <at> debbugs.gnu.org; Fri, 20 Jul 2012 08:16:02 -0400
Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca
[132.204.27.242])
by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id q6KC9goI021075;
Fri, 20 Jul 2012 08:09:43 -0400
Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848)
id A4806AECB8; Fri, 20 Jul 2012 08:09:41 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: "Roland Winkler" <winkler@HIDDEN>
Subject: Re: bug#11983: 24.1; Electric-command-loop broken?
Message-ID: <jwvfw8mocza.fsf-monnier+emacs@HIDDEN>
References: <87pq7s6b8q.fsf@HIDDEN> <jwv7gu0upar.fsf-monnier+emacs@HIDDEN>
<20488.31825.986146.195944@HIDDEN>
<jwvpq7qpz9d.fsf-monnier+emacs@HIDDEN>
<20489.13911.18062.669102@HIDDEN>
Date: Fri, 20 Jul 2012 08:09:41 -0400
In-Reply-To: <20489.13911.18062.669102@HIDDEN> (Roland
Winkler's message of "Fri, 20 Jul 2012 05:43:35 -0500")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 5
X-NAI-Spam-Score: 0
X-NAI-Spam-Rules: 1 Rules triggered
RV4284=0
X-NAI-Spam-Version: 2.2.0.9309 : core <4284> : streams <787671> : uri <1170215>
X-Spam-Score: -3.5 (---)
X-Debbugs-Envelope-To: 11983
Cc: 11983 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -3.5 (---)
>> > (unwind-protect
>> > (catch 'return-tag
>> > (Electric-command-loop 'return-tag))
>> > (cleanup-form))
>> But in which way is this different from `recursive-edit'?
> I do not know much about recursive-edit. How would you use it as a
> replacement for the above to be sure that after leaving
> recursive-edit cleanup-form is always executed?
(unwind-protect
(recursive-edit)
(cleanup-form))
>> It seems that it requires a fair bit of extra surrounding code to
>> use it right. E.g. electric-buffer-list is buggy because it lacks
>> this extra code: after popping up the electric-buffer-list, you
>> can select some other window and work there, but the behavior is
>> then all messed up.
> The amount of protection provided by an Electric-command-loop
> depends on the surrounding code (save-excursion,
> save-window-excursion, etc.)
The issue is not that the buffer is not reset when you return from
electric-buffer-list, but that during electric-buffer-list if you select
some other window you do not exit electric-buffer-list and the keys end
up behaving weird (e.g. typing "c" in a normal buffer will insert "c"
and then move to EOB or something like that). Once you exit from
electric-buffer-list, things are back to normal.
> I believe that the intended usage pattern of Electric-command-loop
> does not include too wild things such as selecting other windows. Or
> phrased differently: of course, you can always do whatever you
> like. But only cleanup-form is definitely evaluated at the end.
What I'm saying is that it's tricky to use Electric-command-loop without
introducing bugs because Electric-command-loop presumes that all
operations will stay within the current buffer, but it does not (help
to) try to enforce it. So it's a poor API.
Stefan
bug-gnu-emacs@HIDDEN:bug#11983; Package emacs.
Full text available.Received: (at 11983) by debbugs.gnu.org; 20 Jul 2012 10:49:58 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 20 06:49:58 2012 Received: from localhost ([127.0.0.1]:51875 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1SsAmT-0001X2-SX for submit <at> debbugs.gnu.org; Fri, 20 Jul 2012 06:49:58 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:47535) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <winkler@HIDDEN>) id 1SsAmO-0001Ws-KO for 11983 <at> debbugs.gnu.org; Fri, 20 Jul 2012 06:49:53 -0400 Received: from lukas.physics.niu.edu ([131.156.85.221]:53276) by fencepost.gnu.org with esmtpa (Exim 4.71) (envelope-from <winkler@HIDDEN>) id 1SsAgJ-0002qd-MD; Fri, 20 Jul 2012 06:43:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20489.13911.18062.669102@HIDDEN> Date: Fri, 20 Jul 2012 05:43:35 -0500 From: "Roland Winkler" <winkler@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#11983: 24.1; Electric-command-loop broken? In-Reply-To: <jwvpq7qpz9d.fsf-monnier+emacs@HIDDEN> References: <87pq7s6b8q.fsf@HIDDEN> <jwv7gu0upar.fsf-monnier+emacs@HIDDEN> <20488.31825.986146.195944@HIDDEN> <jwvpq7qpz9d.fsf-monnier+emacs@HIDDEN> X-Mailer: VM 8.2 trial under 24.1.1 (x86_64-unknown-linux-gnu) X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11983 Cc: 11983 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -6.9 (------) On Fri Jul 20 2012 Stefan Monnier wrote: > > (unwind-protect > > (catch 'return-tag > > (Electric-command-loop 'return-tag)) > > (cleanup-form)) > > But in which way is this different from `recursive-edit'? I do not know much about recursive-edit. How would you use it as a replacement for the above to be sure that after leaving recursive-edit cleanup-form is always executed? > It seems that it requires a fair bit of extra surrounding code to > use it right. E.g. electric-buffer-list is buggy because it lacks > this extra code: after popping up the electric-buffer-list, you > can select some other window and work there, but the behavior is > then all messed up. The amount of protection provided by an Electric-command-loop depends on the surrounding code (save-excursion, save-window-excursion, etc.) I believe that the intended usage pattern of Electric-command-loop does not include too wild things such as selecting other windows. Or phrased differently: of course, you can always do whatever you like. But only cleanup-form is definitely evaluated at the end. Roland
bug-gnu-emacs@HIDDEN:bug#11983; Package emacs.
Full text available.
Received: (at 11983) by debbugs.gnu.org; 20 Jul 2012 09:54:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 20 05:54:04 2012
Received: from localhost ([127.0.0.1]:51835 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1Ss9uO-00006L-73
for submit <at> debbugs.gnu.org; Fri, 20 Jul 2012 05:54:04 -0400
Received: from pruche.dit.umontreal.ca ([132.204.246.22]:38786)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <monnier@HIDDEN>) id 1Ss9uL-00005m-SZ
for 11983 <at> debbugs.gnu.org; Fri, 20 Jul 2012 05:54:02 -0400
Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca
[132.204.27.242])
by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id q6K9lgC0017809;
Fri, 20 Jul 2012 05:47:43 -0400
Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848)
id AA994AECB8; Fri, 20 Jul 2012 05:47:40 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: "Roland Winkler" <winkler@HIDDEN>
Subject: Re: bug#11983: 24.1; Electric-command-loop broken?
Message-ID: <jwvpq7qpz9d.fsf-monnier+emacs@HIDDEN>
References: <87pq7s6b8q.fsf@HIDDEN> <jwv7gu0upar.fsf-monnier+emacs@HIDDEN>
<20488.31825.986146.195944@HIDDEN>
Date: Fri, 20 Jul 2012 05:47:40 -0400
In-Reply-To: <20488.31825.986146.195944@HIDDEN> (Roland Winkler's
message of "Thu, 19 Jul 2012 16:29:53 -0500")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 5
X-NAI-Spam-Score: 0
X-NAI-Spam-Rules: 1 Rules triggered
RV4284=0
X-NAI-Spam-Version: 2.2.0.9309 : core <4284> : streams <787605> : uri <1170125>
X-Spam-Score: -3.5 (---)
X-Debbugs-Envelope-To: 11983
Cc: 11983 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -3.5 (---)
> (unwind-protect
> (catch 'return-tag
> (Electric-command-loop 'return-tag))
> (cleanup-form))
But in which way is this different from `recursive-edit'?
Hmmm... I guess it is different in that it is easier to exit an
Electric-command-loop than a recursive-edit, so it is like
a "transient/lightweight" recursive-edit.
I think it would be good to try to describe it by comparing it to
recursive-edit.
It seems that it requires a fair bit of extra surrounding code to use it
right. E.g. electric-buffer-list is buggy because it lacks this extra
code: after popping up the electric-buffer-list, you can select some
other window and work there, but the behavior is then all
messed up.
>> > - The doc string says
>> > ;; Given third argument non-nil, it
>> > ;; INHIBITS quitting unless the user types C-g at toplevel. This is
>> > ;; so user can do things like C-u C-g and not get thrown out.
>> > Yet it appears to me, that even for C-u C-g the user gets thrown out.
>>
>> I have no idea what this "C-u C-g" refers to, indeed.
> If you type a plain C-g, Electric-command-loop throws
> 'return-tag. Now the idea is that if you type C-u, then you
> change your mind and want to cancel it by typing C-g, then the
> code should not leave the temporary command loop.
I see, yes. This inhibit-quitting seems dangerous since it binds
inhibit-quit. But yes, I see in the code it tries to handle C-g after
some prefix key. Not sure why it now fails or whether it ever worked.
Stefan
bug-gnu-emacs@HIDDEN:bug#11983; Package emacs.
Full text available.
Received: (at 11983) by debbugs.gnu.org; 19 Jul 2012 21:36:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jul 19 17:36:13 2012
Received: from localhost ([127.0.0.1]:51337 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1SryOK-0000OD-Uo
for submit <at> debbugs.gnu.org; Thu, 19 Jul 2012 17:36:13 -0400
Received: from fencepost.gnu.org ([208.118.235.10]:57925)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <winkler@HIDDEN>) id 1SryOI-0000O5-DJ
for 11983 <at> debbugs.gnu.org; Thu, 19 Jul 2012 17:36:11 -0400
Received: from pchdb00005.uni-regensburg.de ([132.199.129.10]:40285
helo=regnitz)
by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16)
(Exim 4.71) (envelope-from <winkler@HIDDEN>)
id 1SryIG-0002GK-DR; Thu, 19 Jul 2012 17:29:56 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <20488.31825.986146.195944@HIDDEN>
Date: Thu, 19 Jul 2012 16:29:53 -0500
From: "Roland Winkler" <winkler@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#11983: 24.1; Electric-command-loop broken?
In-Reply-To: <jwv7gu0upar.fsf-monnier+emacs@HIDDEN>
References: <87pq7s6b8q.fsf@HIDDEN>
<jwv7gu0upar.fsf-monnier+emacs@HIDDEN>
X-Mailer: VM 8.2 trial under 24.1.1 (x86_64-unknown-linux-gnu)
X-Spam-Score: -6.9 (------)
X-Debbugs-Envelope-To: 11983
Cc: 11983 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -6.9 (------)
On Thu Jul 19 2012 Stefan Monnier wrote:
> The best I could understand of what it's trying to do is summarized in
> the commentary I added:
>
> ;; - electric modes and buffers: modes that typically pop-up in a
> ;; modal kind of way a transient buffer that automatically
> ;; disappears as soon as the user is done with it.
>
> > (this is used by BBDB 3):
>
> Could you maybe then describe the expected behavior, from the user's
> point of view? Adding docstrings, and/or improving comments would be
> very welcome.
My understanding of this is the following (better suggestions
welcome):
Imagine you have an unwind-protect form. It allows you to execute
whatever noninteractive code, and you can be sure that in the end
it executes cleanup-form. Now imagine you want to do the same
thing interactively: you want to run some commands interactively,
and in the end you want to be sure you execute cleanup-form, no
matter what happens. The code for this is
(unwind-protect
(catch 'return-tag
(Electric-command-loop 'return-tag))
(cleanup-form))
Electric-command-loop throws 'return-tag if you type
C-g (keyboard-quit). Or you can make commands electric by letting
them throw 'return-tag. But any other command is executed inside
the temporary command loop implemented by Electric-command-loop
without ever leaving this loop. In particular, this temporary
command loop catches all errors that do not throw 'return-tag.
So in short: Electric-command-loop allows one to execute commands
in an `unwind-protect'ed temporary command loop.
Maybe there is a simpler way to implement such a functionality.
A typical application is suggested by the function
Electric-pop-up-window which pops up a window fairly aggresively
(see bug#11985): You quickly execute some command in the electric
window. When you are done, this code guarantees that cleanup-form
gets executed.
> > - The doc string says
> > ;; Given third argument non-nil, it
> > ;; INHIBITS quitting unless the user types C-g at toplevel. This is
> > ;; so user can do things like C-u C-g and not get thrown out.
> > Yet it appears to me, that even for C-u C-g the user gets thrown out.
>
> I have no idea what this "C-u C-g" refers to, indeed.
If you type a plain C-g, Electric-command-loop throws
'return-tag. Now the idea is that if you type C-u, then you
change your mind and want to cancel it by typing C-g, then the
code should not leave the temporary command loop.
bug-gnu-emacs@HIDDEN:bug#11983; Package emacs.
Full text available.
Received: (at 11983) by debbugs.gnu.org; 19 Jul 2012 09:17:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jul 19 05:17:49 2012
Received: from localhost ([127.0.0.1]:49527 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1Srmrl-0004U6-Et
for submit <at> debbugs.gnu.org; Thu, 19 Jul 2012 05:17:49 -0400
Received: from pruche.dit.umontreal.ca ([132.204.246.22]:35396)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <monnier@HIDDEN>) id 1Srmrj-0004Tz-A1
for 11983 <at> debbugs.gnu.org; Thu, 19 Jul 2012 05:17:47 -0400
Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca
[132.204.27.242])
by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id q6J9BZHd005139;
Thu, 19 Jul 2012 05:11:35 -0400
Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848)
id F3778AE20D; Thu, 19 Jul 2012 04:40:43 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: "Roland Winkler" <winkler@HIDDEN>
Subject: Re: bug#11983: 24.1; Electric-command-loop broken?
Message-ID: <jwv7gu0upar.fsf-monnier+emacs@HIDDEN>
References: <87pq7s6b8q.fsf@HIDDEN>
Date: Thu, 19 Jul 2012 04:40:43 -0400
In-Reply-To: <87pq7s6b8q.fsf@HIDDEN> (Roland Winkler's message of "Wed, 18
Jul 2012 15:54:45 -0500")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 5
X-NAI-Spam-Score: 0
X-NAI-Spam-Rules: 1 Rules triggered
RV4283=0
X-NAI-Spam-Version: 2.2.0.9309 : core <4283> : streams <787121> : uri <1169177>
X-Spam-Score: -3.5 (---)
X-Debbugs-Envelope-To: 11983
Cc: 11983 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -3.5 (---)
> I am trying to understand Electric-command-loop in electric.el
I do not understand what it's trying to do, let alone how it's trying to
do it.
The best I could understand of what it's trying to do is summarized in
the commentary I added:
;; - electric modes and buffers: modes that typically pop-up in a modal kind of
;; way a transient buffer that automatically disappears as soon as the user
;; is done with it.
> (this is used by BBDB 3):
Could you maybe then describe the expected behavior, from the user's
point of view? Adding docstrings, and/or improving comments would be
very welcome.
> - The code contains a hard-coded
> (setq universal-argument-num-events 0)
> Apparently this is never reset, so exiting Electric-command-loop
> leaves behind this binding.
It's a global var used by `universal-argument'.
`universal-argument' is implemented in a rather intricate way, part of
which is actually hidden deep in the C code.
universal-argument-num-events is used for when you finish a C-u sequence
to find which keys are part of the universal argument and which keys are
part of the actual command you wan to run.
`universal-argument' should really use something like
set-temporary-overlay-map instead so it wouldn't need
universal-argument-other-key and neither would it have to fiddle with
unread-command-events.
> - The doc string says
> ;; Given third argument non-nil, it
> ;; INHIBITS quitting unless the user types C-g at toplevel. This is
> ;; so user can do things like C-u C-g and not get thrown out.
> Yet it appears to me, that even for C-u C-g the user gets thrown out.
I have no idea what this "C-u C-g" refers to, indeed.
Stefan
bug-gnu-emacs@HIDDEN:bug#11983; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 18 Jul 2012 21:01:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 18 17:01:02 2012
Received: from localhost ([127.0.0.1]:49015 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1SrbMj-0008UX-Sb
for submit <at> debbugs.gnu.org; Wed, 18 Jul 2012 17:01:02 -0400
Received: from eggs.gnu.org ([208.118.235.92]:60181)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <winkler@HIDDEN>) id 1SrbMi-0008UK-K6
for submit <at> debbugs.gnu.org; Wed, 18 Jul 2012 17:01:01 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <winkler@HIDDEN>) id 1SrbGl-0004Rv-Aq
for submit <at> debbugs.gnu.org; Wed, 18 Jul 2012 16:54:53 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level:
X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI,
T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.2
Received: from lists.gnu.org ([208.118.235.17]:54304)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from <winkler@HIDDEN>) id 1SrbGl-0004Rj-7i
for submit <at> debbugs.gnu.org; Wed, 18 Jul 2012 16:54:51 -0400
Received: from eggs.gnu.org ([208.118.235.92]:50691)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from <winkler@HIDDEN>) id 1SrbGk-0001Pl-6F
for bug-gnu-emacs@HIDDEN; Wed, 18 Jul 2012 16:54:51 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <winkler@HIDDEN>) id 1SrbGj-0004RO-2l
for bug-gnu-emacs@HIDDEN; Wed, 18 Jul 2012 16:54:50 -0400
Received: from fencepost.gnu.org ([208.118.235.10]:47873)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from <winkler@HIDDEN>) id 1SrbGi-0004RK-Vb
for bug-gnu-emacs@HIDDEN; Wed, 18 Jul 2012 16:54:49 -0400
Received: from dhcp207152.uni-regensburg.de ([132.199.207.152]:55282
helo=regnitz)
by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16)
(Exim 4.71) (envelope-from <winkler@HIDDEN>) id 1SrbGi-0007ZL-Cs
for bug-gnu-emacs@HIDDEN; Wed, 18 Jul 2012 16:54:48 -0400
Date: Wed, 18 Jul 2012 15:54:45 -0500
Message-Id: <87pq7s6b8q.fsf@HIDDEN>
From: "Roland Winkler" <winkler@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 24.1; Electric-command-loop broken?
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3)
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3)
X-Received-From: 208.118.235.17
X-Spam-Score: -6.9 (------)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -6.9 (------)
I am trying to understand Electric-command-loop in electric.el
(this is used by BBDB 3):
Two things:
- The code contains a hard-coded
(setq universal-argument-num-events 0)
Apparently this is never reset, so exiting Electric-command-loop
leaves behind this binding.
- The doc string says
;; Given third argument non-nil, it
;; INHIBITS quitting unless the user types C-g at toplevel. This is
;; so user can do things like C-u C-g and not get thrown out.
Yet it appears to me, that even for C-u C-g the user gets thrown out.
Here is a slightly simplified version of the code from Electric-command-loop
It does not distinguish between C-g and C-u C-g.
Unfortunately, this hackery goes beyond my understanding of Emacs
internals.
(catch 'return-tag
(let (cmd (inhibit-quit t))
(while t
(setq cmd (read-key-sequence "Prompt: "))
(setq last-command-event (aref cmd (1- (length cmd)))
this-command (key-binding cmd t)
cmd this-command)
;; This makes universal-argument-other-key work.
(setq universal-argument-num-events 0)
(if (or (prog1 quit-flag (setq quit-flag nil))
(eq last-input-event ?\C-g))
(progn (setq unread-command-events nil
prefix-arg nil)
;; If it wasn't canceling a prefix character, then quit.
(if (or (= (length (this-command-keys)) 1)
(not inhibit-quit)) ; safety
(throw 'return-tag (this-command-keys))
(setq cmd nil))))
(setq current-prefix-arg prefix-arg)
(condition-case nil
(progn (command-execute cmd)
(setq last-command this-command))
(error nil)))))
In GNU Emacs 24.1.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.1)
of 2012-06-10 on regnitz
Windowing system distributor `The X.Org Foundation', version 11.0.10706000
"Roland Winkler" <winkler@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#11983; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.