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

It's not important. I just had it in my config for a long time since I didn't know how emacs works - I just didn't want to have one more empty buffer and wanted to see messages at startup. The problem was that I didn't know what exactly led to this behavior after updating to emacs 28 - it was unexpected for me that killing scratch buffer could cause this. But I'm completely fine with not killing it and have already updated my configs to avoid this problem.

On Fri, Jan 21, 2022 at 12:57 PM Eli Zaretskii <eliz@gnu.org> wrote:

> From: Евгений Курневский <kurnevsky@gmail.com>
> Date: Fri, 21 Jan 2022 12:10:42 +0000
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 53391@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?