bug#55041: 28.1; repeat-mode always prints message when enabled

bug#55041: 28.1; repeat-mode always prints message when enabled

[Howard Melman]

Minor thing: When repeat-mode is enabled it calls message with:

  "Repeat mode is enabled for %d commands and %d keymaps; see `describe-repeat-maps'."

I'm working on my configuration and of all the other minor-modes
I enable by calling from lisp, none of them print such a message,
so this stands out when I'm looking at *Messages*.

Modes such as this defined with define-minor-mode only print their
enabled/disabled message if called-interactively-p.  Perhaps
repeat-mode should do this for this message too.

Howard


In GNU Emacs 28.1 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 Version 10.14.6 (Build 18G95))
of 2022-04-04 built on builder10-14.lan
Windowing system distributor 'Apple', version 10.3.2022
System Description:  macOS 11.6.5

bug#55041: 28.1; repeat-mode always prints message when enabled

[Juri Linkov]

> Minor thing: When repeat-mode is enabled it calls message with:
>
>   "Repeat mode is enabled for %d commands and %d keymaps; see `describe-repeat-maps'."
>
> I'm working on my configuration and of all the other minor-modes
> I enable by calling from lisp, none of them print such a message,
> so this stands out when I'm looking at *Messages*.

This is exactly the reason why it outputs its statistics to *Messages*,
so you could see how many commands are affected by this mode.
Also I see that it doesn't stand out too much,
for example, I have after starting Emacs in *Messages*:

  Starting new Ispell process /usr/bin/hunspell with american dictionary...done
  Repeat mode is enabled for 23 commands and 9 keymaps; see ‘describe-repeat-maps’.
  Cleaning up the recentf list...done (0 removed)
  Desktop: 1 frame, 19 buffers restored.

But if the majority will prefer to remove it, then I could commit such a patch.
So we need just one additional vote that supports this change :)

bug#55041: 28.1; repeat-mode always prints message when enabled

[Howard Melman]

On Apr 20, 2022, at 1:10 PM, Juri Linkov <juri@linkov.net> wrote:
> 
>> Minor thing: When repeat-mode is enabled it calls message with:
>> 
>>  "Repeat mode is enabled for %d commands and %d keymaps; see `describe-repeat-maps'."
>> 
>> I'm working on my configuration and of all the other minor-modes
>> I enable by calling from lisp, none of them print such a message,
>> so this stands out when I'm looking at *Messages*.
> 
> This is exactly the reason why it outputs its statistics to *Messages*,
> so you could see how many commands are affected by this mode.
> Also I see that it doesn't stand out too much,
> for example, I have after starting Emacs in *Messages*:
> 
>  Starting new Ispell process /usr/bin/hunspell with american dictionary...done
>  Repeat mode is enabled for 23 commands and 9 keymaps; see ‘describe-repeat-maps’.
>  Cleaning up the recentf list...done (0 removed)
>  Desktop: 1 frame, 19 buffers restored.
> 
> But if the majority will prefer to remove it, then I could commit such a patch.
> So we need just one additional vote that supports this change :)

I also found that recentf does something similar.  So if a few things give these
informational messages (particularly to *Messages*) then I have no complaints.
Seeing just the one I thought it might be violating a convention.  Feel free to 
close this.

Howard

bug#55041: 28.1; repeat-mode always prints message when enabled

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> But if the majority will prefer to remove it, then I could commit such
> a patch.  So we need just one additional vote that supports this
> change :)

I vote for keeping the message, but I have no strong opinion.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#55041: 28.1; repeat-mode always prints message when enabled

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Juri Linkov <juri@linkov.net> writes:
>
>> But if the majority will prefer to remove it, then I could commit such
>> a patch.  So we need just one additional vote that supports this
>> change :)
>
> I vote for keeping the message, but I have no strong opinion.

Why though?  How does it help me as a user?  And if I do need this
information for some reason, why can't I just flip the mode off and on
again?

I would vote for getting rid of it, FWIW.

bug#55041: 28.1; repeat-mode always prints message when enabled

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

