GNU bug report logs - #77678
31.0.50; Infloop in multi-isearch-read-files

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 77678 in the body.
You can then email your comments to 77678 AT debbugs.gnu.org in the normal way.

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

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; Infloop in multi-isearch-read-files
Date: Wed, 09 Apr 2025 13:03:00 +0200

Hello,

depending on the user's settings and environment it is possible that
`multi-isearch-read-files' never terminates because the `string-equal'
test used to compare file names compares expanded and not expanded
names.  This test succeeding is required for the loop to stop.

We should use a more sensible method similar to other places we recently
changed.

Michael.


In GNU Emacs 31.0.50 (build 66, x86_64-pc-linux-gnu, cairo version
 1.16.0) of 2025-04-09 built on drachen
Repository revision: 8ec63b7b102290377a9958be7a5d7996069dd5ff
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101007
System Description: Debian GNU/Linux 12 (bookworm)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 77678 <at> debbugs.gnu.org
Subject: Re: bug#77678: 31.0.50; Infloop in multi-isearch-read-files
Date: Wed, 09 Apr 2025 16:02:01 +0300

> Date: Wed, 09 Apr 2025 13:03:00 +0200
> From:  Michael Heerdegen via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> depending on the user's settings and environment it is possible that
> `multi-isearch-read-files' never terminates because the `string-equal'
> test used to compare file names compares expanded and not expanded
> names.  This test succeeding is required for the loop to stop.
> 
> We should use a more sensible method similar to other places we recently
> changed.

What method did you have in mind?

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77678 <at> debbugs.gnu.org
Subject: Re: bug#77678: 31.0.50; Infloop in multi-isearch-read-files
Date: Wed, 09 Apr 2025 15:13:20 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> What method did you have in mind?

`expand-file-name' both arguments?  I dunno whether this suffices when
Tramp comes into play, though.


Michael.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 77678 <at> debbugs.gnu.org
Subject: Re: bug#77678: 31.0.50; Infloop in multi-isearch-read-files
Date: Wed, 09 Apr 2025 18:36:07 +0300

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: 77678 <at> debbugs.gnu.org
> Date: Wed, 09 Apr 2025 15:13:20 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > What method did you have in mind?
> 
> `expand-file-name' both arguments?  I dunno whether this suffices when
> Tramp comes into play, though.

expand-file-name is a good starting point, yes.  If that's not enough,
then comparing the results with file-equal-p should do.  (If even that
doesn't work in all cases, there's probably more here than meets the
eye.)

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 77678 <at> debbugs.gnu.org
Subject: Re: bug#77678: 31.0.50; Infloop in multi-isearch-read-files
Date: Wed, 09 Apr 2025 18:42:38 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

Hi,

>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > What method did you have in mind?
>>
>> `expand-file-name' both arguments?  I dunno whether this suffices when
>> Tramp comes into play, though.
>
> expand-file-name is a good starting point, yes.  If that's not enough,
> then comparing the results with file-equal-p should do.  (If even that
> doesn't work in all cases, there's probably more here than meets the
> eye.)

file-equal-p uses file-truename which should be OK. Also from the Tramp POV.

Best regards, Michael.

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 77678 <at> debbugs.gnu.org
Subject: Re: bug#77678: 31.0.50; Infloop in multi-isearch-read-files
Date: Wed, 09 Apr 2025 19:49:29 +0300

>> > What method did you have in mind?
>> 
>> `expand-file-name' both arguments?  I dunno whether this suffices when
>> Tramp comes into play, though.
>
> expand-file-name is a good starting point, yes.  If that's not enough,
> then comparing the results with file-equal-p should do.  (If even that
> doesn't work in all cases, there's probably more here than meets the
> eye.)

What does 'read-file-name' return after immediate RET?  From the docstring:

  Read a file name, prompting with PROMPT and completing in directory DIR.
  Retrun the file name as a string.
  The return value is not expanded---you must call expand-file-name
  yourself.

BTW, there is a typo: "Retrun" (not checked if it exists in emacs-30).

Does this return value logic work with all completion frameworks?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: michael_heerdegen <at> web.de, 77678 <at> debbugs.gnu.org
Subject: Re: bug#77678: 31.0.50; Infloop in multi-isearch-read-files
Date: Thu, 10 Apr 2025 09:39:20 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: Michael Heerdegen <michael_heerdegen <at> web.de>,  77678 <at> debbugs.gnu.org
> Date: Wed, 09 Apr 2025 19:49:29 +0300
> 
> What does 'read-file-name' return after immediate RET?  From the docstring:
> 
>   Read a file name, prompting with PROMPT and completing in directory DIR.
>   Retrun the file name as a string.
>   The return value is not expanded---you must call expand-file-name
>   yourself.

Isn't the answer to your question supplied by the paragraph of the doc
string below?  If not, why not?

  DEFAULT-FILENAME specifies the default file name to return if the
  user exits the minibuffer with the same non-empty string inserted
  by this function.  If DEFAULT-FILENAME is a string, that serves
  as the default.  If DEFAULT-FILENAME is a list of strings, the
  first string is the default.  If DEFAULT-FILENAME is omitted or
  nil, then if INITIAL is non-nil, the default is DIR combined with
  INITIAL; otherwise, if the current buffer is visiting a file,
  that file serves as the default; otherwise, the default is simply
  the string inserted into the minibuffer.

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

From: Juri Linkov <juri <at> linkov.net>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, Eli Zaretskii <eliz <at> gnu.org>,
 77678 <at> debbugs.gnu.org
Subject: Re: bug#77678: 31.0.50; Infloop in multi-isearch-read-files
Date: Tue, 29 Apr 2025 20:14:20 +0300

close 77678 31.0.50
thanks

>>> > What method did you have in mind?
>>>
>>> `expand-file-name' both arguments?  I dunno whether this suffices when
>>> Tramp comes into play, though.
>>
>> expand-file-name is a good starting point, yes.  If that's not enough,
>> then comparing the results with file-equal-p should do.  (If even that
>> doesn't work in all cases, there's probably more here than meets the
>> eye.)
>
> file-equal-p uses file-truename which should be OK. Also from the Tramp POV.

So now replaced 'string-equal' with 'file-equal-p'.

Previous Next

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