* 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).