bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#37176: 27.0.50; recursive-edit interrupted by invokation of emacsclient
Date: Sun, 25 Aug 2019 10:02:22 +0300

> 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]