GNU bug report logs - #11983
24.1; Electric-command-loop broken?

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: "Roland Winkler" <winkler@HIDDEN>; dated Wed, 18 Jul 2012 21:02:01 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 11983 <at> debbugs.gnu.org:


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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#11983; Package emacs. Full text available.

Message received at 11983 <at> debbugs.gnu.org:


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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#11983; Package emacs. Full text available.

Message received at 11983 <at> debbugs.gnu.org:


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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#11983; Package emacs. Full text available.

Message received at 11983 <at> debbugs.gnu.org:


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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#11983; Package emacs. Full text available.

Message received at 11983 <at> debbugs.gnu.org:


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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#11983; Package emacs. Full text available.

Message received at 11983 <at> debbugs.gnu.org:


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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#11983; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


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




Acknowledgement sent to "Roland Winkler" <winkler@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#11983; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Fri, 31 Oct 2014 17:00:04 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.