GNU bug report logs -
#72018
30.0.60; [PATCH] Don't emit a prompt when a background Eshell process is killed
Previous Next
Reported by: Jim Porter <jporterbugs <at> gmail.com>
Date: Tue, 9 Jul 2024 18:05:01 UTC
Severity: normal
Tags: patch
Found in version 30.0.60
Done: Jim Porter <jporterbugs <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
On 7/10/2024 4:16 AM, Eli Zaretskii wrote:
>> Date: Tue, 9 Jul 2024 11:04:05 -0700
>> From: Jim Porter <jporterbugs <at> gmail.com>
>>
>> This is a regression from Emacs 29, likely due to some changes I made to
>> improve support for complex background commands. Eli, is this ok to
>> merge to the release branch?
>
> I don't think I understand the essence of the change, and thus cannot
> appreciate its effects enough to be able to answer this. What is the
> significance of '(car command)' in this hunk:
'command' is a "command entry", and the result of
'eshell-commands-for-process', which returns a list of elements of the form:
(BACKGROUND FORM PROCESSES)
BACKGROUND is non-nil if the command is being run in the background.
>> + ;; Reset the prompt if the command we just aborted was in the
>> + ;; foreground.
>> + (unless (car command)
>> + (declare-function eshell-reset "esh-mode" (&optional no-hooks))
>> + (eshell-reset)))))))
>
> IOW, why '(car command)' is used as an indication of a fore/background
> command? Also, why does the comment say "foreground" while your text
> says we don't want the prompt if the killed program was in the
> background?
We want to reset the prompt (this just emits a new command prompt) for
foreground commands, but for background commands, we don't need to do
anything. Would it be clearer if I inverted the wording in the comment,
like, "Don't reset the prompt if the command we just aborted was in the
background"?
This bug report was last modified 316 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.