GNU bug report logs -
#65604
[PATCH] Display the exit code if the last command failed in Eshell
Previous Next
Reported by: Davide Masserut <dm <at> mssdvd.com>
Date: Tue, 29 Aug 2023 22:45:01 UTC
Severity: normal
Tags: patch
Fixed in version 30.1
Done: Jim Porter <jporterbugs <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
Message #53 received at 65604 <at> debbugs.gnu.org (full text, mbox):
On 9/2/2023 1:47 AM, Davide Masserut via Bug reports for GNU Emacs, the
Swiss army knife of text editors wrote:
> Jim Porter <jporterbugs <at> gmail.com> writes:
>
>> Hmm, well if everyone else disagrees, I suppose I don't see any
>> *major* issues with including the exit status in the prompt, though
>> I'm a little worried it would annoy people who like the current
>> way. If it were easier to customize the prompt, I don't think I'd be
>> as worried. Fixing that for real is probably beyond the scope of this
>> bug, but I do have a WIP patch for it.
>
> What do you find difficult to customize?
>
> I can only think of two things:
>
> 1) The default function is quite simple, but displaying the bytecode in
> customization buffer can be confusing.
Yeah, mainly the Customize interface. It's a bit confusing, and when I
think back to when I didn't understand Elisp, I would have found any
customization of the Eshell prompt to be pretty intimidating.
I have a WIP patch for this though, which uses 'mode-line-format' to
make the Eshell prompt work more like the mode-line. It seems to work
pretty well, but I need to finish it up. (And especially to make sure it
doesn't do anything weird with multi-line prompts.)
> 2) It may require to update the regexp.
The prompt regexp is (thankfully) almost irrelevant in Emacs 30 now. It
only matters for paragraph-movement commands, which we could probably
just remap to the actual Eshell-specific commands to navigate forward
and backward through the prompts. I should probably just make a patch
for this and finally get rid of that regexp entirely.
> In this case I would add a small delay before signaling that something
> is running.
The delay isn't present in the current Eshell mode-line implementation,
and I don't think anyone's raised an issue about that...
> However, I'm not sure it is so useful to signaling it.
> When I suspect that the process is hanging, I usually use tools like top
> or proced to check if something is stuck, but otherwise I already know
> something is going on.
I think there's some use, especially for longer-running Lisp functions,
but that area is a bit of a mess anyway since it's tough to run Lisp
code asynchronously (or at least, in a way that meshes with Eshell).
> I believe some terminals update the title bar when something is running
> and send a notification when process ends and the window is not focused.
> But for such long operations compilation-mode works best for me (BTW,
> thank you for the new compile command).
Yeah, this is roughly what I'm thinking for Eshell. The mode-line seems
to me like a decent place for that info.
>> Do they? I tried to see what the default was for Bash and after some
>> searching, it seemed that it doesn't show the exit status by
>> default. But that could be wrong.
>
> Distros often change the default prompt.
Yeah, I tried to take that into account when I looked it up. The actual
default from GNU Bash is *very* basic, but what you get as a fresh user
on most distros is a little fancier. I didn't see that it reported the
exit status though.
... in any case, maybe the simplest way forward here is to put the
(non-zero) exit status in the prompt like your original patch, and then
separately, I can try to improve the customizability of the prompt, as
well as thinking about what to do with the mode-line.
This bug report was last modified 1 year and 256 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.