GNU bug report logs - #55257
29.0.50; New command `scratch-buffer' inconsistent with startup

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: rpluim <at> gmail.com, 55257-submitter <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, emacs-devel <at> gnu.org
Subject: bug#55257: master f2d2fe6fc8: server-execute: Initialize the *scratch* buffer
Date: Sat, 07 May 2022 08:30:06 +0300

> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: monnier <at> iro.umontreal.ca, rpluim <at> gmail.com, emacs-devel <at> gnu.org,
>  55257-submitter <at> debbugs.gnu.org
> Date: Fri, 06 May 2022 12:26:46 -0700
> 
> >> +(defun get-initial-buffer-create ()
> >> +  "Return the \*scratch\* buffer, creating a new one if needed."
> >> +  (if-let ((scratch (get-buffer "*scratch*")))
> >> +      scratch
> >> +    (prog1 (setq scratch (get-buffer-create "*scratch*"))
> >> +      (with-current-buffer scratch
> >> +        (when initial-scratch-message
> >> +          (insert (substitute-command-keys initial-scratch-message))
> >> +          (set-buffer-modified-p nil))
> >> +        (funcall initial-major-mode)))))
> >
> > It's somewhat inelegant to explicitly test for the buffer's existence
> > before you call get-buffer-create.  Is that only to avoid changing its
> > contents?  If so, can't you test for that in some other way?
> 
> I had the same intuition at first, but I don't think there is another
> way -- the code wants to touch the buffer at all only if it wasn't
> already there.

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.

> And the code path where it already exists will be by far
> the most commonly called, so it seems best to avoid calling
> with-current-buffer if we don't have to.

But get-buffer-create already does all that internally, and it exists
for this very purpose.  I don't really understand the objections, to
tell the truth.  Unless some more fundamental problem is involved,
which is why I asked about the reasons.

> >> +  return call0 (intern ("get-initial-buffer-create"));
> >
> > get-initial-buffer-create shows the initial-scratch-message, something
> > the C code you are replacing didn't do.  This is a change in behavior
> > that should at least be documented, if not fixed.
> 
> This is deliberate -- to my mind I'm fixing the same bug as the one in
> server.el.  other-buffer recreates *scratch* for the same sort of
> reasons that 'emacsclient -nc' does.
> 
> Where were you thinking it should be documented?  The Emacs Lisp changes
> section of NEWS?

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

> > I also wonder whether we should use safe_call in these places.
> 
> Could you say more?

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?

Previous Next

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