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

Previous Next

To reply to this bug, email your comments to 78666 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

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

From: Rick <rbielaws <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; recentf-open-files reports opening the last file accessed
Date: Sun, 1 Jun 2025 18:34:45 -0500

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

--text follows this line--
You can recreate most of the problem starting with -Q however you must
have a previously populated recentf file before starting.

M-x recentf-mode
M-x recentf-open-files

Now switch to the *Messagers* buffer and notice something similar to:

    Loading /home/rick/.emacs.d/recentf...done     Cleaning up the 
recentf list...done (0 removed)     Mark set     Open 
/snap/emacs/2827/usr/share/emacs/31.0.50/lisp/files.el.gz

Observe that it claims to have opened the most recent item on recentf-list,
as loaded from the pre-populated recentf file.  In my case .../files.el.gz.

There doesn't seem to be a buffer actually associated with the file but
it's unclear whether it was subsequently closed or a spurious message.

Personally, because my .emacs contains the following and I run in server
mode I get additional messages that may be helpful.

|... '(recentf-auto-cleanup 'never) '(recentf-max-menu-items 40) 
'(recentf-max-saved-items 200) '(recentf-menu-filter 
'recentf-arrange-by-mode) '(recentf-menu-open-all-flag t) '(recentf-mode 
t) '(recentf-show-file-shortcuts-flag nil) |
...

|(setq initial-buffer-choice 'recentf-open-files)|

With the above (some of which could be irrelevant but I didn't narrow down)
I get the following.  Notice that it reports opening the file 3 times.  
It also
contains "Collapse node" messages which I see no reference to in either
recentf.el or wid-edit.el (its only dependency?).  So I can't tell what 
is emitting
them but it's clearly related and may tell you more than it does me:-)

|Starting Emacs daemon. Collapse node Open 
~/snap/emacs/site-lisp/anchored-transpose.el Collapse node Open 
~/snap/emacs/site-lisp/anchored-transpose.el [2 times] When done with 
this frame, type C-x 5 0 Mark set Collapse node|

I tried (debug-on-entry recentf-open-files) and the messages get
created if I simply type 'c' at the debug prompt.  But when I try
stepping thru the code I get to the end and I'm presented with a
proper menu buffer without ever encountering any code that might
have emitted the messages - AND the messages DO NOT appear.

This left me out of my depth.  Otherwise I'd have tried to debug and
at least report which functions were involved if not a solution proposal.


In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.41, cairo version 1.18.0) of 2025-05-25 built on lcy02-amd64-118
Repository revision: 10e023c15c03ca32d3c9b1ad54111ef4ede6de73
Repository branch: master
System Description: Ubuntu 24.04.2 LTS

Configured using:
 'configure --prefix=/snap/emacs/current/usr --with-x-toolkit=gtk3
 --without-xaw3d --with-modules --with-cairo
 --with-native-compilation=aot --with-pgtk --with-xinput2
 --with-tree-sitter 'CFLAGS=-isystem
 /build/emacs/parts/emacs/install/usr/include -isystem
 /build/emacs/parts/emacs/install/usr/include/x86_64-linux-gnu -isystem
 /build/emacs/stage/usr/include -O2' 'CPPFLAGS=-isystem
 /build/emacs/parts/emacs/install/usr/include -isystem
 /build/emacs/parts/emacs/install/usr/include/x86_64-linux-gnu -isystem
 /build/emacs/stage/usr/include'
 'LDFLAGS=-L/build/emacs/parts/emacs/install/lib
 -L/build/emacs/parts/emacs/install/usr/lib
 -L/build/emacs/parts/emacs/install/lib/x86_64-linux-gnu
 -L/build/emacs/parts/emacs/install/usr/lib/x86_64-linux-gnu
 -L/build/emacs/stage/usr/lib''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY
INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Messages

Minor modes in effect:
  recentf-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug lisp-mnt message mailcap yank-media puny
dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config gnus-util mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils cus-start cus-load recentf
tree-widget wid-edit time-date compile text-property-search comint
subr-x ansi-osc ansi-color ring comp-run bytecomp byte-compile
comp-common rx warnings icons cl-loaddefs cl-lib rmc iso-transl tooltip
cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/pgtk-win pgtk-win term/common-win touch-screen
pgtk-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list
replace newcomment text-mode lisp-mode prog-mode register page tab-bar
menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse
jit-lock font-lock syntax font-core term/tty-colors frame minibuffer
nadvice seq simple cl-generic indonesian philippine cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop
case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify dynamic-setting system-font-setting
font-render-setting cairo gtk pgtk lcms2 multi-tty move-toolbar
make-network-process tty-child-frames native-compile emacs)

