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
Message #35 received at 78666 <at> debbugs.gnu.org (full text, mbox):
On Sat, 21 Jun 2025 22:02:03 +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: Sat, 21 Jun 2025 18:40:21 +0200
>>
>> On Sat, 21 Jun 2025 12:22:07 +0300 Eli Zaretskii <eliz <at> gnu.org> 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
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.