GNU bug report logs - #78666
31.0.50; recentf-open-files reports opening the last file accessed

Previous Next

Full log

Message #38 received at 78666 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: rbielaws <at> gmail.com, 78666 <at> debbugs.gnu.org
Subject: Re: bug#78666: 31.0.50; recentf-open-files reports opening the last
 file accessed
Date: Sun, 22 Jun 2025 17:32:54 +0300

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

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

Right.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.