GNU bug report logs - #37352
27.0.50; recursive-edit aborts on elisp error after evaluation

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 37352 in the body.
You can then email your comments to 37352 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jean Louis <bugs <at> gnu.support>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; recursive-edit aborts on elisp error after evaluation
Date: Mon, 09 Sep 2019 09:41:03 +0200

In my opinion this should not be happening. If I am editing buffer
with recursive-edit the buffer is to abort on Emacs Lisp evaluation if
there is any error taking place.

I am using this function below.

(defun read-from-buffer (value &optional buffer-name mode)
  "Edits string and returns it"
  (let ((this-buffer (buffer-name))
	(new-value value)
	(buffy (if buffer-name buffer-name "*edit-string*")))
    (save-excursion
      (switch-to-buffer buffy)
      (set-buffer buffy)
      (if mode (funcall mode)
	(text-mode))
      (setq header-line-format "➜ Finish editing with C-c C-c or C-M-c")
      (local-set-key (kbd "C-c C-c") 'exit-recursive-edit)
      (if (stringp value) (insert value))
      ;; (speak "You may quit the buffer with Control C Control C")
      (message "When you're done editing press C-c C-c or C-M-c to continue.")
      (unwind-protect
	  (recursive-edit)
	(if (get-buffer-window buffy)
	    (progn
	      (setq new-value (buffer-substring (point-min) (point-max)))
	      (kill-buffer buffy))))
      (switch-to-buffer this-buffer)
      new-value)))

Then you could edit some string to see how this is happening:

(read-from-buffer "EDIT ME\nEvaluate this: (nonexistingfunction) ")

Then there after you could evaluate some non existing function to invoke
the Emacs Lisp error.

At that time the editing with recursive-buffer is interrupted and data
is lost.

This should not happen, as evaluations are often required during editing.





In GNU Emacs 27.0.50 (build 5, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2019-09-07 built on protected.rcdrun.com
Repository revision: 40eb4c51a40a37c14e882e6db3f880ba4528c089
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description: Hyperbola GNU/Linux-libre

Recent messages:
Back to top level
funcall-interactively: No recursive edit is in progress
Mark saved where search started
read-from-buffer
When you’re done editing press C-c C-c or C-M-c to continue.
Entering debugger...
Back to top level
Quit
Mark set
Making completion list...

Configured using:
 'configure --prefix=/package/text/emacs-2019-09-07 --with-modules
 --without-gpm --with-x-toolkit=lucid
 PKG_CONFIG_PATH=/home/data1/protected/GNUstep/Library/Libraries/pkgconfig:/usr/lib/pkgconfig'

Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG SOUND DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM MODULES THREADS JSON PDUMPER
LCMS2 GMP

Important settings:
  value of $LC_ALL: de_DE.UTF-8
  value of $LANG: de_DE.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort hashcash mail-extr emacsbug message rmc puny dired
dired-loaddefs format-spec rfc822 mml mml-sec password-cache epa derived
epg epg-config gnus-util rmail rmail-loaddefs text-property-search
time-date subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
misearch multi-isearch help-fns radix-tree cl-print debug backtrace
help-mode easymenu find-func edmacro kmacro cl-loaddefs cl-lib tooltip
eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 51823 7026)
 (symbols 48 6698 1)
 (strings 32 18378 2144)
 (string-bytes 1 589184)
 (vectors 16 11030)
 (vector-slots 8 142630 10478)
 (floats 8 26 76)
 (intervals 56 382 0)
 (buffers 992 14))

-- 
Thanks,
Jean Louis

Message #8 received at 37352 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: 37352 <at> debbugs.gnu.org
Subject: Re: bug#37352: 27.0.50; recursive-edit aborts on elisp error after
 evaluation
Date: Fri, 20 Sep 2019 20:30:07 +0200

Jean Louis <bugs <at> gnu.support> writes:


[...]

>       (unwind-protect
> 	  (recursive-edit)
> 	(if (get-buffer-window buffy)
> 	    (progn
> 	      (setq new-value (buffer-substring (point-min) (point-max)))
> 	      (kill-buffer buffy))))
>       (switch-to-buffer this-buffer)
>       new-value)))
>
> Then you could edit some string to see how this is happening:
>
> (read-from-buffer "EDIT ME\nEvaluate this: (nonexistingfunction) ")
>
> Then there after you could evaluate some non existing function to invoke
> the Emacs Lisp error.
>
> At that time the editing with recursive-buffer is interrupted and data
> is lost.

