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