>> I vote for keeping the message, but I have no strong opinion.
>
> Why though?  How does it help me as a user?  And if I do need this
> information for some reason, why can't I just flip the mode off and on
> again?
>
> I would vote for getting rid of it, FWIW.

I can't remember what my reasoning was back then, and looking at it
again, I agree with you -- it doesn't really seem very useful to a user.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#55041: 28.1; repeat-mode always prints message when enabled

[Juri Linkov]

>>> But if the majority will prefer to remove it, then I could commit such
>>> a patch.  So we need just one additional vote that supports this
>>> change :)
>>
>> I vote for keeping the message, but I have no strong opinion.
>
> Why though?  How does it help me as a user?  And if I do need this
> information for some reason, why can't I just flip the mode off and on
> again?

Every minor mode displays a message, e.g.:

  M-x delete-selection-mode
  Delete-Selection mode enabled

  M-x electric-pair-mode
  Electric-Pair mode enabled

  ...
  ...

repeat-mode just adds more useful information to such messages.

bug#55041: 28.1; repeat-mode always prints message when enabled

[Howard Melman]

> On Jun 20, 2022, at 12:51 PM, Juri Linkov <juri@linkov.net> wrote:
> 
>>>> But if the majority will prefer to remove it, then I could commit such
>>>> a patch.  So we need just one additional vote that supports this
>>>> change :)
>>> 
>>> I vote for keeping the message, but I have no strong opinion.
>> 
>> Why though?  How does it help me as a user?  And if I do need this
>> information for some reason, why can't I just flip the mode off and on
>> again?
> 
> Every minor mode displays a message, e.g.:
> 
>  M-x delete-selection-mode
>  Delete-Selection mode enabled
> 
>  M-x electric-pair-mode
>  Electric-Pair mode enabled

My original report was about enabling these in init.el and seeing the
message in the *Messages* buffer.  I have the following in my init:

(size-indication-mode)
(column-number-mode)
(show-paren-mode)
(recentf-mode)
(which-function-mode)
(global-hl-line-mode)
(context-menu-mode)			; new in Emacs 28
(global-so-long-mode)
(repeat-mode)				; new in Emacs 28

Of the above, only recentf-mode and repeat-mode write to the
*Messages* buffer on startup.  I added electric-pair-mode to my
init and it did not write to *Messages* though if I toggle it interactively
with M-x it does output (I assume to the echo area).

Howard

bug#55041: 28.1; repeat-mode always prints message when enabled

[Stefan Kangas]

Howard Melman <hmelman@gmail.com> writes:

> My original report was about enabling these in init.el and seeing the
> message in the *Messages* buffer.  I have the following in my init:
>
> (size-indication-mode)
> (column-number-mode)
> (show-paren-mode)
> (recentf-mode)
> (which-function-mode)
> (global-hl-line-mode)
> (context-menu-mode)                     ; new in Emacs 28
> (global-so-long-mode)
> (repeat-mode)                           ; new in Emacs 28
>
> Of the above, only recentf-mode and repeat-mode write to the
> *Messages* buffer on startup.  I added electric-pair-mode to my
> init and it did not write to *Messages* though if I toggle it interactively
> with M-x it does output (I assume to the echo area).

Right.  Using that config, I get the following *Messages* buffer after
starting Emacs:

  For information about GNU Emacs and the GNU system, type C-h C-a.
  Cleaning up the recentf list...done (0 removed)
  Repeat mode is enabled for 14 commands and 7 keymaps; see
‘describe-repeat-maps’.

Personally, I think we should remove both the recentf-mode and
repeat-mode messages here.  I don't find either of them very helpful
or interesting.

bug#55041: 28.1; repeat-mode always prints message when enabled

[Juri Linkov]

> Using that config, I get the following *Messages* buffer after
> starting Emacs:
>
>   For information about GNU Emacs and the GNU system, type C-h C-a.
>   Cleaning up the recentf list...done (0 removed)
>   Repeat mode is enabled for 14 commands and 7 keymaps; see
> ‘describe-repeat-maps’.
>
> Personally, I think we should remove both the recentf-mode and
> repeat-mode messages here.  I don't find either of them very helpful
> or interesting.

