GNU bug report logs -
#55041
28.1; repeat-mode always prints message when enabled
Previous Next
Full log
View this message in rfc822 format
On Jun 22, 2022, at 9:30 AM, Eli Zaretskii <eliz <at> 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
This bug report was last modified 2 years and 358 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.