* bug#50184: emacsclient -n should clear the minibuffer
@ 2021-08-24 13:15 積丹尼 Dan Jacobson
2021-08-25 11:54 ` Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: 積丹尼 Dan Jacobson @ 2021-08-24 13:15 UTC (permalink / raw)
To: 50184
C-x C-f clears any words sitting in the minibuffer.
So should emacsclient -n.
Try this:
M-! date
C-x C-f somefile
Vs.
M-x server-start
M-! date
$ emacsclient -n somefile
That the date is still sitting there is weird.
emacs-version "27.1"
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#50184: emacsclient -n should clear the minibuffer
2021-08-24 13:15 bug#50184: emacsclient -n should clear the minibuffer 積丹尼 Dan Jacobson
@ 2021-08-25 11:54 ` Lars Ingebrigtsen
2021-08-25 12:23 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-25 11:54 UTC (permalink / raw)
To: 積丹尼 Dan Jacobson; +Cc: 50184
積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:
> C-x C-f clears any words sitting in the minibuffer.
> So should emacsclient -n.
>
> Try this:
> M-! date
> C-x C-f somefile
>
> Vs.
> M-x server-start
> M-! date
> $ emacsclient -n somefile
>
> That the date is still sitting there is weird.
When reusing the Emacs frame, it seems kinda natural to not touch the
minibuffer area -- I can imagine that some people have work flows that
depend on not losing the message.
Anybody got an opinion here?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#50184: emacsclient -n should clear the minibuffer
2021-08-25 11:54 ` Lars Ingebrigtsen
@ 2021-08-25 12:23 ` Eli Zaretskii
2021-08-25 20:43 ` 積丹尼 Dan Jacobson
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2021-08-25 12:23 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: jidanni, 50184
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 25 Aug 2021 13:54:42 +0200
> Cc: 50184@debbugs.gnu.org
>
> > That the date is still sitting there is weird.
>
> When reusing the Emacs frame, it seems kinda natural to not touch the
> minibuffer area -- I can imagine that some people have work flows that
> depend on not losing the message.
>
> Anybody got an opinion here?
I also don't see why emacsclient should produce the same behavior as
an internal command. We only clear the echo area when the next
interactive command arrives, and emacsclient doesn't invoke any
commands interactively.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#50184: emacsclient -n should clear the minibuffer
2021-08-25 12:23 ` Eli Zaretskii
@ 2021-08-25 20:43 ` 積丹尼 Dan Jacobson
2021-08-26 6:45 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: 積丹尼 Dan Jacobson @ 2021-08-25 20:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 50184
Proof:
Do C-x =.
it says
Char: s (115, #o163, #x73) point=474 of 1163 (41%) column=6
OK, now do
$ emacsclient -n some.file
So the character under the cursor is still
Char: s (115, #o163, #x73) point=474 of 1163 (41%) column=6
??
Little chance.
OK, now repeat the experiment,
but instead of emacsclient -n,
use C-x C-f to open that file.
Well, why not restore the (now invalid)
Char: s (115, #o163, #x73) point=474 of 1163 (41%) column=6
here too?
Yes, that would be nonsense.
Why not always have the last message in the minibuffer stay there.
Bad idea also.
>> When reusing the Emacs frame, it seems kinda natural to not touch the
>> minibuffer area -- I can imagine that some people have work flows that
>> depend on not losing the message.
For every one of such workflows, I have 100 that say clearing the
minibuffer would be more appropriate.
Just like if we are looking at a picture of Bob in some app, and now we
switch to a picture of Mary, but her picture doesn't have a name.
Well to play it safe we still should clear the title.
EZ> I also don't see why emacsclient should produce the same behavior as
EZ> an internal command. We only clear the echo area when the next
EZ> interactive command arrives, and emacsclient doesn't invoke any
EZ> commands interactively.
OK, but when is that better.
Only when we did
M-! date,
and we need to keep looking at the date all day long?
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#50184: emacsclient -n should clear the minibuffer
2021-08-25 20:43 ` 積丹尼 Dan Jacobson
@ 2021-08-26 6:45 ` Eli Zaretskii
2021-09-23 21:56 ` Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2021-08-26 6:45 UTC (permalink / raw)
To: 積丹尼 Dan Jacobson; +Cc: larsi, 50184
> From: 積丹尼 Dan Jacobson <jidanni@jidanni.org>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 50184@debbugs.gnu.org
> Date: Thu, 26 Aug 2021 04:43:55 +0800
>
> Proof:
> Do C-x =.
> it says
> Char: s (115, #o163, #x73) point=474 of 1163 (41%) column=6
>
> OK, now do
> $ emacsclient -n some.file
>
> So the character under the cursor is still
> Char: s (115, #o163, #x73) point=474 of 1163 (41%) column=6
> ??
>
> Little chance.
It is a fallacy to assign some kind of "truth value" to the echo-area
message, and expect it to disappear when it's no longer "true". Those
messages are just that: echoes of some past command.
More generally, Emacs keeps the echo-area messages because they might
be important, and because Emacs has no idea about the true meaning of
the messages. You made a straw man argument by picking up a message
that is highly context dependent, but what if that message would show
something like a text message from your loved one, or the date and
time of your death?
There's no way I can see that we could distinguish between messages
that should stay and those which should go. I can tell you from my
experience that I frequently have important messages go when I'd like
them to stay.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#50184: emacsclient -n should clear the minibuffer
2021-08-26 6:45 ` Eli Zaretskii
@ 2021-09-23 21:56 ` Lars Ingebrigtsen
0 siblings, 0 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2021-09-23 21:56 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 積丹尼 Dan Jacobson, 50184
Eli Zaretskii <eliz@gnu.org> writes:
> There's no way I can see that we could distinguish between messages
> that should stay and those which should go. I can tell you from my
> experience that I frequently have important messages go when I'd like
> them to stay.
So I think the conclusion here is that we don't want to change the
behaviour here, and I'm therefore closing this bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-09-23 21:56 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-24 13:15 bug#50184: emacsclient -n should clear the minibuffer 積丹尼 Dan Jacobson
2021-08-25 11:54 ` Lars Ingebrigtsen
2021-08-25 12:23 ` Eli Zaretskii
2021-08-25 20:43 ` 積丹尼 Dan Jacobson
2021-08-26 6:45 ` Eli Zaretskii
2021-09-23 21:56 ` Lars Ingebrigtsen
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).