GNU bug report logs - #72018
30.0.60; [PATCH] Don't emit a prompt when a background Eshell process is killed

Previous Next

Package: emacs;

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


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

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72018 <at> debbugs.gnu.org
Subject: Re: bug#72018: 30.0.60; [PATCH] Don't emit a prompt when a background
 Eshell process is killed
Date: Wed, 10 Jul 2024 09:16:11 -0700
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.