bug#47678: 27.1; `completion-boundaries` assertion failure for file

[Daniel Mendler]

On 4/13/21 2:46 PM, Stefan Monnier wrote:
> The problem has to do with quoting/unquoting: in `C-x C-f` we do not
> quite enter "raw file name" because the name typed by the user is passed
> through `substitute-in-file-name` which expands envvar references (and
> de-doubles dollars for those files whose name looks like an envvar
> reference) and does some truncation (like foo//bar => /bar).

I am aware of that feature and use it but for now I avoided looking into 
how this is exactly implemented :)

> So the `completion-file-name-table` (which completes raw file names) is
> wrapped via `completion-table-with-quoting` and this function has to be
> able to relate the unquoted text back to the quoted text, for example in
> order to convert the boundaries returned by `completion-file-name-table`
> (on the unquoted file name) into the corresponding boundaries that apply
> to the quoted file name.
>
> This is in general somewhere between hard and impossible.  So if/when we
> get those boundaries wrong (for example) it may lead to misbehavior down
> the line.
> I'd rather not try and guess what those might be.
> I'm just hoping that they're minor enough and rare enough.

Thank you for the detailed explanation.

Ok, but in the case where this issue occurs we already have a somehow 
broken path, especially when moving with the point over the shadowed 
parts. So as a user I would not be worried to much if this does not work.

I hope most assumptions down the line are checked by conditions. However 
given that in this particular case we already have an error we could 
only get more errors at worst down the line?

(Btw, in Vertico I throw out the shadowed paths as soon as I get the 
opportunity (vertico--tidy-shadowed-file) in the same way as Icomplete 
does it if enabled.)

Daniel