Memory information:
((conses 16 88314 19791) (symbols 48 8421 0) (strings 32 20906 1600)
 (string-bytes 1 716862) (vectors 16 12038)
 (vector-slots 8 163474 8069) (floats 8 27 2) (intervals 56 460 0)
 (buffers 1064 12))

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

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

From: Rick <rbielaws <at> gmail.com>
To: 78666 <at> debbugs.gnu.org
Subject: Re: 31.0.50; recentf-open-files reports opening the last file accessed
Date: Tue, 3 Jun 2025 16:53:51 -0500

With some help from @NickD in this thread
https://emacs.stackexchange.com/questions/84614

I've isolated the messages source to this function:

(defun recentf-dialog-goto-first (widget-type)
  "Move the cursor to the first WIDGET-TYPE in current dialog.
Go to the beginning of buffer if not found."
  (goto-char (point-min))
  (condition-case nil
      (let (done)
        (widget-move 1)
        (while (not done)
          (if (eq widget-type (widget-type (widget-at (point))))
              (setq done t)
            (widget-move 1))))
    (error
     (goto-char (point-min)))))

Perhaps the real problem is in widget-move and the
messages should not even be generated.  But that isn't
something I have a way to tell.  What I CAN tell is that
given they seem to  serve no purpose beyond creating
confusion I see they can easily be eliminated using
widget-move's optional suppress-echo parameter.

Specifically, change

 (widget-move 1)

 to

 (widget-move 1 t)

in BOTH invocations within the above function.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Rick <rbielaws <at> gmail.com>
Cc: 78666 <at> debbugs.gnu.org
Subject: Re: bug#78666: 31.0.50; recentf-open-files reports opening the last
 file accessed
Date: Wed, 04 Jun 2025 00:51:35 +0200

On Sun, 1 Jun 2025 18:34:45 -0500 Rick <rbielaws <at> gmail.com> wrote:

> --text follows this line--
> You can recreate most of the problem starting with -Q however you must
> have a previously populated recentf file before starting.
>
> M-x recentf-mode
> M-x recentf-open-files
>
> Now switch to the *Messagers* buffer and notice something similar to:
>
>     Loading /home/rick/.emacs.d/recentf...done     Cleaning up the recentf
> list...done (0 removed)     Mark set     Open
> /snap/emacs/2827/usr/share/emacs/31.0.50/lisp/files.el.gz
>
> Observe that it claims to have opened the most recent item on recentf-list,
> as loaded from the pre-populated recentf file.  In my case .../files.el.gz.
>
> There doesn't seem to be a buffer actually associated with the file but
> it's unclear whether it was subsequently closed or a spurious message.

I think you misunderstood those messages: each one is help text to
inform you that by checking the box of that item you will open the file
(in GUI Emacs you can see the same text in a tooltip if you move the
mouse pointer over the item).  So they are not informing you that the
file has been opened.

Steve Berman

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

From: Rick <rbielaws <at> gmail.com>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 78666 <at> debbugs.gnu.org
Subject: Re: bug#78666: 31.0.50; recentf-open-files reports opening the last
 file accessed
Date: Tue, 3 Jun 2025 19:21:19 -0500

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

It seems you are confirming that the messages are in fact spurious
at this point in the execution process because they are generated
prior to the window being presented to the user.   You are
describing messages that are only useful once the user starts
being able to interact with the buffer so other than at this point
they are correct, necessary, appropriate.

Given I'm not mistaken, I'm now much more confident that the
fix I suggested an hour or so ago ago is only pretty close to
the correct way to deal with it.  I will now amend my suggestion
to the following.

Add the optional parameter (accepted by widget-move) to
recentf-dialog-goto-first so that 't' can be passed to widget-move
when recentf-edit-list and recentf-open-files call it.  All other
callers will default to nil and therefore be unaffected.  This should
cleanly remove them exactly and only where they are inappropriate.

(defun recentf-dialog-goto-first (widget-type *_&optional quietly_*)
  "Move the cursor to the first WIDGET-TYPE in current dialog.
Go to the beginning of buffer if not found."
  (goto-char (point-min))
  (condition-case nil
      (let (done)
        (widget-move 1 _*quietly*_)
        (while (not done)
          (if (eq widget-type (widget-type (widget-at (point))))
              (setq done t)
            (widget-move 1 _*quietly*_))))
    (error
     (goto-char (point-min)))))