I'm not quite sure I understand the function above, are you basically
doing this?

M-: (recursive-edit)
M-: (error)

And you say that this returns you to the to the top level?

It doesn't do that for me -- unless I have debug-on-error set, and use
`q' to exit that (which returns to top level, as advertised).

Is this what you're seeing?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #11 received at 37352 <at> debbugs.gnu.org (full text, mbox):

From: Jean Louis <bugs <at> gnu.support>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 37352 <at> debbugs.gnu.org
Subject: Re: bug#37352: 27.0.50; recursive-edit aborts on elisp error after
 evaluation
Date: Fri, 20 Sep 2019 21:09:03 +0200

* Lars Ingebrigtsen <larsi <at> gnus.org> [2019-09-20 20:30]:
> Jean Louis <bugs <at> gnu.support> writes:
> 
> 
> [...]
> 
> >       (unwind-protect
> > 	  (recursive-edit)
> > 	(if (get-buffer-window buffy)
> > 	    (progn
> > 	      (setq new-value (buffer-substring (point-min) (point-max)))
> > 	      (kill-buffer buffy))))
> >       (switch-to-buffer this-buffer)
> >       new-value)))
> >
> > Then you could edit some string to see how this is happening:
> >
> > (read-from-buffer EDIT ME\nEvaluate this: (nonexistingfunction) )
> >
> > Then there after you could evaluate some non existing function to invoke
> > the Emacs Lisp error.
> >
> > At that time the editing with recursive-buffer is interrupted and data
> > is lost.
> 
> I'm not quite sure I understand the function above, are you basically
> doing this?
> 
> M-: (recursive-edit)
> M-: (error)
> 
> And you say that this returns you to the to the top level?
> 
> It doesn't do that for me -- unless I have debug-on-error set, and use
> `q' to exit that (which returns to top level, as advertised).
> 
> Is this what you're seeing?
> 
> -- 
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no

Please see the attached picture. I have turned off debug on error
before evaluating (jnjn) non-existing function.

Jean

Message #14 received at 37352 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: 37352 <at> debbugs.gnu.org
Subject: Re: bug#37352: 27.0.50; recursive-edit aborts on elisp error after
 evaluation
Date: Fri, 20 Sep 2019 23:01:07 +0200

Jean Louis <bugs <at> gnu.support> writes:

> Please see the attached picture. I have turned off debug on error
> before evaluating (jnjn) non-existing function.

The picture (sent in a separate email) showed a backtrace, so you do
have debug-on-error switched on -- perhaps via
eval-expression-debug-on-error?  (It's a separate setting when you do
M-:, which is rather confusing.)

And if you hit `q' in the backtrace window, you run `top-level':

(defun debugger-quit ()
  "Quit debugging and return to the top level."
  (interactive)
  (if (= (recursion-depth) 0)
      (quit-window)
    (top-level)))


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #17 received at 37352 <at> debbugs.gnu.org (full text, mbox):

From: Jean Louis <bugs <at> gnu.support>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 37352 <at> debbugs.gnu.org
Subject: Re: bug#37352: 27.0.50; recursive-edit aborts on elisp error after
 evaluation
Date: Sun, 22 Sep 2019 14:57:44 +0200

* Lars Ingebrigtsen <larsi <at> gnus.org> [2019-09-20 23:01]:
> Jean Louis <bugs <at> gnu.support> writes:
> 
> > Please see the attached picture. I have turned off debug on error
> > before evaluating (jnjn) non-existing function.
> 
> The picture (sent in a separate email) showed a backtrace, so you do
> have debug-on-error switched on -- perhaps via
> eval-expression-debug-on-error?  (It's a separate setting when you do
> M-:, which is rather confusing.)

Exactl that. If I turn off eval-expression-debug-on-error, then there
is no interruption of recursive-edit and I can continue editing.

That is probably better defined bug.

The eval-expression-debug-on-error when T or NIL shall not interrupt
the recursive-edit if there is error in evaluation. The debug window
could be finalized or abandoned, and then the old window shall
continue processing the text edited.

If you think that is not a bug, let me know. Then I can implement it
in my function and avoid the problem.

Jean

Message #20 received at 37352 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: 37352 <at> debbugs.gnu.org
Subject: Re: bug#37352: 27.0.50; recursive-edit aborts on elisp error after
 evaluation
Date: Sun, 22 Sep 2019 15:00:26 +0200

