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.

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

Previous Next

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