It's very surprising to worry about keeping the *Messages* buffer clean.

bug#55041: 28.1; repeat-mode always prints message when enabled

[Drew Adams]

> It's very surprising to worry about keeping
> the *Messages* buffer clean.

+1.

If this is a user concern then the only reasonable
approach is one that gives individual users control.

You can't reasonably guess what this or that user
considers "clean" vs noisy.

I'm not suggesting that Emacs needs a way for users
to control this.  I'm suggesting that IF you start
to worry about this, and are tempted to change
whether this or that gets logged in *Messages* THEN
please don't do that but instead provide a way for
_users_ to control it somehow.

bug#55041: 28.1; repeat-mode always prints message when enabled

[Howard Melman]

On Jun 21, 2022, at 1:49 PM, Juri Linkov <juri@linkov.net> wrote:
> 
> It's very surprising to worry about keeping the *Messages* buffer clean.

I don't usually.  In this case I was working at reducing my startup time
(from ~3 secs to ~1 sec). 

My init is broken up into about 2 dozen files; logical groupings like some 
major modes I typically use, mac settings, gnus stuff, magit stuff,
dired, minor modes, etc.  I load each with a function that times the load
and prints it out with some gc info.  Here's part of what I saw:

Loaded in   0.21ms with 0 gcs hrm-funcs
Loaded in   1.08ms with 0 gcs hrm-frame
Loaded in   1.11ms with 0 gcs hrm-tabs
Loading /Users/hmelman/.emacs.d/recentf...done
Cleaning up the recentf list...
File /Users/hmelman/Library/Mobile Documents/iCloud~md~obsidian/Documents/Film Lists/Alfred Hitchcock.md removed from the recentf list
Cleaning up the recentf list...done (1 removed)
Repeat mode is enabled for 14 commands and 7 keymaps; see `describe-repeat-maps'.
Loaded in 252.90ms with 0 gcs hrm-minor.....VERY LONG
Loaded in  42.70ms with 0 gcs hrm-packages.....LONG
Loaded in   2.03ms with 0 gcs hrm-help
Loaded in   0.73ms with 0 gcs hrm-git

As I said in the OP:

> I'm working on my configuration and of all the other minor-modes

> I enable by calling from lisp, none of them print such a message,

> so this stands out when I'm looking at *Messages*.

Since nothing else printed out stuff I thought it might have been
a mistake that the new repeat-mode command did.

Howard

bug#55041: 28.1; repeat-mode always prints message when enabled

[Juri Linkov]

>> It's very surprising to worry about keeping the *Messages* buffer clean.
>
> I don't usually.  In this case I was working at reducing my startup time
> (from ~3 secs to ~1 sec).
>
> My init is broken up into about 2 dozen files; logical groupings like some
> major modes I typically use, mac settings, gnus stuff, magit stuff,
> dired, minor modes, etc.  I load each with a function that times the load
> and prints it out with some gc info.  Here's part of what I saw:
>
> Loaded in   0.21ms with 0 gcs hrm-funcs
> Loaded in   1.08ms with 0 gcs hrm-frame
> Loaded in   1.11ms with 0 gcs hrm-tabs
> Loading /Users/hmelman/.emacs.d/recentf...done
> Cleaning up the recentf list...
> File /Users/hmelman/Library/Mobile Documents/iCloud~md~obsidian/Documents/Film Lists/Alfred Hitchcock.md removed from the recentf list
> Cleaning up the recentf list...done (1 removed)
> Repeat mode is enabled for 14 commands and 7 keymaps; see `describe-repeat-maps'.
> Loaded in 252.90ms with 0 gcs hrm-minor.....VERY LONG
> Loaded in  42.70ms with 0 gcs hrm-packages.....LONG
> Loaded in   2.03ms with 0 gcs hrm-help
> Loaded in   0.73ms with 0 gcs hrm-git

