bug#65604: [PATCH] Display the exit code if the last command failed in Eshell

[Jim Porter]

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@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.