Subject: Re: bug#77718: 31.0.50; completion styles substring and flex are broken

From: Stefan Monnier <[email-masked]>
Date: Wed, 16 Apr 2025 16:00:09 -0400

I suggest we focus on the immediate completion issue.
If you want to refine the treatment of $$, let's do that in a separate
bug report.

        Stefan

Spencer Baugh [2025-04-16 15:15:44] wrote:

> Stefan Monnier <[email-masked]> 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.