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

Previous Next

Package: emacs;

Reported by: David Ponce <da_vid <at> orange.fr>

Date: Wed, 4 May 2022 08:33:02 UTC

Severity: normal

Found in version 29.0.50

Done: Sean Whitton <spwhitton <at> spwhitton.name>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Robert Pluim <rpluim <at> gmail.com>, 55257 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, emacs-devel <at> gnu.org
Subject: bug#55257: master f2d2fe6fc8: server-execute: Initialize the *scratch* buffer
Date: Mon, 09 May 2022 18:49:02 -0700
Hello,

On Mon 09 May 2022 at 02:11pm -04, Stefan Monnier wrote:

> I know you didn't like my `scratch-buffer--create` suggestion because of
> the double dash, but I think at least "scratch" would be very welcome in it.

I've done s/initial/scratch/ which is better because this function
always uses *scratch* rather than, say, looking at initial-buffer-choice.

> Now that I look at it again, it occurs to me that maybe we should do
> something like:
>
>     (defun scratch-buffer (&optional display)
>       "Create the \*scratch\* buffer.
>     If the buffer doesn't exist, create it first.
>     If DISPLAY (or when used interactively), switch to it."
>       (interactive (list t))
>       (let ((buf (get-buffer "*scratch*")))
>         (unless buf
>           ;; Don't touch the buffer contents or mode unless we know that
>           ;; we just created it.
>           (with-current-buffer (setq buf (get-buffer-create "*scratch*"))
>             (when initial-scratch-message
>               (insert (substitute-command-keys initial-scratch-message))
>               (set-buffer-modified-p nil))
>             (funcall initial-major-mode)))
>         (when display (pop-to-buffer-same-window buf))
>         buf))
>
> i.e. combine the new function with the existing command, so we don't
> need to come up with a new name.

Nice idea, but I'd argue for keeping them separate.  I find it more
natural to distinguish functions called for their return values and
commands.

-- 
Sean Whitton




This bug report was last modified 3 years and 105 days ago.

Previous Next


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