GNU bug report logs - #77718
31.0.50; completion styles substring and flex are broken

Previous Next

Package: emacs;

Reported by: Stephen Berman <stephen.berman <at> gmx.net>

Date: Thu, 10 Apr 2025 22:23:02 UTC

Severity: normal

Found in version 31.0.50

Done: Stefan Monnier <monnier <at> iro.umontreal.ca>

Full log


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

From: Ship Mints <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Spencer Baugh <sbaugh <at> janestreet.com>, stephen.berman <at> gmx.net,
 monnier <at> iro.umontreal.ca, 77718 <at> debbugs.gnu.org
Subject: Re: bug#77718: 31.0.50;
 completion styles substring and flex are broken
Date: Tue, 15 Apr 2025 07:16:58 -0400
[Message part 1 (text/plain, inline)]
On Tue, Apr 15, 2025 at 2:26 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Spencer Baugh <sbaugh <at> janestreet.com>
> > Cc: 77718 <at> debbugs.gnu.org,  Eli Zaretskii <eliz <at> gnu.org>,  Stephen
> Berman
> >   <stephen.berman <at> gmx.net>
> > Date: Mon, 14 Apr 2025 16:30:09 -0400
> >
> > +     (;; Ensure we discard text before // by always using sifn in that
> case.
> > +      (unless (string-search "//" orig)
> > +        (complete-with-action action table orig pred)))
>
> AFAIU, this ignores the case of UNC file names, which begin with "//",
> and other complications with file names on Windows.  Emacs on Windows
> reacts differently to "//" than it does on Posix systems, and it does
> so for very good reasons.
>
> Please don't break file-name completion on Windows.  It took us many
> iterations to get it right, and the result is fragile.  Be sure to
> test each change on Windows as well before installing.
>
> For the same reasons, please test thoroughly with remote file names of
> different formats.
>
> Given the fragility of this, I'd tend to suggest to define a new style
> with these changes, and leave alone the existing styles, even if you
> consider them "broken".
>

The POSIX standard allows "pathnames" that start with "//" and Emacs, for
sure, should respect file names that begin with //.

"A pathname that begins with two successive slashes may be interpreted in
an implementation-defined manner, although more than two leading slashes
shall be treated as a single slash."

"A pathname may optionally contain one or more trailing slashes."

"Multiple successive slashes are considered to be the same as one slash."

For mailing list posterity:

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_271:~:text=in%20Filename.-,3.273,-Path%20Prefix
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_271:~:text=in%20their%20execution.-,3.40,-Basename
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#:~:text=If%20a%20pathname%20begins%20with%20two%20successive%20%3Cslash%3E%20characters%2C%20the%20first%20component%20following%20the%20leading%20%3Cslash%3E%20characters%20may%20be%20interpreted%20in%20an%20implementation%2Ddefined%20manner%2C%20although%20more%20than%20two%20leading%20%3Cslash%3E%20characters%20shall%20be%20treated%20as%20a%20single%20%3Cslash%3E%20character.
https://pubs.opengroup.org/onlinepubs/007904875/basedefs/xbd_chap03.html#tag_03_266:~:text=A%20pathname%20may%20optionally%20contain%20one%20or%20more%20trailing%20slashes.%20Multiple%20successive%20slashes%20are%20considered%20to%20be%20the%20same%20as%20one%20slash.

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

This bug report was last modified today.

Previous Next


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