GNU bug report logs - #64866
30.0.50; Emacsclient block for 2 seconds when error is raised from command

Previous Next

Full log

Message #19 received at 64866 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Yikai Zhao <yikai <at> z1k.dev>
Cc: 64866 <at> debbugs.gnu.org
Subject: Re: bug#64866: 30.0.50; Emacsclient block for 2 seconds when error is
 raised from command
Date: Wed, 26 Jul 2023 11:07:24 -0700

On 7/25/2023 7:30 PM, Eli Zaretskii wrote:
> I don't think your quite special use case is a reason good enough to
> prevent users from seeing error messages.  An error message that
> cannot be read is useless.

In this case, the user *can* see the error though: it's printed in the 
terminal that they called `emacsclient -e '(error "oops")'` from. Even 
without the 2 second delay, I don't think there would be any loss of 
information to the user (at least not that I can see).

I've actually seen a related issue come up elsewhere: in our regression 
tests. When testing programmable completion in Eshell, I had to let-bind 
'minibuffer-message-timeout' to 0 to prevent the 2 second delay, which 
occurred even in batch mode. (See 
'em-cmpl-test/variable-ref-completion/directory' in 
"test/lisp/eshell/em-cmpl-tests.el".) I'm not sure why this delay is 
present in batch mode. (Going back to the original bug report, I'd 
consider 'emacsclient -e blah' to be analogous to batch mode.)

Strangely, I tried running this and I still see a 2 second delay:

  emacsclient -e '(let ((minibuffer-message-timeout 0)) (error "oops"))'

I'm not sure why that doesn't work...

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.