Subject: bug#55257: master f2d2fe6fc8: server-execute: Initialize the *scratch* buffer

From: Sean Whitton <[email-masked]>
Date: Sat, 07 May 2022 09:29:50 -0700

Hello,

On Sat 07 May 2022 at 08:30am +03, Eli Zaretskii wrote:

> What do you mean by "touch"?  Doesn't get-buffer already "touch" the
> buffer if it exists?  And determining whether the buffer has any stuff
> in it (if this is the concern here) is just one function call away,
> and is very fast.

As Stefan said, if the user has deleted the initial scratch message, we
do not want to go reinserting it.  And similarly if they have changed
the mode away from whatever initial-major-mode specifies, we do not want
to change it back.  The only time we want to do anything is when the
buffer does not exist.

> This is not about Emacs Lisp, this is an incompatible behavior change,
> and we have a section for that in NEWS.

Okay.

> My bother is that the function you call could signal an error at some
> point, and that could cause trouble to some of the callers, perhaps.
> Calling Lisp from C should always assume this could happen, because
> basically the Lisp function you call is out of your control, and you
> cannot reliably assume anything about what it does or will do at some
> future time.
>
> Does this answer your question?

I'm still not clear on what safe_call protects us from here.  It's in
xdisp.c and the comment next to it talks about preventing redisplay, but
I don't see how redisplay is relevant to what this function does.  Does
safe_call also catch all signals and convert them to nil, or something?

-- 
Sean Whitton