Re: master f2d2fe6fc8: server-execute: Initialize the *scratch* buffer

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> 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"?

Modify the buffer in any way (change its content or some of its
buffer-local variables (e.g. the major mode)).

His code just reproduces the existing code's behavior, AFAICT.

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

Not sure what it is we'd be gaining.

The code is just trying to avoid modifying the buffer in any way (since
that would likely lose information or undo something the user did,
without its explicit request).

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

Indeed `get-buffer-create` begins by calling `get-buffer` so there's
redundancy at run-time.  But we don't export any `create-buffer`
function which presumes that there is no buffer by that name, so when
we want to create a buffer named *scratch* and we know there is no such
buffer yet, we still have to call `get-buffer-create` :-(

Since we want to preserve the invariant that there can't be two buffers
with the same name, we don't have much choice in this matter (we
couldn't offer a `create-buffer` and just trust users to only call it
when it's safe, tho we could do that in the C code that's not exported
to ELisp).

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

I think this is not needed here, or at least we haven't needed it so
far: the old C code called `Fset_buffer_major_mode` which itself
calls `call0 (function);` where `function` is the `initial-major-mode`.


        Stefan