Jean Louis <bugs <at> gnu.support> writes:

> That is probably better defined bug.
>
> The eval-expression-debug-on-error when T or NIL shall not interrupt
> the recursive-edit if there is error in evaluation. The debug window
> could be finalized or abandoned, and then the old window shall
> continue processing the text edited.
>
> If you think that is not a bug, let me know. Then I can implement it
> in my function and avoid the problem.

I don't think it's a bug -- the `q' command in the debugging buffer is
documented to "Quit debugging and return to the top level".

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #27 received at 37352 <at> debbugs.gnu.org (full text, mbox):

From: Jean Louis <bugs <at> gnu.support>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 37352 <at> debbugs.gnu.org
Subject: Re: bug#37352: 27.0.50; recursive-edit aborts on elisp error after
 evaluation
Date: Sun, 22 Sep 2019 15:04:24 +0200

* Lars Ingebrigtsen <larsi <at> gnus.org> [2019-09-22 15:00]:
> Jean Louis <bugs <at> gnu.support> writes:
> 
> > That is probably better defined bug.
> >
> > The eval-expression-debug-on-error when T or NIL shall not interrupt
> > the recursive-edit if there is error in evaluation. The debug window
> > could be finalized or abandoned, and then the old window shall
> > continue processing the text edited.
> >
> > If you think that is not a bug, let me know. Then I can implement it
> > in my function and avoid the problem.
> 
> I don't think it's a bug -- the `q' command in the debugging buffer
> is documented to Quit debugging and return to the top level.

After the 'q' command, recursive-edit is interrupted. So why would
that be interrupted? There is no reason that I see.

Message #30 received at 37352 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: 37352 <at> debbugs.gnu.org
Subject: Re: bug#37352: 27.0.50; recursive-edit aborts on elisp error after
 evaluation
Date: Sun, 22 Sep 2019 15:49:26 +0200

Jean Louis <bugs <at> gnu.support> writes:

>> I don't think it's a bug -- the `q' command in the debugging buffer
>> is documented to Quit debugging and return to the top level.
>
> After the 'q' command, recursive-edit is interrupted. So why would
> that be interrupted? There is no reason that I see.

"Return to the top level" means that the recursive edit is interrupted.

I don't know why the `q' command in the debugging mode is defined that
way.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #33 received at 37352 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Jean Louis <bugs <at> gnu.support>
Cc: 37352 <at> debbugs.gnu.org
Subject: RE: bug#37352: 27.0.50; recursive-edit aborts on elisp error after
 evaluation
Date: Sun, 22 Sep 2019 09:14:21 -0700 (PDT)

> I don't know why the `q' command in the debugging mode
> is defined that way.

Uh, because it makes sense?  The recursive edit
was entered only for use of the debugger.

What is the real problem that this bug report is
trying to report?  What's the aim?  (Sounds like
an X-Y question.)

Message #36 received at 37352 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Jean Louis <bugs <at> gnu.support>,
 37352 <at> debbugs.gnu.org
Subject: Re: bug#37352: 27.0.50;
 recursive-edit aborts on elisp error after evaluation
Date: Sun, 22 Sep 2019 12:39:31 -0400

On Sun, 22 Sep 2019 at 12:15, Drew Adams <drew.adams <at> oracle.com> wrote:
>
> > I don't know why the `q' command in the debugging mode
> > is defined that way.
>
> Uh, because it makes sense?  The recursive edit
> was entered only for use of the debugger.

There are two recursive edits, one that the OP entered from their code
(I assume for the edit-file-and-return-as-string stuff [1]), and a
second nested one that happend after an error was signaled and the
debugger was invoked. Then quitting the debugger exits both recursive
edits, because q is bound to top-level in debugger-mode, and top-level
aborts all recursive edits, not just the latest one.

A possible solution might be to bind q to a command which quits
recursive edits only up to the one that the debugger invoked.

[1]: https://lists.gnu.org/archive/html/help-gnu-emacs/2019-08/msg00051.html

Message #39 received at 37352 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Jean Louis <bugs <at> gnu.support>,
 37352 <at> debbugs.gnu.org
Subject: RE: bug#37352: 27.0.50; recursive-edit aborts on elisp error after
 evaluation
Date: Sun, 22 Sep 2019 09:55:44 -0700 (PDT)

