bug#37176: 27.0.50; recursive-edit interrupted by invokation of emacsclient

bug#37176: 27.0.50; recursive-edit interrupted by invokation of emacsclient

[Jean Louis]

I am invoking a function with recursive-edit. It is normal to use Emacs
with all kinds of other windows. But if I switch to window with
ansi-term where I am invoking from mutt client new emacsclient to edit
an email, my recursive-edit is interrupted, cancelled and my editing is
gone.

In my opinion that should not be so.

Video demonstration is here:
https://gnu.support/images/2019/08/2019-08-24/2019-08-24-22:07:35.ogv



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

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
delete-backward-char: Text is read-only

Configured using:
 'configure --prefix=/package/text/emacs-2019-08-04 --with-modules
 --without-gpm --with-x-toolkit=lucid'

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 easymenu 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 cl-loaddefs cl-lib sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils 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 45716 7312)
 (symbols 48 6060 1)
 (strings 32 16281 2443)
 (string-bytes 1 520128)
 (vectors 16 9854)
 (vector-slots 8 127259 7198)
 (floats 8 22 18)
 (intervals 56 241 0)
 (buffers 992 12))

-- 
Thanks,
Jean Louis

bug#37176: 27.0.50; recursive-edit interrupted by invokation of emacsclient

[Eli Zaretskii]

> From: Jean Louis <bugs@gnu.support>
> Date: Sat, 24 Aug 2019 22:15:37 +0200
> 
> I am invoking a function with recursive-edit. It is normal to use Emacs
> with all kinds of other windows. But if I switch to window with
> ansi-term where I am invoking from mutt client new emacsclient to edit
> an email, my recursive-edit is interrupted, cancelled and my editing is
> gone.

Stefan, this is the result of your code from 13 years ago in
server.el:

  (when (> (recursion-depth) 0)
    ;; We're inside a minibuffer already, so if the emacs-client is trying
    ;; to open a frame on a new display, we might end up with an unusable
    ;; frame because input from that display will be blocked (until exiting
    ;; the minibuffer).  Better exit this minibuffer right away.
    ;; Similarly with recursive-edits such as the splash screen.
    (run-with-timer 0 nil (lambda () (server-execute-continuation proc)))
    (top-level)))

I could understand the rationale with the minibuffer, but I don't
think I understand why the recursive-edit scenario needs the same
treatment.  Can you explain?  In the recursive-edit case (unlike the
minibuffer case) it sounds like a too drastic measure to me.

bug#37176: 27.0.50; recursive-edit interrupted by invokation of emacsclient

[Stefan Monnier]

> Stefan, this is the result of your code from 13 years ago in
> server.el:
>
>   (when (> (recursion-depth) 0)
>     ;; We're inside a minibuffer already, so if the emacs-client is trying
>     ;; to open a frame on a new display, we might end up with an unusable
>     ;; frame because input from that display will be blocked (until exiting
>     ;; the minibuffer).  Better exit this minibuffer right away.
>     ;; Similarly with recursive-edits such as the splash screen.
>     (run-with-timer 0 nil (lambda () (server-execute-continuation proc)))
>     (top-level)))
>
> I could understand the rationale with the minibuffer, but I don't
> think I understand why the recursive-edit scenario needs the same
> treatment.  Can you explain?

I can't remember wanting to do it for recursive-edit, so I'm pretty sure
the use of recursion-depth is just careless here and using
minibuffer-depth should work just as well.


        Stefan

bug#37176: 27.0.50; recursive-edit interrupted by invokation of emacsclient

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Jean Louis <bugs@gnu.support>,  37176@debbugs.gnu.org
> Date: Sun, 25 Aug 2019 14:08:01 -0400
> 
> >   (when (> (recursion-depth) 0)
> >     ;; We're inside a minibuffer already, so if the emacs-client is trying
> >     ;; to open a frame on a new display, we might end up with an unusable
> >     ;; frame because input from that display will be blocked (until exiting
> >     ;; the minibuffer).  Better exit this minibuffer right away.
> >     ;; Similarly with recursive-edits such as the splash screen.
> >     (run-with-timer 0 nil (lambda () (server-execute-continuation proc)))
> >     (top-level)))
> >
> > I could understand the rationale with the minibuffer, but I don't
> > think I understand why the recursive-edit scenario needs the same
> > treatment.  Can you explain?
> 
> I can't remember wanting to do it for recursive-edit, so I'm pretty sure
> the use of recursion-depth is just careless here and using
> minibuffer-depth should work just as well.

Yes, but there's an explicit reference to recursive-edit in the
comment:

     ;; Similarly with recursive-edits such as the splash screen.

Does that ring any bells?

bug#37176: 27.0.50; recursive-edit interrupted by invokation of emacsclient

[Stefan Monnier]

> Yes, but there's an explicit reference to recursive-edit in the
> comment:
>
>      ;; Similarly with recursive-edits such as the splash screen.

Oh, indeed.

> Does that ring any bells?

No, sorry.


        Stefan

bug#37176: 27.0.50; recursive-edit interrupted by invokation of emacsclient

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: bugs@gnu.support,  37176@debbugs.gnu.org
> Date: Sun, 25 Aug 2019 14:53:27 -0400
> 
> > Yes, but there's an explicit reference to recursive-edit in the
> > comment:
> >
> >      ;; Similarly with recursive-edits such as the splash screen.
> 
> Oh, indeed.
> 
> > Does that ring any bells?
> 
> No, sorry.

OK, thanks.  I've now replaced recursion-depth with minibuffer-depth,
and I'm marking this bug done.