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

Previous Next

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