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

From: Stephen Berman <[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:

>> From: Stephen Berman <[email-masked]>
>> Cc: [email-masked],  [email-masked]
>> Date: Sat, 21 Jun 2025 18:40:21 +0200
>> 
>> On Sat, 21 Jun 2025 12:22:07 +0300 Eli Zaretskii <[email-masked]> wrote:
[...] 
>> > I don't use recentf, so I have hard time understanding what this is
>> > about.  What are those messages which you are talking about, and why
>> > and under what circumstances would users want to suppress them?
>> 
>> The messages are mostly of the form "Open <file name>" (if the files
>> listed in the *Open Recent* buffer are displayed as a tree structure,
>> there are also the messages "Collapse node" and "Expand node").  These
>> messages inform the user what action clicking (or typing RET) on an
>> entry in the list executes (the entries are all widgets: the file names
>> are links, and with a tree structure, there are also
>> expandable/collapsible nodes that contain file names as leaves).  Since
>> the meaning of the message is pretty obvious, and a message appears
>> (with a different file name) each time the user tabs between entries in
>> the list, it seems reasonable that many users would prefer not to see
>> the messages in the echo area (and also have them in *Messages*).
>> 
>> Indeed, since the messages are also displayed in tooltips, it might have
>> been preferable if displaying them in the echo area and in *Messages*
>> had been suppressed by default.  However, the messages are shown on
>> invoking `widget-move' and the ability to suppress them by passing an
>> optional argument to that function was added in commit fd86149b1a05 many
>> years after recentf.el first appeared in Emacs.  That is why I proposed
>> making suppressing the messages configurable, defaulting to showing the
>> messages, since that's the way it's always been in recentf.el.
>> 
>> The patch does unconditionally suppress the message in one case: on
>> invoking `recentf-open-files', which was what prompted the OP to file
>> the bug report.  This command automatically and noninteractively moves
>> point to the first file entry in the *Open Recent* buffer using
>> `widget-move', which displays the message.  And it is displayed even if
>> the buffer is not visible (e.g., if `recentf-open-files' is invoked
>> noninteractively from another function that then changes the current
>> buffer), so in this case showing the message is clearly inappropriate.
>> However, if `recentf-open-files' is invoked interactively, so *Open
>> Recent* is the current buffer, then I suppose showing the message
>> initially makes as much sense as showing it on tabbing.  If so, I could
>> adjust the patch accordingly.
>> 
>> On the other hand, given the small information value of the messages,
>> breaking the existing behavior by defaulting to suppressing the
>> messages, or, even more radically, by unconditionally suppressing the
>> messages, does not seem too unreasonable, especially since they can
>> still be viewed in tooltips.  What do you think?
>
> 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.

> Are there any other questionable aspects?

Since the patch involves passing the optional suppression argument to
`widget-forward' and `widget-backward', I did briefly consider the
possibility of making the suppression mechanism in wid-edit.el more
flexible, which I expect would then have required fewer changes to
recentf.el; but that is a more invasive job, so I think it's safest to
just make the recentf.el changes for now, and if such changes are made
later in wid-edit.el, the recentf.el changes can then be adjusted
accordingly.

Steve Berman