From: Jim Porter <jporterbugs@gmail.com>
To: Davide Masserut <dm@mssdvd.com>
Cc: 65604@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>, me@eshelyaron.com
Subject: bug#65604: [PATCH] Display the exit code if the last command failed in Eshell
Date: Sat, 2 Sep 2023 11:40:53 -0700 [thread overview]
Message-ID: <1f740d2f-ee68-7157-b6bb-d2725c9c67c3@gmail.com> (raw)
In-Reply-To: <87msy4yl2c.fsf@mssdvd.com>
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.
next prev parent reply other threads:[~2023-09-02 18:40 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-29 22:24 bug#65604: [PATCH] Display the exit code if the last command failed in Eshell Davide Masserut via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-30 1:52 ` Jim Porter
2023-08-30 9:18 ` Davide Masserut via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-30 15:26 ` Davide Masserut via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-30 15:34 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-30 16:45 ` Eli Zaretskii
2023-08-30 16:58 ` Eli Zaretskii
2023-08-30 19:02 ` Davide Masserut via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-30 19:25 ` Eli Zaretskii
2023-08-30 19:59 ` Davide Masserut via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-30 20:20 ` Davide Masserut via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-31 4:52 ` Eli Zaretskii
2023-08-31 9:31 ` Davide Masserut via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-02 5:17 ` Jim Porter
2023-09-02 8:47 ` Davide Masserut via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-02 18:40 ` Jim Porter [this message]
2023-09-02 18:54 ` Davide Masserut via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-02 22:46 ` Jim Porter
2023-09-10 14:44 ` Sean Whitton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1f740d2f-ee68-7157-b6bb-d2725c9c67c3@gmail.com \
--to=jporterbugs@gmail.com \
--cc=65604@debbugs.gnu.org \
--cc=dm@mssdvd.com \
--cc=eliz@gnu.org \
--cc=me@eshelyaron.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).