From: Drew Adams <drew.adams@oracle.com>
To: Lars Ingebrigtsen <larsi@gnus.org>, Eli Zaretskii <eliz@gnu.org>
Cc: 3465@debbugs.gnu.org, 4477@debbugs.gnu.org, bojohan@gnu.org
Subject: bug#3465: 23.0.94; feature request: be able to log minibuffer messages
Date: Sat, 22 Aug 2020 09:54:14 -0700 (PDT) [thread overview]
Message-ID: <f1623e09-ceee-4ba6-9cf2-205d292ee017@default> (raw)
In-Reply-To: <87ft8en62j.fsf@gnus.org>
> >> There's no problem with logging in general. The request is to also have
> >> the messages output by the minibuffer-message function also end up in
> >> the *Messages* buffer.
No. The request is to _be able_ to also log
`minibuffer-message' feedback.
> > By default? I'd object to that. As an option, maybe;
The bug requested to _be able to_ do it.
Not to do it by default.
> > but then I
> > don't understand why this is requested as a core feature, since any
> > Lisp program that wants this can simply call 'message' with the same
> > string, and be done.
No. `minibuffer-message' has an entirely different
UI effect. You are coupling the UI effect (messaging)
with the logging effect. It is you, even in your "but
then" (i.e., NOT by default), who are saying that
every time logging is wanted the UI effect of `message'
is also wanted.
That's exactly the point of this bug:
1. `message' and `minibuffer-message' have different UI
effects. They are used for different things.
2. `message' can be logged. `minibuffer-message' cannot.
The point is to be able to log `minibuffer-message',
WITHOUT getting the different UI effect of `message'.
Please reread the bug report. I don't think it's hard
to understand the request: Be able to also log
`minibuffer-message' output.
And obviously WITHOUT calling `message', which is not
logging `minibuffer-message' but logging `message',
and which adds the UI effect of `message'.
> I thought it would make sense to have that function behave as regularly
> as possible...
>
> However, looking at the use cases for minibuffer-message, all of the
> in-tree calls are trivial: "Confirm". "Incomplete". "Hit space to
> flush". All of those things are UI details that would be surprising to
> have land in the *Messages* buffer.
This is irrelevant. User code - 3rd-party libraries
can, and do, use `minibuffer-message' in other ways.
Don't judge what something is used for generally by
such trivial uses of it. Uses of the minibuffer by
vanilla Emacs are mostly trivial, There's not much
user interaction, not many keys/actions possible in
the minibuffer, etc.
> So I agree with Eli, and I don't think this is something that
> minibuffer-message should do at all. If something wants to do a
> minibuffer-message and log it, then that thing should just do both.
>
> So I'm closing this bug report.
Eli seems to have clearly misunderstood the request.
And you seem to have based your conclusion of how
`minibuffer-message' is and can be used only on its
few uses in the vanilla code, which are trivial uses.
Please reopen this enhancement request. It's simply
a request to _be able to_ log `minibuffer-message'
output. Not a big deal.
`message' does NOT replace `minibuffer-message', and
vice versa. Neither should be hard-code coupled with
logging. And each should be able to log, as well as
have its minibuffer UI effect.
The effects of the two functions should be totally
_independent_.
(And yes, Juri's recent changes that act against this
independence are a real step _backward_. I argued
this in vain in that context. Too bad.)
next prev parent reply other threads:[~2020-08-22 16:54 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-03 21:38 bug#3465: 23.0.94; feature request: be able to log minibuffer messages Drew Adams
2016-04-27 19:13 ` Lars Ingebrigtsen
2016-04-27 19:35 ` Drew Adams
2016-04-27 20:20 ` Johan Bockgård
2016-04-27 20:25 ` Lars Ingebrigtsen
2016-04-27 20:26 ` Lars Ingebrigtsen
2020-08-20 18:52 ` Lars Ingebrigtsen
2020-08-20 19:14 ` Eli Zaretskii
2020-08-20 19:18 ` Lars Ingebrigtsen
2020-08-20 19:41 ` Eli Zaretskii
2020-08-20 19:45 ` Lars Ingebrigtsen
2020-08-20 19:52 ` Eli Zaretskii
2020-08-20 20:03 ` Lars Ingebrigtsen
2020-08-20 23:40 ` Juri Linkov
2020-08-21 0:05 ` Lars Ingebrigtsen
2020-08-22 7:16 ` Eli Zaretskii
2020-08-22 13:49 ` Lars Ingebrigtsen
2020-08-22 16:54 ` Drew Adams [this message]
2020-08-22 17:02 ` bug#4477: " Eli Zaretskii
[not found] <<CE526A71768043CA82AE63F6386B70E7@us.oracle.com>
[not found] ` <<87a8keeufp.fsf@gnus.org>
[not found] ` <<87r3dq248n.fsf@gnu.org>
[not found] ` <<87ziseu7bh.fsf@gnus.org>
[not found] ` <<87zh6pkv4b.fsf@gnus.org>
[not found] ` <<83364hceou.fsf@gnu.org>
[not found] ` <<87k0xtktxc.fsf@gnus.org>
[not found] ` <<83wo1taywj.fsf@gnu.org>
[not found] ` <<871rk1ksob.fsf@gnus.org>
[not found] ` <<83sgchaydm.fsf@gnu.org>
[not found] ` <<87sgchjd9r.fsf@gnus.org>
[not found] ` <<83tuwv9mm2.fsf@gnu.org>
[not found] ` <<87ft8en62j.fsf@gnus.org>
[not found] ` <<f1623e09-ceee-4ba6-9cf2-205d292ee017@default>
[not found] ` <<834kouaa0y.fsf@gnu.org>
2020-08-22 18:11 ` Drew Adams
2020-08-22 18:34 ` Lars Ingebrigtsen
2020-08-22 18:36 ` bug#4477: " Eli Zaretskii
[not found] <<<CE526A71768043CA82AE63F6386B70E7@us.oracle.com>
[not found] ` <<<87a8keeufp.fsf@gnus.org>
[not found] ` <<<87r3dq248n.fsf@gnu.org>
[not found] ` <<<87ziseu7bh.fsf@gnus.org>
[not found] ` <<<87zh6pkv4b.fsf@gnus.org>
[not found] ` <<<83364hceou.fsf@gnu.org>
[not found] ` <<<87k0xtktxc.fsf@gnus.org>
[not found] ` <<<83wo1taywj.fsf@gnu.org>
[not found] ` <<<871rk1ksob.fsf@gnus.org>
[not found] ` <<<83sgchaydm.fsf@gnu.org>
[not found] ` <<<87sgchjd9r.fsf@gnus.org>
[not found] ` <<<83tuwv9mm2.fsf@gnu.org>
[not found] ` <<<87ft8en62j.fsf@gnus.org>
[not found] ` <<<f1623e09-ceee-4ba6-9cf2-205d292ee017@default>
[not found] ` <<<834kouaa0y.fsf@gnu.org>
[not found] ` <<028c363a-e801-4c9a-8ebd-d55180961cf7@default>
[not found] ` <<83zh6m8r4e.fsf@gnu.org>
2020-08-22 19:17 ` Drew Adams
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=f1623e09-ceee-4ba6-9cf2-205d292ee017@default \
--to=drew.adams@oracle.com \
--cc=3465@debbugs.gnu.org \
--cc=4477@debbugs.gnu.org \
--cc=bojohan@gnu.org \
--cc=eliz@gnu.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 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).