GNU bug report logs -
#78666
31.0.50; recentf-open-files reports opening the last file accessed
Previous Next
Reported by: Rick <rbielaws <at> gmail.com>
Date: Sun, 1 Jun 2025 23:35:02 UTC
Severity: normal
Found in version 31.0.50
Done: Stephen Berman <stephen.berman <at> gmx.net>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
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 <eliz <at> gnu.org> wrote:
>
>>> From: Stephen Berman <stephen.berman <at> gmx.net>
>>> Cc: rbielaws <at> gmail.com, 78666 <at> debbugs.gnu.org
>>> Date: Sun, 22 Jun 2025 15:27:59 +0200
>>>
>>> On Sat, 21 Jun 2025 22:02:03 +0300 Eli Zaretskii <eliz <at> gnu.org> 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
This bug report was last modified 38 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.