> > > I don't know why the `q' command in the debugging mode
> > > is defined that way.
> >
> > Uh, because it makes sense?  The recursive edit
> > was entered only for use of the debugger.
> 
> There are two recursive edits, one that the OP entered from their code
> (I assume for the edit-file-and-return-as-string stuff [1]), 

Sorry; didn't realize that.

> and a second nested one that happend after an error was signaled and the
> debugger was invoked. Then quitting the debugger exits both recursive
> edits, because q is bound to top-level in debugger-mode, and top-level
> aborts all recursive edits, not just the latest one.
> 
> A possible solution might be to bind q to a command which quits
> recursive edits only up to the one that the debugger invoked.

I see; thanks.

But if an error was raised then is it possible to return
from the debugger recursive edit to the previous recursive
edit?  Continuing from an error can be problematic, no?

On the other hand, if the debugger was entered for, say,
`debug` or `debug-on-entry` then what's called for is to
use `c`, not `q`, (as many times as necessary, to exit the
debugger), or to use `C-M-c` to exit the recursive edit
immediately.

Message #42 received at 37352 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: larsi <at> gnus.org, bugs <at> gnu.support, 37352 <at> debbugs.gnu.org
Subject: Re: bug#37352: 27.0.50;
 recursive-edit aborts on elisp error after evaluation
Date: Sun, 22 Sep 2019 19:58:07 +0300

> Date: Sun, 22 Sep 2019 09:14:21 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 37352 <at> debbugs.gnu.org
> 
> > I don't know why the `q' command in the debugging mode
> > is defined that way.
> 
> Uh, because it makes sense?  The recursive edit
> was entered only for use of the debugger.

No, it wasn't.  Please re-read the original bug report.

Message #45 received at 37352 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: larsi <at> gnus.org, bugs <at> gnu.support, drew.adams <at> oracle.com,
 37352 <at> debbugs.gnu.org
Subject: Re: bug#37352: 27.0.50;
 recursive-edit aborts on elisp error after evaluation
Date: Sun, 22 Sep 2019 19:59:36 +0300

> From: Noam Postavsky <npostavs <at> gmail.com>
> Date: Sun, 22 Sep 2019 12:39:31 -0400
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Jean Louis <bugs <at> gnu.support>,
>  37352 <at> debbugs.gnu.org
> 
> A possible solution might be to bind q to a command which quits
> recursive edits only up to the one that the debugger invoked.

For backward compatibility reasons, this should be a different key, or
at the very least there should be a defcustom to control what q does,
defaulting to the current behavior.

Message #48 received at 37352 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, Noam Postavsky <npostavs <at> gmail.com>, bugs <at> gnu.support,
 37352 <at> debbugs.gnu.org
Subject: Re: bug#37352: 27.0.50;
 recursive-edit aborts on elisp error after evaluation
Date: Sun, 22 Sep 2019 19:54:43 +0200

On Sep 22 2019, Eli Zaretskii <eliz <at> gnu.org> wrote:

>> A possible solution might be to bind q to a command which quits
>> recursive edits only up to the one that the debugger invoked.
>
> For backward compatibility reasons, this should be a different key,

Like C-M-c?

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Message #51 received at 37352 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: larsi <at> gnus.org, npostavs <at> gmail.com, bugs <at> gnu.support, 37352 <at> debbugs.gnu.org
Subject: Re: bug#37352: 27.0.50;
 recursive-edit aborts on elisp error after evaluation
Date: Sun, 22 Sep 2019 21:20:54 +0300

> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Cc: Noam Postavsky <npostavs <at> gmail.com>,  larsi <at> gnus.org,  bugs <at> gnu.support,  37352 <at> debbugs.gnu.org
> Date: Sun, 22 Sep 2019 19:54:43 +0200
> 
> On Sep 22 2019, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> >> A possible solution might be to bind q to a command which quits
> >> recursive edits only up to the one that the debugger invoked.
> >
> > For backward compatibility reasons, this should be a different key,
> 
> Like C-M-c?

Yes, like C-M-c.

Message #54 received at 37352 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Andreas Schwab <schwab <at> linux-m68k.org>, npostavs <at> gmail.com,
 bugs <at> gnu.support, 37352 <at> debbugs.gnu.org
Subject: Re: bug#37352: 27.0.50; recursive-edit aborts on elisp error after
 evaluation
Date: Mon, 23 Sep 2019 12:18:26 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Like C-M-c?
>
> Yes, like C-M-c.

