emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Sean Whitton
Subject: Re: master f2d2fe6fc8: server-execute: Initialize the *scratch* buffer
Date: Wed, 04 May 2022 08:41:50 -0700
User-agent: Notmuch/0.36 Emacs/29.0.50 (x86_64-pc-linux-gnu)

Hello,

On Wed 04 May 2022 at 10:42am -04, Stefan Monnier wrote:

>>> If you could factor out the commonality (and remove the gratuitous
>>> differences along the way), I'd be grateful.
>>> In my experience, it's always worth it in the long run (and it's
>>> generally an opportunity to improve the code, because once it only
>>> exists at a single place, it's much easier to add functionality and
>>> customizability to it).
>> In order to factor it out of the C as well I need to define it in C with
>> the DEFUN macro, right?  Otherwise each C callsite would have to use
>> Ffuncall, which doesn't seem right.
>
> Yup.  Using Ffuncall (of `call1`, call2`, ...) is not in itself
> a problem, especially for code like this which is not
> performance critical.  But I suspect that using a DEFUN might be a better
> option here for bootstrap reasons (if the code needs to be run before
> things like `subr.el` have been loaded).

In order to make all these cases consistent, my new code will (insert
(substitute-command-keys initial-scratch-message)), so it's going to
require that both help.el and startup.el have been loaded.  So I guess
it should be in Lisp.

It looks like Fother_window is called only from Fcall_interactively and
Fkill_buffer, so there probably isn't a bootstrapping issue if I make
those Ffuncall my new `get-initial-buffer-create'.  It looks like
bootstrapping C code just makes an empty *scratch* and leaves it to
startup.el to initialise it.

-- 
Sean Whitton



reply via email to

[Prev in Thread] Current Thread [Next in Thread]