Do you think it would help you to disable messages during activating these modes:

  (let (inhibit-message message-log-max)
    (size-indication-mode)
    (column-number-mode)
    (show-paren-mode)
    (recentf-mode)
    (which-function-mode)
    (global-hl-line-mode)
    (context-menu-mode)
    (global-so-long-mode)
    (repeat-mode))

> As I said in the OP:
>
>> I'm working on my configuration and of all the other minor-modes
>
>> I enable by calling from lisp, none of them print such a message,
>
>> so this stands out when I'm looking at *Messages*.
>
> Since nothing else printed out stuff I thought it might have been
> a mistake that the new repeat-mode command did.

Strange, I see a lot of such stuff in the *Messages* buffer:

  Cleaning up the recentf list...
  File ~/src/emacs/.git/MERGE_MSG removed from the recentf list
  Cleaning up the recentf list...done (1 removed)
  Repeat mode is enabled for 23 commands and 9 keymaps; see ‘describe-repeat-maps’
  Starting new Ispell process /usr/bin/hunspell with american dictionary...done
  Wrote ~/.emacs.d/.emacs.desktop.lock
  Desktop: 1 frame, 24 buffers restored.

bug#55041: 28.1; repeat-mode always prints message when enabled

[Howard Melman]

> On Jun 22, 2022, at 3:33 AM, Juri Linkov <juri@linkov.net> wrote:
> 
> Do you think it would help you to disable messages during activating these modes:
> 
>  (let (inhibit-message message-log-max)
>    (size-indication-mode)
>    (column-number-mode)
>    (show-paren-mode)
>    (recentf-mode)
>    (which-function-mode)
>    (global-hl-line-mode)
>    (context-menu-mode)
>    (global-so-long-mode)
>    (repeat-mode))
> 
>> Since nothing else printed out stuff I thought it might have been
>> a mistake that the new repeat-mode command did.
> 
> Strange, I see a lot of such stuff in the *Messages* buffer:
> 
>  Cleaning up the recentf list...
>  File ~/src/emacs/.git/MERGE_MSG removed from the recentf list
>  Cleaning up the recentf list...done (1 removed)
>  Repeat mode is enabled for 23 commands and 9 keymaps; see ‘describe-repeat-maps’
>  Starting new Ispell process /usr/bin/hunspell with american dictionary...done
>  Wrote ~/.emacs.d/.emacs.desktop.lock
>  Desktop: 1 frame, 24 buffers restored.

So just two more than me: desktop, which I don't use and ispell which 
I don't pre-start the sub-process.

I could inhibit messages for those two but it seems a little messy.
I'd rather not inhibit generally in case there are issues, I'd have to
do it in each of my files so that I'd still see loading timings.  I could
do it for recentf and repeat-mode but that feels like working around
their specific behavior.

I'd kinda like to inhibit stdout and leave stderr, to put it in those terms.
IMHO the above seems like unnecessary information. Yes
it's specific, but it's also of little use.  I enabled repeat-mode, I expect
it to be enabled, I don't really care that 23 commands and 9 keymaps
were affected vs some other number of commands; and I don't need 
help like "see describe-repeat-maps" every time I enable it.

Howard

bug#55041: 28.1; repeat-mode always prints message when enabled

[Eli Zaretskii]

> Cc: 55041@debbugs.gnu.org, Lars Ingebrigtsen <larsi@gnus.org>,
>  Stefan Kangas <stefan@marxist.se>
> From: Howard Melman <hmelman@gmail.com>
> Date: Wed, 22 Jun 2022 09:16:17 -0400
> 
> So just two more than me: desktop, which I don't use and ispell which 
> I don't pre-start the sub-process.
> 
> I could inhibit messages for those two but it seems a little messy.

Please don't: those messages are both informative and important.

bug#55041: 28.1; repeat-mode always prints message when enabled

[Howard Melman]

On Jun 22, 2022, at 9:30 AM, Eli Zaretskii <eliz@gnu.org> wrote:

>> I could inhibit messages for those two but it seems a little messy.
> 
> Please don't: those messages are both informative and important.

The context was in my own config.

Could you explain why you find them important?  Why is it important
that I know recent is trimming some items when it reaches its max
limit?  That's just normal behavior.