Hm; I never considered that `C-M-c' would be a good way to exit the
debugger -- perhaps this should be mentioned in the doc string?

Or perhaps we could bind, say, `Q', to `exit-recursive-edit' in that
mode?

I just had a look at the doc string -- I'm not quite sure what the
second paragraph tries to say, but it seems to be grammatically dubious,
anyway.  Perhaps somebody who knows what this means can fix that
sentence up, anyway?  :-)

---
A line starts with ‘*’ if exiting that frame will call the debugger.
Type b or u to set or remove the ‘*’.

When in debugger due to frame being exited,
use the r command to override the value
being returned from that frame.

Use M-x debug-on-entry and M-x cancel-debug-on-entry to control
which functions will enter the debugger when called.


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #57 received at 37352 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Andreas Schwab <schwab <at> linux-m68k.org>,
 bugs <at> gnu.support, 37352 <at> debbugs.gnu.org
Subject: Re: bug#37352: 27.0.50;
 recursive-edit aborts on elisp error after evaluation
Date: Mon, 23 Sep 2019 08:43:45 -0400

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> Like C-M-c?
>>
>> Yes, like C-M-c.
>
> Hm; I never considered that `C-M-c' would be a good way to exit the
> debugger -- perhaps this should be mentioned in the doc string?
>
> Or perhaps we could bind, say, `Q', to `exit-recursive-edit' in that
> mode?

This would fail to exit the debugger when there is a recursive-edit
invoked after the debugger is entered.

Message #60 received at 37352 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Andreas Schwab <schwab <at> linux-m68k.org>,
 bugs <at> gnu.support, 37352 <at> debbugs.gnu.org
Subject: Re: bug#37352: 27.0.50; recursive-edit aborts on elisp error after
 evaluation
Date: Mon, 23 Sep 2019 16:01:52 +0200

Noam Postavsky <npostavs <at> gmail.com> writes:

> This would fail to exit the debugger when there is a recursive-edit
> invoked after the debugger is entered.

Ah, right.  So a new `Q' command that unwinds to whatever recursive
level was at the time the debugger was entered?  Is that information
available in Lisp land?  command_loop_level is the variable that keeps
track of this?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #63 received at 37352 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>,
 bugs <at> gnu.support, 37352 <at> debbugs.gnu.org
Subject: Re: bug#37352: 27.0.50;
 recursive-edit aborts on elisp error after evaluation
Date: Mon, 23 Sep 2019 16:14:46 +0200

On Sep 23 2019, Noam Postavsky <npostavs <at> gmail.com> wrote:

> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>>> Like C-M-c?
>>>
>>> Yes, like C-M-c.
>>
>> Hm; I never considered that `C-M-c' would be a good way to exit the
>> debugger -- perhaps this should be mentioned in the doc string?
>>
>> Or perhaps we could bind, say, `Q', to `exit-recursive-edit' in that
>> mode?
>
> This would fail to exit the debugger when there is a recursive-edit
> invoked after the debugger is entered.

Then repeat until it does.  If you enter a recursive edit, you probably
had a good reason.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Message #66 received at 37352 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: schwab <at> linux-m68k.org, npostavs <at> gmail.com, bugs <at> gnu.support,
 37352 <at> debbugs.gnu.org
Subject: Re: bug#37352: 27.0.50; recursive-edit aborts on elisp error after
 evaluation
Date: Wed, 25 Sep 2019 11:11:05 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Andreas Schwab <schwab <at> linux-m68k.org>,  npostavs <at> gmail.com,
>   bugs <at> gnu.support,  37352 <at> debbugs.gnu.org
> Date: Mon, 23 Sep 2019 12:18:26 +0200
> 
> I just had a look at the doc string -- I'm not quite sure what the
> second paragraph tries to say, but it seems to be grammatically dubious,
> anyway.  Perhaps somebody who knows what this means can fix that
> sentence up, anyway?  :-)

It took me a while to understand doc string of what you were alluding
to do, but eventually I found it, and tried to clarify it.

Message #69 received at 37352 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: schwab <at> linux-m68k.org, npostavs <at> gmail.com, bugs <at> gnu.support,
 37352 <at> debbugs.gnu.org
Subject: Re: bug#37352: 27.0.50; recursive-edit aborts on elisp error after
 evaluation
Date: Wed, 25 Sep 2019 15:09:35 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> It took me a while to understand doc string of what you were alluding
> to do, but eventually I found it, and tried to clarify it.

Ah, thanks, now it's understandable to me too.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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