GNU bug report logs - #53391
First keypress doesn't work when scratch buffer is killed in emacs 28, emacs daemon + emacs client is used

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Евгений Курневский
 <kurnevsky <at> gmail.com>
Cc: larsi <at> gnus.org, 53391 <at> debbugs.gnu.org
Subject: Re: bug#53391: First keypress doesn't work when scratch buffer is
 killed in emacs 28, emacs daemon + emacs client is used
Date: Fri, 21 Jan 2022 14:57:30 +0200

> From: Евгений Курневский <kurnevsky <at> gmail.com>
> Date: Fri, 21 Jan 2022 12:10:42 +0000
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 53391 <at> debbugs.gnu.org
> 
> > Does this mean you see the problem in stock Emacs 28 built from the
> > emacs-28 branch of the upstream Emacs repository on Savannah?
> 
> Not exactly, it fetches https://git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-28.0.91.tar.gz and builds
> it.
> But it doesn't apply any custom changes, and to build emacs manually I'd anyway have to get the same
> environment where it's built and do almost the same things - nixos is a bit more complex system than usual
> linux.
> 
> > Can you type C-g and show the backtrace?
> 
> Tried to do it with (toggle-debug-on-quit), but just got 'Debugger entered--Lisp error: (quit)'

I think I've succeeded in reproducing this.  However, given that it
only happens if the init file deletes the *scratch* buffer (which is
the current buffer available to the daemon initially), I wonder
whether it's important to solve this corner case.  I'm guessing that
this has something to do with the fact that the daemon performs some
initial processing of the client commands in the original buffer.

Why is it important to delete the *scratch* buffer in your case?

Previous Next

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