Why is it important I know how many commands repeat-mode affects?
Other minor-modes (like cua-mode) don't tell me or log how many
bindings they provide.  And the "see describe-repeat-maps" point is in
the command's docstring which is the most natural place for it.

Both of these strike me as useful only when debugging.

To sum up so far:

Juri> This is exactly the reason why it outputs its statistics to *Messages*,

Juri> But if the majority will prefer to remove it, then I could
Juri> commit such a patch.  So we need just one additional vote that
Juri> supports this change :)

Howard> I also found that recentf does something similar.  So if a few
Howard> things give these informational messages (particularly to
Howard> *Messages*) then I have no complaints.  Seeing just the one I
Howard> thought it might be violating a convention.  Feel free to
Howard> close this.

But clearly I don't find these message useful :)

Lars> I vote for keeping the message, but I have no strong opinion.

Lars> I can't remember what my reasoning was back then, and looking at
Lars> it again, I agree with you -- it doesn't really seem very useful
Lars> to a user.

StefanK> Personally, I think we should remove both the recentf-mode
StefanK> and repeat-mode messages here.  I don't find either of them
StefanK> very helpful or interesting.

Eli> Please don't: those messages are both informative and important.

Howard

bug#55041: 28.1; repeat-mode always prints message when enabled

[Drew Adams]

> >> I could inhibit messages for those two but it seems a little messy.
> > Please don't: those messages are both informative and important.
> 
> Howard> ...Could you explain why you find them important?...
> Howard> To sum up so far:
> Juri> This is exactly the reason why it outputs its statistics to
>       *Messages*,
> Lars> I vote for keeping the message, but I have no strong opinion.
> Lars> ...looking at it again...it doesn't really seem very useful
> Lars> to a user.
> StefanK> ... we should remove both the recentf-mode
> StefanK> and repeat-mode messages here...
> Eli> Please don't: those messages are both informative and important.

1. *Messages* should record _all_ echo-area messages.
   As is, with no changes (curlifying quotes, fiddling
   with text properties, prettifying,...).  *Messages*
   is a _log_.

2. We can add various ways for users or libraries to
   optionally _view_ various subsets of such messages,
   or to _filter_ (remove) them, or to _inhibit adding_
   some of them.

   But all of that needs to be optional, under control
   by individual users or libraries, and _on top of_
   an underlying/default behavior of recording every
   echo-area message in *Messages* as is.

#2 has been discussed before, with no conclusions or
action taken.

I can't easily find the mail conversations about this,
and probably that doesn't matter - I think not much
that was concrete was proposed/discussed.

I did find these threads that touched on it, at least:

emacs-devel@gnu.org:

* Intelligent stacking of messages in the echo area
* Message's text-properties in *Messages*
* Why "symbol's value" error about a list?

Bug list:

* bug#40774: Error messages shouldn't be hidden when the user is idle
___

