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

Previous Next

Full log

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

From: Rick Bielawski <rbielaws <at> gmail.com>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 78666 <at> debbugs.gnu.org
Subject: Re: bug#78666: 31.0.50; recentf-open-files reports opening the last
 file accessed
Date: Tue, 1 Jul 2025 10:08:28 -0500

[Message part 1 (text/plain, inline)]

Absolutely

On Mon, Jun 30, 2025, 4:28 AM Stephen Berman <stephen.berman <at> gmx.net> wrote:

> On Sat, 28 Jun 2025 20:02:50 -0500 Rick <rbielaws <at> gmail.com> wrote:
>
> > 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.
>
> I appreciate your effort.
>
> > To your immediate question.  Yes, suppression appears to work
> completely.
> > Thank you.
>
> Thanks for confirming.
>
> > 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).
>
> There is a crucial difference between invoking `recentf-open-files' via
> a key sequence or a menu and invoking it by setting the value of
> `initial-buffer-choice' to `recentf-open-files': the former are in
> effect the same as doing `M-x recentf-open-files', i.e., interactively
> invoking the function, while the latter invokes the function
> noninteractively (it's called from a Lisp program - your init file).  As
> you pointed out at or near the beginning of this bug thread, and I
> agree, showing the help messages is reasonable (as an option) only when
> the the *Open recent* buffer is the current buffer, which is the case
> when `recentf-open-files' is invoked interactively, but may not be the
> case when it's invoked from Lisp.  Admittedly, calling it via
> `initial-buffer-choice' could be seen as effectively equivalent to
> calling it interactively, but accounting for that case would make the
> code a bit more complicated, and since I haven't seen any other bug
> reports involving this use case besides yours, and you don't want the
> messages, I chose to keep the code simpler.
>
> >                                                                  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."
>
> Setting `message-log-max' to nil prevents messages from being added to
> the *Messages* buffer, and setting `inhibit-message' to non-nil prevents
> displaying messages in the echo area but they are still added to
> *Messages*.  But neither of those seems reasonable to me for the recentf
> help messages; and the option to turn them off entirely (both in the
> echo area and in *Messages*) now exists thanks to your bug report.
>
> > 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 guess you mean `recentf-edit-list', which does call
> `recentf-dialog-goto-first', crucially with the argument 'checkbox, and
> the checkbox widgets that `recentf-edit-list' also defines do not set
> the `:help-echo' property: that's why no messages are displayed.  In
> contrast, `recentf-open-files' calls `recentf-dialog-goto-first' with
> the argument 'link, and the link widgets defined in
> `recentf-open-files-item' do set the `:help-echo' property, so the
> messages are shown (now only by default).  It seems to me that there is
> even less reason to show messages in the *Edit list* buffer than in the
> *Open recent*, since enabling a checkbox does not take immediate action
> (you have to push the "Ok" button), and the action (removing the checked
> files from the recentf list) is clearly described at the top of the
> buffer.
>
> > 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?
>
> This is because the *Open recent* buffer uses tree widgets when the
> files are grouped (in your case because you customize
> `recentf-menu-filter' to 'recentf-arrange-by-mode), as well as link
> widgets for the individuals.  I agree that it would be better to only
> tab once to move between files (this is in fact the case without
> grouping the files); I haven't looked into how feasible that is to
> implement, but in any case it's separate from the issue of showing
> messages (though the double tabbing means each message is displayed and
> logged twice).
>
> >                                   C-n/C-p or arrows are far quicker.  But
> > those don't give help.
>
> That's because tabbing is the standard way to move between widgets: in
> wid-edit.el widget-forward is bound to TAB and widget-backward to S-TAB,
> (and recentf.el uses these bindings, now via remapping); these commands
> invoke `widget-move', which in turn invokes `widget-echo-help', which
> shows (or suppresses) a `:help-echo' message.  In contrast, `next-line'
> (C-n) and `previous-line' (C-p) know nothing about widgets, so issue no
> help messages.
>
> >                         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.
>
> Since the possibility of showing messages when tabbing is not specific
> to recentf but a feature of widgets in general, it seems inappropriate
> to mention this feature in the *Open recent* buffer, though it might be
> reasonable to mention that you can tab between the files; but it would
> better to do that if you only have to tab one instead of twice, so I
> think the latter should be implemented first (but I cannot promise to
> try and do that any time soon).
>
> Anyway, since this bug report is about showing and suppressing messages
> in the *Open recent* buffer, are you satisfied with how that now works
> and with my answers to the points you raised above, and if so, do you
> agree this bug can now be closed?
>
> Steve Berman
>

[Message part 2 (text/html, inline)]

Previous Next

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