From: Drew Adams <drew.adams@oracle.com>
To: "Lars Ingebrigtsen" <larsi@gnus.org>,
"積丹尼 Dan Jacobson" <jidanni@jidanni.org>
Cc: "51132@debbugs.gnu.org" <51132@debbugs.gnu.org>
Subject: bug#51132: [External] : bug#51132: Make sure user is doubly aware of finished complilations
Date: Mon, 11 Oct 2021 14:41:53 +0000 [thread overview]
Message-ID: <SJ0PR10MB5488C4F1B9AB6358A7E1F6F4F3B59@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <87czocj6d9.fsf@gnus.org>
> > OK, but then it disappears when the compilation is over.
>
> A message is issued, and I think that's sufficient. Closing.
FWIW:
I agree with the OP that a progress indication
should end with an indication that the thing in
progress is finished.
AND the indication should generally be of the same
type (at least - _additional_ indications are OK).
A message "Foobarring..." should generally be
followed when done by "Foobarring...done". And an
indication "Foobarring..." in the mode line should
generally be followed by an indication in the mode
line (e.g. "Foobarring...done").
This is just common sense, IMO. Saying that there's
some _other_ indication somewhere else, doesn't cut
the mustard. The "opening of the parenthesis" needs
to be followed by its closing in the same manner
(e.g. same place) - whatever that manner might be.
It shouldn't be difficult to update the mode-line
indication to add "...done". And the first user
action can erase that indication. (Ideally, a user
action might cause such a mode-line message to be
copied to `*Messages*' or some other log, if there
is no other progress indication than that in the
mode line.
I see no reason for the justification of won't-fix
that just because there's an echo-area message that
the process is done there should be no mode-line
indication as well.
Just one opinion.
next prev parent reply other threads:[~2021-10-11 14:41 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-11 6:50 bug#51132: Make sure user is doubly aware of finished complilations 積丹尼 Dan Jacobson
2021-10-11 8:46 ` Lars Ingebrigtsen
2021-10-11 9:21 ` Kévin Le Gouguec
2021-10-11 14:44 ` bug#51132: [External] : " Drew Adams
2021-10-11 16:03 ` Eli Zaretskii
2021-10-11 16:21 ` Drew Adams
2021-10-11 16:31 ` Eli Zaretskii
2021-10-11 16:44 ` Drew Adams
2021-10-12 8:01 ` 積丹尼 Dan Jacobson
2021-10-12 13:59 ` Eli Zaretskii
2021-10-11 14:41 ` Drew Adams [this message]
2021-10-11 16:03 ` Eli Zaretskii
2021-10-11 16:13 ` Drew Adams
2021-10-11 12:16 ` Eli Zaretskii
2021-10-12 8:04 ` 積丹尼 Dan Jacobson
2021-10-12 14:00 ` Eli Zaretskii
2021-10-12 15:16 ` Kévin Le Gouguec
2021-10-12 16:11 ` Eli Zaretskii
2021-10-12 18:24 ` Kévin Le Gouguec
2021-10-20 1:09 ` 積丹尼 Dan Jacobson
2021-10-20 6:09 ` Kévin Le Gouguec
2021-10-22 12:32 ` 積丹尼 Dan Jacobson
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=SJ0PR10MB5488C4F1B9AB6358A7E1F6F4F3B59@SJ0PR10MB5488.namprd10.prod.outlook.com \
--to=drew.adams@oracle.com \
--cc=51132@debbugs.gnu.org \
--cc=jidanni@jidanni.org \
--cc=larsi@gnus.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.