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

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Thank you for looking into this. I hope this will not lead to further
> problems, it is mostly an edge case when moving around the cursor and the
> path at that point is not really valid? What kind of issues could happen?
> I can always enter some invalid/shadowed path ///, /~~~/, ~/~/~, which do
> not make problems (at least with this patch).

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).

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.


        Stefan