E.g., in the bug #40774 thread, I wrote:

  I wonder if buffer *Messages* shouldn't have a menu-bar
  menu, with a few items that do things like filter
  temporarily in various ways, change `message-log-max',
  etc.  Some things a user might want to do with the buffer
  content aren't necessarily obvious.

  IOW, *Messages* could probably be made more directly
  useful than it is now.

bug#55041: 28.1; repeat-mode always prints message when enabled

[Eli Zaretskii]

> From: Howard Melman <hmelman@gmail.com>
> Date: Wed, 22 Jun 2022 10:30:42 -0400
> Cc: juri@linkov.net,
>  55041@debbugs.gnu.org,
>  larsi@gnus.org,
>  stefan@marxist.se
> 
> On Jun 22, 2022, at 9:30 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> >> I could inhibit messages for those two but it seems a little messy.
> > 
> > Please don't: those messages are both informative and important.
> 
> The context was in my own config.
> 
> Could you explain why you find them important?  Why is it important
> that I know recent is trimming some items when it reaches its max
> limit?  That's just normal behavior.
> 
> Why is it important I know how many commands repeat-mode affects?
> Other minor-modes (like cua-mode) don't tell me or log how many
> bindings they provide.  And the "see describe-repeat-maps" point is in
> the command's docstring which is the most natural place for it.

I was talking only about desktop and ispell (the "those two" in your
message to which I replied).

> StefanK> Personally, I think we should remove both the recentf-mode
> StefanK> and repeat-mode messages here.  I don't find either of them
> StefanK> very helpful or interesting.
> 
> Eli> Please don't: those messages are both informative and important.

That's wrong attribution: I didn't reply to Stefan's message, I
replied to yours.

bug#55041: 28.1; repeat-mode always prints message when enabled

[Howard Melman]

On Jun 22, 2022, at 12:00 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Howard Melman <hmelman@gmail.com>
>> Date: Wed, 22 Jun 2022 10:30:42 -0400
>> Cc: juri@linkov.net,
>> 55041@debbugs.gnu.org,
>> larsi@gnus.org,
>> stefan@marxist.se
>> 
>> On Jun 22, 2022, at 9:30 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>>>> I could inhibit messages for those two but it seems a little messy.
>>> 
>>> Please don't: those messages are both informative and important.
> 
> I was talking only about desktop and ispell (the "those two" in your
> message to which I replied).

Apologies, I was talking about recentf and repeat-mode which Juri was asking
if I could inhibit messages for, so confusion all around it seems :)

>> StefanK> Personally, I think we should remove both the recentf-mode
>> StefanK> and repeat-mode messages here.  I don't find either of them
>> StefanK> very helpful or interesting.
>> 
>> Eli> Please don't: those messages are both informative and important.
> 
> That's wrong attribution: I didn't reply to Stefan's message, I
> replied to yours.

I did not mean to imply that you were replying to StefanK, I was trying
to list all the offered opinions about removing the message (for 
repeat-mode and possibly recentf) and I interpreted your reply as
being against doing so.

Howard

bug#55041: 28.1; repeat-mode always prints message when enabled

[Eli Zaretskii]

> From: Howard Melman <hmelman@gmail.com>
> Date: Wed, 22 Jun 2022 12:18:05 -0400
> Cc: Juri Linkov <juri@linkov.net>,
>  55041@debbugs.gnu.org,
>  larsi@gnus.org,
>  stefan@marxist.se
> 
> I did not mean to imply that you were replying to StefanK, I was trying
> to list all the offered opinions about removing the message (for 
> repeat-mode and possibly recentf) and I interpreted your reply as
> being against doing so.

To clarify: I'm only against shutting up desktop.el and ispell.el (out
of the list of packages that were discussed here).

bug#55041: 28.1; repeat-mode always prints message when enabled

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> To clarify: I'm only against shutting up desktop.el and ispell.el (out
> of the list of packages that were discussed here).

Both interactively and non-interactively?  (The suggestion is to make
these modes be silent when called non-interactively.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#55041: 28.1; repeat-mode always prints message when enabled

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Howard Melman <hmelman@gmail.com>,  juri@linkov.net,
>   55041@debbugs.gnu.org,  stefan@marxist.se
> Date: Thu, 23 Jun 2022 11:01:30 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > To clarify: I'm only against shutting up desktop.el and ispell.el (out
> > of the list of packages that were discussed here).
> 
> Both interactively and non-interactively?  (The suggestion is to make
> these modes be silent when called non-interactively.)

What do you mean by "non-interactively" in these two cases?

desktop.el runs automatically each time I restart Emacs, and ispell is
loaded and reloaded automatically whenever I visit a file in any
derivative of text-mode and whenever I the dictionary changes.  I
think those are deemed "non-interactive" for the purposes of your
question?  In both cases, it is important for me to see the messages.
For example, when the speller is restarted, I do want to see a message
telling me it is now using this or that dictionary.

bug#55041: 28.1; repeat-mode always prints message when enabled

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> What do you mean by "non-interactively" in these two cases?

Not interactive-p.  (Ish.)

> desktop.el runs automatically each time I restart Emacs, and ispell is
> loaded and reloaded automatically whenever I visit a file in any
> derivative of text-mode and whenever I the dictionary changes.  I
> think those are deemed "non-interactive" for the purposes of your
> question?  In both cases, it is important for me to see the messages.
> For example, when the speller is restarted, I do want to see a message
> telling me it is now using this or that dictionary.

In the olden days, it didn't tell you the current dictionary in the mode
line, I think?  But it does show you that now, so the message isn't as
interesting as it used to be.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#55041: 28.1; repeat-mode always prints message when enabled

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: hmelman@gmail.com,  juri@linkov.net,  55041@debbugs.gnu.org,
>   stefan@marxist.se
> Date: Thu, 23 Jun 2022 13:36:20 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > What do you mean by "non-interactively" in these two cases?
> 
> Not interactive-p.  (Ish.)
> 
> > desktop.el runs automatically each time I restart Emacs, and ispell is
> > loaded and reloaded automatically whenever I visit a file in any
> > derivative of text-mode and whenever I the dictionary changes.  I
> > think those are deemed "non-interactive" for the purposes of your
> > question?  In both cases, it is important for me to see the messages.
> > For example, when the speller is restarted, I do want to see a message
> > telling me it is now using this or that dictionary.
> 
> In the olden days, it didn't tell you the current dictionary in the mode
> line, I think?  But it does show you that now, so the message isn't as
> interesting as it used to be.

It doesn't show enough of it.  And a message in the echo area saying
the dictionary was changed is much more easily seen than 2 characters
that change in a crowded mode line.

bug#55041: 28.1; repeat-mode always prints message when enabled

[Juri Linkov]

> I'd kinda like to inhibit stdout and leave stderr, to put it in those terms.
> IMHO the above seems like unnecessary information. Yes
> it's specific, but it's also of little use.  I enabled repeat-mode, I expect
> it to be enabled, I don't really care that 23 commands and 9 keymaps
> were affected vs some other number of commands; and I don't need
> help like "see describe-repeat-maps" every time I enable it.

Then what do you think about doing what all minor modes do, i.e. to
display these messages conditionally on (called-interactively-p 'any).

bug#55041: 28.1; repeat-mode always prints message when enabled

[Howard Melman]

On Jun 22, 2022, at 2:30 PM, Juri Linkov <juri@linkov.net> wrote:
> 
>> I'd kinda like to inhibit stdout and leave stderr, to put it in those terms.
>> IMHO the above seems like unnecessary information. Yes
>> it's specific, but it's also of little use.  I enabled repeat-mode, I expect
>> it to be enabled, I don't really care that 23 commands and 9 keymaps
>> were affected vs some other number of commands; and I don't need
>> help like "see describe-repeat-maps" every time I enable it.
> 
> Then what do you think about doing what all minor modes do, i.e. to
> display these messages conditionally on (called-interactively-p 'any).

I think that would be fine, but I don't think "that" is what all minor modes do.

They do that for an enabled/disabled message via define-minor-mode,
which I think is certainly useful and correct.  They don't typically provide
such statistics at all.

Howard

bug#55041: 28.1; repeat-mode always prints message when enabled

[Stefan Kangas]

Juri Linkov <juri@linkov.net> writes:

> It's very surprising to worry about keeping the *Messages* buffer clean.

It's very minor, yes.

bug#55041: 28.1; repeat-mode always prints message when enabled

[Juri Linkov]

> My original report was about enabling these in init.el and seeing the
> message in the *Messages* buffer.  I have the following in my init:
>
> (size-indication-mode)
> (column-number-mode)
> (show-paren-mode)
> (recentf-mode)
> (which-function-mode)
> (global-hl-line-mode)
> (context-menu-mode)			; new in Emacs 28
> (global-so-long-mode)
> (repeat-mode)				; new in Emacs 28
>
> Of the above, only recentf-mode and repeat-mode write to the
> *Messages* buffer on startup.  I added electric-pair-mode to my
> init and it did not write to *Messages* though if I toggle it interactively
> with M-x it does output (I assume to the echo area).

I see now that define-minor-mode displays the message conditionally on

  (called-interactively-p 'any)

Maybe repeat-mode could do the same.