From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>, Drew Adams <drew.adams@oracle.com>
Cc: 3465@debbugs.gnu.org, larsi@gnus.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 12:17:16 -0700 (PDT) [thread overview]
Message-ID: <12b66207-14ef-46aa-98d5-533362f0a3ea@default> (raw)
In-Reply-To: <<83zh6m8r4e.fsf@gnu.org>>
> > The request is to be able to have `minibuffer-message'
> > output logged, WITHOUT calling `message'.
>
> Why "without"?
Treat `minibuffer-message' as first-class, the same
way `message' is treated. `message' shouldn't affect
`minibuffer-message', and vice versa.
`message' has an easy way to do what's requested;
`minibuffer-message' does not have one.
> > It's about simply controlling logging for
> > `minibuffer-message', totally, completely, independent
> > of any use of `message'.
>
> You want every single call to minibuffer-message to be logged in
> *Messages*? I'm guessing not, because this would make no sense.
Not at all. What makes you think that?
I think I made it clear that the request is to be able
to have, for `minibuffer-message', control over logging
similar to what we have for `message'.
They are separate. They should remain separate.
All that's being requested is logging control
for `minibuffer-message' that's on a par with the
logging control for `message'.
> If you want to log only _some_ calls to minibuffer-message, then you
> will have to have special code to request that in those places where
> you want the minibuffer messages to be logged. I'm saying that you
> can easily call 'message' in those places, and be done with that.
What I want is to be able to do with and for
`minibuffer-message' what I can do with and for
`message'. Without any use of `message' - no
connection between the two, no dependence of
either on the other.
> > IOW, please forget about `message'. The request is
> > for a simple way to (optionally) log output of
> > `minibuffer-message', just as we do, for example for
> > `message' output. And without recourse to any call
> > to `message' - no workaround, just a simple way to
> > log `minibuffer-message'. We have such a way for
> > `message' output. The request is for such a way for
> > `minibuffer-message' output - totally independent
> > from `message'.
>
> You cannot request a feature and then also dictate
> how it is implemented.
I in no way dictated anything about implementation.
I have said absolutely nothing about implementation.
The entire request is expressed in terms of behavior:
user-visible, user-controllable behavior. Nothing
about implementation. It's about what users can do.
> The solution I proposed should do what you want without
> requiring any changes to the core.
See above. It doesn't do what was requested.
> > > You are already able to do that, AFAICT.
> >
> > Not simply.
>
> It's simple enough, from where I stand. Certainly
> so for a minor feature such as this one.
next parent reply other threads:[~2020-08-22 19:17 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[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 [this message]
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
2020-08-22 17:02 ` bug#4477: " Eli Zaretskii
2020-08-22 18:11 ` Drew Adams
2020-08-22 18:34 ` Lars Ingebrigtsen
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=12b66207-14ef-46aa-98d5-533362f0a3ea@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 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.