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 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
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.