GNU bug report logs -
#55257
29.0.50; New command `scratch-buffer' inconsistent with startup
Previous Next
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
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.