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

Previous Next

Full log

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

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 77718 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, stephen.berman <at> gmx.net
Subject: Re: bug#77718: 31.0.50; completion styles substring and flex are
 broken
Date: Wed, 16 Apr 2025 15:15:44 -0400

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

>>> [ Also, I'm not sure it's worth the trouble anyway: dollars in file names
>>>   are fairly rare, so having to double them in those rare cases where they
>>>   occur is not a big deal.  In any case, it seems orthogonal to the
>>>   problem at hand.  ]
>> That's fair - so you think it might be OK to, basically, not support
>> completion on file names containing substrings like "$HOME"?
>
> Of course we support it, but we require the use of `$$HOME` to state
> clearly which interpretation you want.

Ah, sure.  But my code supports completion on file names containing
"$HOME" without the user of "$$HOME", which seems even nicer.

>> This TAB behavior doesn't help if I manually type $HOME though, right?
>
> Presumably if you type `$HOME` it means you want the value of the HOME
> envvar.  If you want the file named `$HOME` you need to type `$$HOME`.
>
> When the typing is done by the completion code, it's up to the
> completion code to apply that same rule.

Sure, that's fair.  Though, a user might not know that they can type
$$HOME to get the file named '$HOME'; it's not that obvious.  It seems
like it would be nice to automatically DTRT, where possible, without
requiring them to know that.

>> So here's one idea: Since this only works if I tab-complete, that means
>> it only works for files which actually exist.  So, instead, I could have
>> read-file-name check if the file (e.g. "~/tmp/foo$HOME.txt") exists
>> before expanding environment variables; if the file exists, don't expand
>> environment variables.  This avoids the need to duplicate $s.
>
> But then we'd need to add some way for the user to say "I really want
> this $HOME to be expanded even though there is also a file by that funny
> name".

True.  Although, this situation seems likely to be quite rare.  Perhaps
we could support it by adding some new command
minibuffer-substitute-in-file-name or something, which explicitly
expands environment variables found in the current minibuffer.

Then read-file-name does the right thing automatically in every case
except this one, without the user needing to insert $$; and in this
case, the user can just use minibuffer-substitute-in-file-name
explicitly.

Previous Next

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