[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 21:23:59 +0300 |
> 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?