(defun recentf-open-files (&optional files buffer-name)
...
    (recentf-dialog-goto-first 'link *_t_*)))


(defun recentf-edit-list ()
...
    (recentf-dialog-goto-first 'checkbox *_t_*)))


On 6/3/25 17:51, Stephen Berman wrote:
> On Sun, 1 Jun 2025 18:34:45 -0500 Rick<rbielaws <at> gmail.com> wrote:
>
>> --text follows this line--
>> You can recreate most of the problem starting with -Q however you must
>> have a previously populated recentf file before starting.
>>
>> M-x recentf-mode
>> M-x recentf-open-files
>>
>> Now switch to the *Messagers* buffer and notice something similar to:
>>
>>      Loading /home/rick/.emacs.d/recentf...done     Cleaning up the recentf
>> list...done (0 removed)     Mark set     Open
>> /snap/emacs/2827/usr/share/emacs/31.0.50/lisp/files.el.gz
>>
>> Observe that it claims to have opened the most recent item on recentf-list,
>> as loaded from the pre-populated recentf file.  In my case .../files.el.gz.
>>
>> There doesn't seem to be a buffer actually associated with the file but
>> it's unclear whether it was subsequently closed or a spurious message.
> I think you misunderstood those messages: each one is help text to
> inform you that by checking the box of that item you will open the file
> (in GUI Emacs you can see the same text in a tooltip if you move the
> mouse pointer over the item).  So they are not informing you that the
> file has been opened.
>
> Steve Berman

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

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Rick <rbielaws <at> gmail.com>
Cc: 78666 <at> debbugs.gnu.org
Subject: Re: bug#78666: 31.0.50; recentf-open-files reports opening the last
 file accessed
Date: Wed, 04 Jun 2025 15:37:11 +0200

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

On Tue, 3 Jun 2025 19:21:19 -0500 Rick <rbielaws <at> gmail.com> wrote:

[I moved the quoted message from me up for continuity.]
> On 6/3/25 17:51, Stephen Berman wrote:
>> On Sun, 1 Jun 2025 18:34:45 -0500 Rick<rbielaws <at> gmail.com> wrote:
>>
>>> --text follows this line--
>>> You can recreate most of the problem starting with -Q however you must
>>> have a previously populated recentf file before starting.
>>>
>>> M-x recentf-mode
>>> M-x recentf-open-files
>>>
>>> Now switch to the *Messagers* buffer and notice something similar to:
>>>
>>>      Loading /home/rick/.emacs.d/recentf...done     Cleaning up the recentf
>>> list...done (0 removed)     Mark set     Open
>>> /snap/emacs/2827/usr/share/emacs/31.0.50/lisp/files.el.gz
>>>
>>> Observe that it claims to have opened the most recent item on recentf-list,
>>> as loaded from the pre-populated recentf file.  In my case .../files.el.gz.
>>>
>>> There doesn't seem to be a buffer actually associated with the file but
>>> it's unclear whether it was subsequently closed or a spurious message.
>> I think you misunderstood those messages: each one is help text to
>> inform you that by checking the box of that item you will open the file
>> (in GUI Emacs you can see the same text in a tooltip if you move the
>> mouse pointer over the item).  So they are not informing you that the
>> file has been opened.
>>
>> Steve Berman
>
> It seems you are confirming that the messages are in fact spurious
> at this point in the execution process because they are generated
> prior to the window being presented to the user.   You are
> describing messages that are only useful once the user starts
> being able to interact with the buffer so other than at this point
> they are correct, necessary, appropriate.
>
> Given I'm not mistaken, I'm now much more confident that the
> fix I suggested an hour or so ago ago is only pretty close to
> the correct way to deal with it.  I will now amend my suggestion
> to the following.
>
> Add the optional parameter (accepted by widget-move) to
> recentf-dialog-goto-first so that 't' can be passed to widget-move
> when recentf-edit-list and recentf-open-files call it.  All other
> callers will default to nil and therefore be unaffected.  This should
> cleanly remove them exactly and only where they are inappropriate.
>
> (defun recentf-dialog-goto-first (widget-type *_&optional quietly_*)
>   "Move the cursor to the first WIDGET-TYPE in current dialog.
> Go to the beginning of buffer if not found."
>   (goto-char (point-min))
>   (condition-case nil
>       (let (done)
>         (widget-move 1 _*quietly*_)
>         (while (not done)
>           (if (eq widget-type (widget-type (widget-at (point))))
>               (setq done t)
>             (widget-move 1 _*quietly*_))))
>     (error
>      (goto-char (point-min)))))
>
>
> (defun recentf-open-files (&optional files buffer-name)
> ...
>     (recentf-dialog-goto-first 'link *_t_*)))
>
>
> (defun recentf-edit-list ()
> ...
>     (recentf-dialog-goto-first 'checkbox *_t_*)))

I took a closer look at recentf.el and found that the messages (which
come from the :help-echo property in `recentf-open-files-item') are
displayed only on invoking `recentf-open-files' and on tabbing between
items in the *Open Recent* buffer; invoking `recentf-edit-list' or
tabbing between check boxes in that list does not display such a message
(so my assertion above was wrong in referring to check boxes).  So you
don't need to change `recentf-edit-list'.  (And in fact, it isn't
necessary to change `recentf-open-files' either, see the attached
patch.)

Also, your change only affects displaying the message on creating the
open file dialog; further messages are still displayed when tabbing
between items in that buffer.  In your second post you said you saw
several messages, also repeated ones.  AFAICT all messages but the first
can only result from tabbing between items; if this is not what you see,
please give a precise recipe detailing what you find problematic.

If you do also want to suppress the messages on tabbing between items,
then I think more extensive changes are needed.  For one thing, since
displaying the messages has long been the status quo, suppressing them
should be optional (though I agree with you that displaying the message
on creating the *Open Recent* buffer seems like a bug).  Moreover, since
tabbing invokes the commands `widget-forward' and `widget-backward'
(which in turn invoke `widget-move'), these need to be changed as well.
The attached patch implements these changes.

Steve Berman

[Message part 2 (text/x-patch, attachment)]

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

From: Rick <rbielaws <at> gmail.com>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 78666 <at> debbugs.gnu.org
Subject: Re: bug#78666: 31.0.50; recentf-open-files reports opening the last
 file accessed
Date: Wed, 4 Jun 2025 09:43:46 -0500

> I took a closer look at recentf.el and found that the messages (which
> come from the :help-echo property in `recentf-open-files-item') are
> displayed only on invoking `recentf-open-files' and on tabbing between
> items in the *Open Recent* buffer; invoking `recentf-edit-list' or
> tabbing between check boxes in that list does not display such a message
> (so my assertion above was wrong in referring to check boxes).  So you
> don't need to change `recentf-edit-list'.  (And in fact, it isn't
> necessary to change `recentf-open-files' either, see the attached
> patch.)
>
> Also, your change only affects displaying the message on creating the
> open file dialog; further messages are still displayed when tabbing
> between items in that buffer.  In your second post you said you saw
> several messages, also repeated ones.  AFAICT all messages but the first
> can only result from tabbing between items; if this is not what you see,
> please give a precise recipe detailing what you find problematic.
>
> If you do also want to suppress the messages on tabbing between items,
> then I think more extensive changes are needed.  For one thing, since
> displaying the messages has long been the status quo, suppressing them
> should be optional (though I agree with you that displaying the message
> on creating the *Open Recent* buffer seems like a bug).  Moreover, since
> tabbing invokes the commands `widget-forward' and `widget-backward'
> (which in turn invoke `widget-move'), these need to be changed as well.
> The attached patch implements these changes.
>
> Steve Berman

Nice bonus.  Thanks

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Rick <rbielaws <at> gmail.com>
Cc: 78666 <at> debbugs.gnu.org
Subject: Re: bug#78666: 31.0.50; recentf-open-files reports opening the last
 file accessed
Date: Tue, 17 Jun 2025 09:51:03 +0200

On Wed, 4 Jun 2025 09:43:46 -0500 Rick <rbielaws <at> gmail.com> wrote:

>> I took a closer look at recentf.el and found that the messages (which
>> come from the :help-echo property in `recentf-open-files-item') are
>> displayed only on invoking `recentf-open-files' and on tabbing between
>> items in the *Open Recent* buffer; invoking `recentf-edit-list' or
>> tabbing between check boxes in that list does not display such a message
>> (so my assertion above was wrong in referring to check boxes).  So you
>> don't need to change `recentf-edit-list'.  (And in fact, it isn't
>> necessary to change `recentf-open-files' either, see the attached
>> patch.)
>>
>> Also, your change only affects displaying the message on creating the
>> open file dialog; further messages are still displayed when tabbing
>> between items in that buffer.  In your second post you said you saw
>> several messages, also repeated ones.  AFAICT all messages but the first
>> can only result from tabbing between items; if this is not what you see,
>> please give a precise recipe detailing what you find problematic.
>>
>> If you do also want to suppress the messages on tabbing between items,
>> then I think more extensive changes are needed.  For one thing, since
>> displaying the messages has long been the status quo, suppressing them
>> should be optional (though I agree with you that displaying the message
>> on creating the *Open Recent* buffer seems like a bug).  Moreover, since
>> tabbing invokes the commands `widget-forward' and `widget-backward'
>> (which in turn invoke `widget-move'), these need to be changed as well.
>> The attached patch implements these changes.
>>
>> Steve Berman
>
> Nice bonus.  Thanks

Since my patch goes beyond a minimal fix for the problem reported, I
think it's appropriate that at least one of the Emacs maintainers should
approve it or explain why it should not be installed.  So this is a
request for maintainer feedback.  Thanks.

Steve Berman

Message #26 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: Sat, 21 Jun 2025 12:22:07 +0300

> Cc: 78666 <at> debbugs.gnu.org
> Date: Tue, 17 Jun 2025 09:51:03 +0200
> From:  Stephen Berman via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> On Wed, 4 Jun 2025 09:43:46 -0500 Rick <rbielaws <at> gmail.com> wrote:
> 
> >> I took a closer look at recentf.el and found that the messages (which
> >> come from the :help-echo property in `recentf-open-files-item') are
> >> displayed only on invoking `recentf-open-files' and on tabbing between
> >> items in the *Open Recent* buffer; invoking `recentf-edit-list' or
> >> tabbing between check boxes in that list does not display such a message
> >> (so my assertion above was wrong in referring to check boxes).  So you
> >> don't need to change `recentf-edit-list'.  (And in fact, it isn't
> >> necessary to change `recentf-open-files' either, see the attached
> >> patch.)
> >>
> >> Also, your change only affects displaying the message on creating the
> >> open file dialog; further messages are still displayed when tabbing
> >> between items in that buffer.  In your second post you said you saw
> >> several messages, also repeated ones.  AFAICT all messages but the first
> >> can only result from tabbing between items; if this is not what you see,
> >> please give a precise recipe detailing what you find problematic.
> >>
> >> If you do also want to suppress the messages on tabbing between items,
> >> then I think more extensive changes are needed.  For one thing, since
> >> displaying the messages has long been the status quo, suppressing them
> >> should be optional (though I agree with you that displaying the message
> >> on creating the *Open Recent* buffer seems like a bug).  Moreover, since
> >> tabbing invokes the commands `widget-forward' and `widget-backward'
> >> (which in turn invoke `widget-move'), these need to be changed as well.
> >> The attached patch implements these changes.
> >>
> >> Steve Berman
> >
> > Nice bonus.  Thanks
> 
> Since my patch goes beyond a minimal fix for the problem reported, I
> think it's appropriate that at least one of the Emacs maintainers should
> approve it or explain why it should not be installed.  So this is a
> request for maintainer feedback.  Thanks.

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?

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
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: Sat, 21 Jun 2025 18:40:21 +0200

On Sat, 21 Jun 2025 12:22:07 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> Cc: 78666 <at> debbugs.gnu.org
>> Date: Tue, 17 Jun 2025 09:51:03 +0200
>> From:  Stephen Berman via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> 
>> On Wed, 4 Jun 2025 09:43:46 -0500 Rick <rbielaws <at> gmail.com> wrote:
>> 
>> >> I took a closer look at recentf.el and found that the messages (which
>> >> come from the :help-echo property in `recentf-open-files-item') are
>> >> displayed only on invoking `recentf-open-files' and on tabbing between
>> >> items in the *Open Recent* buffer; invoking `recentf-edit-list' or
>> >> tabbing between check boxes in that list does not display such a message
>> >> (so my assertion above was wrong in referring to check boxes).  So you
>> >> don't need to change `recentf-edit-list'.  (And in fact, it isn't
>> >> necessary to change `recentf-open-files' either, see the attached
>> >> patch.)
>> >>
>> >> Also, your change only affects displaying the message on creating the
>> >> open file dialog; further messages are still displayed when tabbing
>> >> between items in that buffer.  In your second post you said you saw
>> >> several messages, also repeated ones.  AFAICT all messages but the first
>> >> can only result from tabbing between items; if this is not what you see,
>> >> please give a precise recipe detailing what you find problematic.
>> >>
>> >> If you do also want to suppress the messages on tabbing between items,
>> >> then I think more extensive changes are needed.  For one thing, since
>> >> displaying the messages has long been the status quo, suppressing them
>> >> should be optional (though I agree with you that displaying the message
>> >> on creating the *Open Recent* buffer seems like a bug).  Moreover, since
>> >> tabbing invokes the commands `widget-forward' and `widget-backward'
>> >> (which in turn invoke `widget-move'), these need to be changed as well.
>> >> The attached patch implements these changes.
>> >>
>> >> Steve Berman
>> >
>> > Nice bonus.  Thanks
>> 
>> Since my patch goes beyond a minimal fix for the problem reported, I
>> think it's appropriate that at least one of the Emacs maintainers should
>> approve it or explain why it should not be installed.  So this is a
>> request for maintainer feedback.  Thanks.
>
> 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?

Steve Berman

Message #32 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: Sat, 21 Jun 2025 22:02:03 +0300

> 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:
> 
> >> Cc: 78666 <at> debbugs.gnu.org
> >> Date: Tue, 17 Jun 2025 09:51:03 +0200
> >> From:  Stephen Berman via "Bug reports for GNU Emacs,
> >>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> >> 
> >> On Wed, 4 Jun 2025 09:43:46 -0500 Rick <rbielaws <at> gmail.com> wrote:
> >> 
> >> >> I took a closer look at recentf.el and found that the messages (which
> >> >> come from the :help-echo property in `recentf-open-files-item') are
> >> >> displayed only on invoking `recentf-open-files' and on tabbing between
> >> >> items in the *Open Recent* buffer; invoking `recentf-edit-list' or
> >> >> tabbing between check boxes in that list does not display such a message
> >> >> (so my assertion above was wrong in referring to check boxes).  So you
> >> >> don't need to change `recentf-edit-list'.  (And in fact, it isn't
> >> >> necessary to change `recentf-open-files' either, see the attached
> >> >> patch.)
> >> >>
> >> >> Also, your change only affects displaying the message on creating the
> >> >> open file dialog; further messages are still displayed when tabbing
> >> >> between items in that buffer.  In your second post you said you saw
> >> >> several messages, also repeated ones.  AFAICT all messages but the first
> >> >> can only result from tabbing between items; if this is not what you see,
> >> >> please give a precise recipe detailing what you find problematic.
> >> >>
> >> >> If you do also want to suppress the messages on tabbing between items,
> >> >> then I think more extensive changes are needed.  For one thing, since
> >> >> displaying the messages has long been the status quo, suppressing them
> >> >> should be optional (though I agree with you that displaying the message
> >> >> on creating the *Open Recent* buffer seems like a bug).  Moreover, since
> >> >> tabbing invokes the commands `widget-forward' and `widget-backward'
> >> >> (which in turn invoke `widget-move'), these need to be changed as well.
> >> >> The attached patch implements these changes.
> >> >>
> >> >> Steve Berman
> >> >
> >> > Nice bonus.  Thanks
> >> 
> >> Since my patch goes beyond a minimal fix for the problem reported, I
> >> think it's appropriate that at least one of the Emacs maintainers should
> >> approve it or explain why it should not be installed.  So this is a
> >> request for maintainer feedback.  Thanks.
> >
> > 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.

Are there any other questionable aspects?

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
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 15:27:59 +0200

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

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.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
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: Mon, 23 Jun 2025 12:05:54 +0200

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

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

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

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

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Rick <rbielaws <at> gmail.com>
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: Mon, 30 Jun 2025 11:28:48 +0200

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 #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)]

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Rick Bielawski <rbielaws <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 78666-done <at> debbugs.gnu.org
Subject: Re: bug#78666: 31.0.50; recentf-open-files reports opening the last
 file accessed
Date: Tue, 01 Jul 2025 23:07:46 +0200

On Tue, 1 Jul 2025 10:08:28 -0500 Rick Bielawski <rbielaws <at> gmail.com> wrote:

> Absolutely
>
> On Mon, Jun 30, 2025, 4:28 AM Stephen Berman <stephen.berman <at> gmx.net> wrote:
[...]
>> 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?

Ok, thanks and closing.

Steve Berman

Previous Next

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