GNU bug report logs - #77389
31.0.50; Restarting Emacs with (kill-emacs ... t) looses noninteractivity

Previous Next

Full log

Message #14 received at 77389 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Cc: 77389 <at> debbugs.gnu.org
Subject: Re: bug#77389: 31.0.50; Restarting Emacs with (kill-emacs ... t)
 looses noninteractivity
Date: Wed, 02 Apr 2025 14:43:47 +0300

> Date: Tue, 1 Apr 2025 22:52:48 +0200
> From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
> Cc: 77389 <at> debbugs.gnu.org
> 
> >>   - But I do have a valid use case for a non-interactive restart,
> >>     so I created this bug report ... ]
> > 
> > Please describe your use case.
> 
> TL;DR:
> 
> 1. Start foo.el in batch mode with "emacs --script foo.el".
> 2. foo.el reads the user init file and writes a modified copy of
>    it to init-new.el.
> 3. Then foo.el calls (kill-emacs ... t), thus restarting itself,
>    (hopefully) still in batch mode.
> 4. The newly started foo.el senses the presence of init-new.el
>    and, hence, processes that in a final step.
> 
> In the above it is important that steps 2 and 4 are executed
> from different, newly started Emacs processes which share STDOUT
> and STDERR.

Why do you need to write Lisp to a file, only to have that file read
and executed? why not simply execute that Lisp directly in the
original session?

> The only thing that bothers me a bit is that there is the following
> memory-related initialization being executed in main *after*
> copy_raw_args (or also the present sort_args) have already been
> allocating memory:

Why does this bother you?  The old session is going down, and the new
one will re-execute that part anew, no?  What did I miss?

Previous Next

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