* bug#37352: 27.0.50; recursive-edit aborts on elisp error after evaluation
@ 2019-09-09 7:41 Jean Louis
2019-09-20 18:30 ` Lars Ingebrigtsen
0 siblings, 1 reply; 21+ messages in thread
From: Jean Louis @ 2019-09-09 7:41 UTC (permalink / raw)
To: 37352
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#37352: 27.0.50; recursive-edit aborts on elisp error after evaluation
2019-09-09 7:41 bug#37352: 27.0.50; recursive-edit aborts on elisp error after evaluation Jean Louis
@ 2019-09-20 18:30 ` Lars Ingebrigtsen
2019-09-20 19:09 ` Jean Louis
0 siblings, 1 reply; 21+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-20 18:30 UTC (permalink / raw)
To: Jean Louis; +Cc: 37352
Jean Louis <bugs@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
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#37352: 27.0.50; recursive-edit aborts on elisp error after evaluation
2019-09-20 18:30 ` Lars Ingebrigtsen
@ 2019-09-20 19:09 ` Jean Louis
2019-09-20 21:01 ` Lars Ingebrigtsen
0 siblings, 1 reply; 21+ messages in thread
From: Jean Louis @ 2019-09-20 19:09 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 37352
* Lars Ingebrigtsen <larsi@gnus.org> [2019-09-20 20:30]:
> Jean Louis <bugs@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
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#37352: 27.0.50; recursive-edit aborts on elisp error after evaluation
2019-09-20 19:09 ` Jean Louis
@ 2019-09-20 21:01 ` Lars Ingebrigtsen
2019-09-22 12:57 ` Jean Louis
0 siblings, 1 reply; 21+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-20 21:01 UTC (permalink / raw)
To: Jean Louis; +Cc: 37352
Jean Louis <bugs@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
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#37352: 27.0.50; recursive-edit aborts on elisp error after evaluation
2019-09-20 21:01 ` Lars Ingebrigtsen
@ 2019-09-22 12:57 ` Jean Louis
2019-09-22 13:00 ` Lars Ingebrigtsen
0 siblings, 1 reply; 21+ messages in thread
From: Jean Louis @ 2019-09-22 12:57 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 37352
* Lars Ingebrigtsen <larsi@gnus.org> [2019-09-20 23:01]:
> Jean Louis <bugs@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
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#37352: 27.0.50; recursive-edit aborts on elisp error after evaluation
2019-09-22 12:57 ` Jean Louis
@ 2019-09-22 13:00 ` Lars Ingebrigtsen
2019-09-22 13:04 ` Jean Louis
0 siblings, 1 reply; 21+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-22 13:00 UTC (permalink / raw)
To: Jean Louis; +Cc: 37352
Jean Louis <bugs@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
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#37352: 27.0.50; recursive-edit aborts on elisp error after evaluation
2019-09-22 13:00 ` Lars Ingebrigtsen
@ 2019-09-22 13:04 ` Jean Louis
2019-09-22 13:49 ` Lars Ingebrigtsen
0 siblings, 1 reply; 21+ messages in thread
From: Jean Louis @ 2019-09-22 13:04 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 37352
* Lars Ingebrigtsen <larsi@gnus.org> [2019-09-22 15:00]:
> Jean Louis <bugs@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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#37352: 27.0.50; recursive-edit aborts on elisp error after evaluation
2019-09-22 13:04 ` Jean Louis
@ 2019-09-22 13:49 ` Lars Ingebrigtsen
2019-09-22 16:14 ` Drew Adams
0 siblings, 1 reply; 21+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-22 13:49 UTC (permalink / raw)
To: Jean Louis; +Cc: 37352
Jean Louis <bugs@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
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#37352: 27.0.50; recursive-edit aborts on elisp error after evaluation
2019-09-22 13:49 ` Lars Ingebrigtsen
@ 2019-09-22 16:14 ` Drew Adams
2019-09-22 16:39 ` Noam Postavsky
2019-09-22 16:58 ` Eli Zaretskii
0 siblings, 2 replies; 21+ messages in thread
From: Drew Adams @ 2019-09-22 16:14 UTC (permalink / raw)
To: Lars Ingebrigtsen, Jean Louis; +Cc: 37352
> 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.)
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#37352: 27.0.50; recursive-edit aborts on elisp error after evaluation
2019-09-22 16:14 ` Drew Adams
@ 2019-09-22 16:39 ` Noam Postavsky
2019-09-22 16:55 ` Drew Adams
2019-09-22 16:59 ` Eli Zaretskii
2019-09-22 16:58 ` Eli Zaretskii
1 sibling, 2 replies; 21+ messages in thread
From: Noam Postavsky @ 2019-09-22 16:39 UTC (permalink / raw)
To: Drew Adams; +Cc: Lars Ingebrigtsen, Jean Louis, 37352
On Sun, 22 Sep 2019 at 12:15, Drew Adams <drew.adams@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
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#37352: 27.0.50; recursive-edit aborts on elisp error after evaluation
2019-09-22 16:39 ` Noam Postavsky
@ 2019-09-22 16:55 ` Drew Adams
2019-09-22 16:59 ` Eli Zaretskii
1 sibling, 0 replies; 21+ messages in thread
From: Drew Adams @ 2019-09-22 16:55 UTC (permalink / raw)
To: Noam Postavsky; +Cc: Lars Ingebrigtsen, Jean Louis, 37352
> > > 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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#37352: 27.0.50; recursive-edit aborts on elisp error after evaluation
2019-09-22 16:39 ` Noam Postavsky
2019-09-22 16:55 ` Drew Adams
@ 2019-09-22 16:59 ` Eli Zaretskii
2019-09-22 17:54 ` Andreas Schwab
1 sibling, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2019-09-22 16:59 UTC (permalink / raw)
To: Noam Postavsky; +Cc: larsi, bugs, 37352
> From: Noam Postavsky <npostavs@gmail.com>
> Date: Sun, 22 Sep 2019 12:39:31 -0400
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Jean Louis <bugs@gnu.support>,
> 37352@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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#37352: 27.0.50; recursive-edit aborts on elisp error after evaluation
2019-09-22 16:59 ` Eli Zaretskii
@ 2019-09-22 17:54 ` Andreas Schwab
2019-09-22 18:20 ` Eli Zaretskii
0 siblings, 1 reply; 21+ messages in thread
From: Andreas Schwab @ 2019-09-22 17:54 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: larsi, Noam Postavsky, bugs, 37352
On Sep 22 2019, Eli Zaretskii <eliz@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@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#37352: 27.0.50; recursive-edit aborts on elisp error after evaluation
2019-09-22 17:54 ` Andreas Schwab
@ 2019-09-22 18:20 ` Eli Zaretskii
2019-09-23 10:18 ` Lars Ingebrigtsen
0 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2019-09-22 18:20 UTC (permalink / raw)
To: Andreas Schwab; +Cc: larsi, npostavs, bugs, 37352
> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Noam Postavsky <npostavs@gmail.com>, larsi@gnus.org, bugs@gnu.support, 37352@debbugs.gnu.org
> Date: Sun, 22 Sep 2019 19:54:43 +0200
>
> On Sep 22 2019, Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#37352: 27.0.50; recursive-edit aborts on elisp error after evaluation
2019-09-22 18:20 ` Eli Zaretskii
@ 2019-09-23 10:18 ` Lars Ingebrigtsen
2019-09-23 12:43 ` Noam Postavsky
2019-09-25 8:11 ` Eli Zaretskii
0 siblings, 2 replies; 21+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-23 10:18 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Andreas Schwab, npostavs, bugs, 37352
Eli Zaretskii <eliz@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
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#37352: 27.0.50; recursive-edit aborts on elisp error after evaluation
2019-09-23 10:18 ` Lars Ingebrigtsen
@ 2019-09-23 12:43 ` Noam Postavsky
2019-09-23 14:01 ` Lars Ingebrigtsen
2019-09-23 14:14 ` Andreas Schwab
2019-09-25 8:11 ` Eli Zaretskii
1 sibling, 2 replies; 21+ messages in thread
From: Noam Postavsky @ 2019-09-23 12:43 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Andreas Schwab, bugs, 37352
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#37352: 27.0.50; recursive-edit aborts on elisp error after evaluation
2019-09-23 12:43 ` Noam Postavsky
@ 2019-09-23 14:01 ` Lars Ingebrigtsen
2019-09-23 14:14 ` Andreas Schwab
1 sibling, 0 replies; 21+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-23 14:01 UTC (permalink / raw)
To: Noam Postavsky; +Cc: Andreas Schwab, bugs, 37352
Noam Postavsky <npostavs@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
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#37352: 27.0.50; recursive-edit aborts on elisp error after evaluation
2019-09-23 12:43 ` Noam Postavsky
2019-09-23 14:01 ` Lars Ingebrigtsen
@ 2019-09-23 14:14 ` Andreas Schwab
1 sibling, 0 replies; 21+ messages in thread
From: Andreas Schwab @ 2019-09-23 14:14 UTC (permalink / raw)
To: Noam Postavsky; +Cc: Lars Ingebrigtsen, bugs, 37352
On Sep 23 2019, Noam Postavsky <npostavs@gmail.com> wrote:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Eli Zaretskii <eliz@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@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#37352: 27.0.50; recursive-edit aborts on elisp error after evaluation
2019-09-23 10:18 ` Lars Ingebrigtsen
2019-09-23 12:43 ` Noam Postavsky
@ 2019-09-25 8:11 ` Eli Zaretskii
2019-09-25 13:09 ` Lars Ingebrigtsen
1 sibling, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2019-09-25 8:11 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: schwab, npostavs, bugs, 37352
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Andreas Schwab <schwab@linux-m68k.org>, npostavs@gmail.com,
> bugs@gnu.support, 37352@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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#37352: 27.0.50; recursive-edit aborts on elisp error after evaluation
2019-09-25 8:11 ` Eli Zaretskii
@ 2019-09-25 13:09 ` Lars Ingebrigtsen
0 siblings, 0 replies; 21+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-25 13:09 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: schwab, npostavs, bugs, 37352
Eli Zaretskii <eliz@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
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#37352: 27.0.50; recursive-edit aborts on elisp error after evaluation
2019-09-22 16:14 ` Drew Adams
2019-09-22 16:39 ` Noam Postavsky
@ 2019-09-22 16:58 ` Eli Zaretskii
1 sibling, 0 replies; 21+ messages in thread
From: Eli Zaretskii @ 2019-09-22 16:58 UTC (permalink / raw)
To: Drew Adams; +Cc: larsi, bugs, 37352
> Date: Sun, 22 Sep 2019 09:14:21 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 37352@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.
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2019-09-25 13:09 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-09-09 7:41 bug#37352: 27.0.50; recursive-edit aborts on elisp error after evaluation Jean Louis
2019-09-20 18:30 ` Lars Ingebrigtsen
2019-09-20 19:09 ` Jean Louis
2019-09-20 21:01 ` Lars Ingebrigtsen
2019-09-22 12:57 ` Jean Louis
2019-09-22 13:00 ` Lars Ingebrigtsen
2019-09-22 13:04 ` Jean Louis
2019-09-22 13:49 ` Lars Ingebrigtsen
2019-09-22 16:14 ` Drew Adams
2019-09-22 16:39 ` Noam Postavsky
2019-09-22 16:55 ` Drew Adams
2019-09-22 16:59 ` Eli Zaretskii
2019-09-22 17:54 ` Andreas Schwab
2019-09-22 18:20 ` Eli Zaretskii
2019-09-23 10:18 ` Lars Ingebrigtsen
2019-09-23 12:43 ` Noam Postavsky
2019-09-23 14:01 ` Lars Ingebrigtsen
2019-09-23 14:14 ` Andreas Schwab
2019-09-25 8:11 ` Eli Zaretskii
2019-09-25 13:09 ` Lars Ingebrigtsen
2019-09-22 16:58 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).