Subject: bug#78666: 31.0.50; recentf-open-files reports opening the last file accessed

From: Rick <[email-masked]>
Date: Sat, 28 Jun 2025 20:02:50 -0500

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.

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

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).  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."

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 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?  C-n/C-p or arrows are far 
quicker.  But those don't give help.  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.

On 25-Jun-23 05:05, Stephen Berman wrote:
> On Sun, 22 Jun 2025 17:32:54 +0300 Eli Zaretskii <[email-masked]> wrote:
>
>>> From: Stephen Berman <[email-masked]>
>>> Cc: [email-masked],  [email-masked]
>>> Date: Sun, 22 Jun 2025 15:27:59 +0200
>>>
>>> On Sat, 21 Jun 2025 22:02:03 +0300 Eli Zaretskii <[email-masked]> wrote:
>>>
>>>> So, given that this is a recentf-specific issue, what kind of feedback
>>>> did you expect from me, now that you know I don't use this feature?
>>>> It sounds like you have already everything figured out.  What are the
>>>> aspects about which you are in doubt?  If that is whether to suppress
>>>> these messages unconditionally, then I don't think that would be TRT:
>>>> these messages are shown for many years, and we didn't have any
>>>> complaints about them till now, AFAIU.  So having this as an opt-in
>>>> behavior sounds correct to me.
>>> Thanks, that's the feedback I was hoping for.  I was uncertain whether
>>> this minor issue justified the extent of the changes and adding a user
>>> option, not least because I've gotten unexpected resistance to adding a
>>> user option in the ongoing bug#77718 thread.  So, I'll push an updated
>>> version of the patch to master, which adds a NEWS entry and by default
>>> keeps the initial message only when `recentf-open-files' is invoked
>>> interactively, since I think that's more consistent behavior if the
>>> option to suppress the messages is not enabled.
>> Thanks.
> Now pushed to master as commit 2b34f38b383.  On retesting before
> committing, I found that I had missed the command
> 'recentf-open-more-files', which should also display a message by
> default, so I added that to 'recentf-dialog-goto-first'.
>
> I would appreciate it if Rick (the OP) would confirm that, when
> 'recentf-suppress-open-file-help' is set to non-nil, no messages
> are shown when interactively opening a recentf open file dialog or when
> tabbing between items in the open file buffer.  Also, in the use case
> mentioned where 'initial-buffer-choice' is set to 'recentf-open-files,
> starting Emacs should not show an open file message even when the
> suppress option is nil.  If these expectations are satisfied, the bug
> can be closed.
>
> Steve Berman