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

Previous Next

Full log

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

From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77389 <at> debbugs.gnu.org
Subject: Re: bug#77389: 31.0.50; Restarting Emacs with (kill-emacs ... t)
 looses noninteractivity
Date: Thu, 3 Apr 2025 21:52:33 +0200

On 2025-04-03  07:10, Eli Zaretskii wrote:
>> Date: Wed, 2 Apr 2025 22:54:23 +0200
>> Cc: 77389 <at> debbugs.gnu.org
>> From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
>>
>>> 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?
>>
>> Because the state of the original session (most notably the loaded
>> features) influences (and gets influenced by) that Lisp.
> 
> If you really do need to do something in a pristine Emacs, do that in
> a separate sub-process, then read the results.  That's what we do with
> native-compilation, for example.

Thanks for the discussion, now we are basically at the point
where I failed to see a straightforward solution further on
and resorted to `(kill-emacs ... t)'.  Because:

The driving Elisp (foo.el) is only ever to be called as a script.
If I wanted to spawn a pristine and equally non-interactive Emacs
session from foo.el and present its STDOUT and STDERR together
with that of foo.el, then I would need to do so through an async
process, right?  With all the effort of setting up a sentinel and
a filter just to forward the child Emacs's STDOUT and STDERR to,
well, STDOUT.

Given the effort described above simply calling `kill-process'
plus a bit of recursion control seemed the better or at least
easier solution to transfer control to a pristine Emacs process.

>> But back to my patch: I did a cursory grep for initial_arg[cv]
>> through current master.  From the results I got the impression
>> that instead of setting up a second copy raw_initial_arg[cv]
>> like done in the first patch, one could also try to directly
>> use initial_arg[cv], like in the attached alternative patch.
>> Should I go that route instead or would that be too risky,
>> anyway?
> 
> That's a possibility, but please make all this copy_raw_args and its
> calls #ifdef'ed away on WINDOWSNT, since we already do something like
> that there, just better.  Also, these additions need comments to
> explain why we do this.

Agreed.  I checked the grep results in more detail, resulting in
the following follow-up questions:

- I guess the following files all don't get compiled on Windows
  and any references to initial_arg[vc] can be safely ignored in
  these: src/nsterm.m, src/xterm.c, src/xsmfns.c, src/pgtkterm.c

- sysdep.c refers to initial_argv[0] in function emacs_perror
  and it seems it does so for Windows as well.  What should I
  do about that one?  Use simply constant "emacs"?  Or the
  result of w32_my_exename (plus any required coding system
  conversion)?

Previous Next

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