GNU logs - #11983, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#11983: 24.1; Electric-command-loop broken?
Resent-From: "Roland Winkler" <winkler@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 18 Jul 2012 21:02:01 +0000
Resent-Message-ID: <handler.11983.B.134264526232659 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 11983 <at> debbugs.gnu.org
Date: Wed, 18 Jul 2012 15:54:45 -0500
Message-Id: <87pq7s6b8q.fsf@HIDDEN>
From: "Roland Winkler" <winkler@HIDDEN>
Precedence: list
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org

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

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: "Roland Winkler" <winkler@HIDDEN>
Subject: bug#11983: Acknowledgement (24.1; Electric-command-loop broken?)
Message-ID: <handler.11983.B.134264526232659.ack <at> debbugs.gnu.org>
References: <87pq7s6b8q.fsf@HIDDEN>
X-Gnu-PR-Message: ack 11983
X-Gnu-PR-Package: emacs
Reply-To: 11983 <at> debbugs.gnu.org
Date: Wed, 18 Jul 2012 21:02:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 11983 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
11983: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D11983
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#11983: 24.1; Electric-command-loop broken?
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 19 Jul 2012 09:18:01 +0000
Resent-Message-ID: <handler.11983.B11983.134268946917245 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: "Roland Winkler" <winkler@HIDDEN>
Cc: 11983 <at> debbugs.gnu.org
From: Stefan Monnier <monnier@HIDDEN>
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
Precedence: list
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org

> 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

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#11983: 24.1; Electric-command-loop broken?
Resent-From: "Roland Winkler" <winkler@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 19 Jul 2012 21:37:01 +0000
Resent-Message-ID: <handler.11983.B11983.13427337731504 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Stefan Monnier <monnier@HIDDEN>
Cc: 11983 <at> debbugs.gnu.org
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>
In-Reply-To: <jwv7gu0upar.fsf-monnier+emacs@HIDDEN>
References: <87pq7s6b8q.fsf@HIDDEN>
	<jwv7gu0upar.fsf-monnier+emacs@HIDDEN>
Precedence: list
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org

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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#11983: 24.1; Electric-command-loop broken?
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 20 Jul 2012 09:55:01 +0000
Resent-Message-ID: <handler.11983.B11983.1342778044398 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 11983
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: "Roland Winkler" <winkler@HIDDEN>
Cc: 11983 <at> debbugs.gnu.org
Received: via spool by 11983-submit <at> debbugs.gnu.org id=B11983.1342778044398
          (code B ref 11983); Fri, 20 Jul 2012 09:55:01 +0000
Received: (at 11983) by debbugs.gnu.org; 20 Jul 2012 09:54:04 +0000
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>
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-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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#11983: 24.1; Electric-command-loop broken?
Resent-From: "Roland Winkler" <winkler@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 20 Jul 2012 10:50:02 +0000
Resent-Message-ID: <handler.11983.B11983.13427813985895 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 11983
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 11983 <at> debbugs.gnu.org
Received: via spool by 11983-submit <at> debbugs.gnu.org id=B11983.13427813985895
          (code B ref 11983); Fri, 20 Jul 2012 10:50:02 +0000
Received: (at 11983) by debbugs.gnu.org; 20 Jul 2012 10:49:58 +0000
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>
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-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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#11983: 24.1; Electric-command-loop broken?
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 20 Jul 2012 12:17:01 +0000
Resent-Message-ID: <handler.11983.B11983.134278656416441 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 11983
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: "Roland Winkler" <winkler@HIDDEN>
Cc: 11983 <at> debbugs.gnu.org
Received: via spool by 11983-submit <at> debbugs.gnu.org id=B11983.134278656416441
          (code B ref 11983); Fri, 20 Jul 2012 12:17:01 +0000
Received: (at 11983) by debbugs.gnu.org; 20 Jul 2012 12:16:04 +0000
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>
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-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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#11983: 24.1; Electric-command-loop broken?
Resent-From: "Roland Winkler" <winkler@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 20 Jul 2012 12:45:01 +0000
Resent-Message-ID: <handler.11983.B11983.134278827318996 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 11983
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 11983 <at> debbugs.gnu.org
Received: via spool by 11983-submit <at> debbugs.gnu.org id=B11983.134278827318996
          (code B ref 11983); Fri, 20 Jul 2012 12:45:01 +0000
Received: (at 11983) by debbugs.gnu.org; 20 Jul 2012 12:44:33 +0000
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>
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-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

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

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