On Sat, 28 Jun 2025 20:02:50 -0500 Rick <rbielaws@gmail.com> wrote:

> Sorry for the response delay.  I can't build Emacs myself and it took quite a
> bit of time to investigate thoroughly enough to answer usefully.

I appreciate your effort.

> To your immediate question.  Yes, suppression appears to work completely. 
> Thank you.

Thanks for confirming.

> However I dug in a little deeper and if don't find the result useful, I'm
> happy with the feature just tested.
>
> With (setq initial-buffer-choice 'recentf-open-files) in my .emacs  I see no
> log messages from recentf.  Good.  That's what started this.  But either this
> goes against the feature's design philosophy or the next behavior is
> incorrect. If I run recentf-open-files via my custom hotkey or via the menu,
> the messages ARE generated.  Why?  Although I do see why you think they should
> be there, I hope you see why, either these shouldn't get generated or the ones
> you suppressed shouldn't have been (yes, despite my complaint). 

There is a crucial difference between invoking `recentf-open-files' via
a key sequence or a menu and invoking it by setting the value of
`initial-buffer-choice' to `recentf-open-files': the former are in
effect the same as doing `M-x recentf-open-files', i.e., interactively
invoking the function, while the latter invokes the function
noninteractively (it's called from a Lisp program - your init file).  As
you pointed out at or near the beginning of this bug thread, and I
agree, showing the help messages is reasonable (as an option) only when
the the *Open recent* buffer is the current buffer, which is the case
when `recentf-open-files' is invoked interactively, but may not be the
case when it's invoked from Lisp.  Admittedly, calling it via
`initial-buffer-choice' could be seen as effectively equivalent to
calling it interactively, but accounting for that case would make the
code a bit more complicated, and since I haven't seen any other bug
reports involving this use case besides yours, and you don't want the
messages, I chose to keep the code simpler.

>                                                                  The truthful
> argument to shoot me down would have been "The REAL problem is that there is
> no way to show the Help message in the mini-buffer without it ending up in the
> log.  If you don't want to see help, maybe you want an enhancement to turn it
> off."

Setting `message-log-max' to nil prevents messages from being added to
the *Messages* buffer, and setting `inhibit-message' to non-nil prevents
displaying messages in the echo area but they are still added to
*Messages*.  But neither of those seems reasonable to me for the recentf
help messages; and the option to turn them off entirely (both in the
echo area and in *Messages*) now exists thanks to your bug report.

> Anyway, I then opened a recentf-edit-files buffer.  Despite it calling
> recentf-dialog-goto-first just like recentf-open-files does, the initial help
> DOESN'T display.  It seems likely this has been broken for a very long time
> but I don't know that for sure. I don't see how it could be related to what
> you did.

I guess you mean `recentf-edit-list', which does call
`recentf-dialog-goto-first', crucially with the argument 'checkbox, and
the checkbox widgets that `recentf-edit-list' also defines do not set
the `:help-echo' property: that's why no messages are displayed.  In
contrast, `recentf-open-files' calls `recentf-dialog-goto-first' with
the argument 'link, and the link widgets defined in
`recentf-open-files-item' do set the `:help-echo' property, so the
messages are shown (now only by default).  It seems to me that there is
even less reason to show messages in the *Edit list* buffer than in the
*Open recent*, since enabling a checkbox does not take immediate action
(you have to push the "Ok" button), and the action (removing the checked
files from the recentf list) is clearly described at the top of the
buffer.

> I think the help idea was a fiasco from the start because in
> recentf-open-files it takes hitting the tab key twice to change from one file
> to the next.  Who would do that? 

This is because the *Open recent* buffer uses tree widgets when the
files are grouped (in your case because you customize
`recentf-menu-filter' to 'recentf-arrange-by-mode), as well as link
widgets for the individuals.  I agree that it would be better to only
tab once to move between files (this is in fact the case without
grouping the files); I haven't looked into how feasible that is to
implement, but in any case it's separate from the issue of showing
messages (though the double tabbing means each message is displayed and
logged twice).

>                                   C-n/C-p or arrows are far quicker.  But
> those don't give help. 

That's because tabbing is the standard way to move between widgets: in
wid-edit.el widget-forward is bound to TAB and widget-backward to S-TAB,
(and recentf.el uses these bindings, now via remapping); these commands
invoke `widget-move', which in turn invokes `widget-echo-help', which
shows (or suppresses) a `:help-echo' message.  In contrast, `next-line'
(C-n) and `previous-line' (C-p) know nothing about widgets, so issue no
help messages.

>                         Since the instructional messages at the top of the
> buffer don't mention tab being useful, it's likely that most people never
> realize help exists.  The only artifacts of implementation are what I reported
> as spurious messages in the log.

Since the possibility of showing messages when tabbing is not specific
to recentf but a feature of widgets in general, it seems inappropriate
to mention this feature in the *Open recent* buffer, though it might be
reasonable to mention that you can tab between the files; but it would
better to do that if you only have to tab one instead of twice, so I
think the latter should be implemented first (but I cannot promise to
try and do that any time soon).

Anyway, since this bug report is about showing and suppressing messages
in the *Open recent* buffer, are you satisfied with how that now works
and with my answers to the points you raised above, and if so, do you
agree this bug can now be closed?

Steve Berman