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

[Daniel Mendler]

On 5/9/21 1:41 AM, Stefan Monnier wrote:
> Not only the way it's done is inevitably "hackish", but it's also very
> hard to make it correct.  E.g. the shadowing is not a property of
> file names but of `substitute-in-file-name`, so `file-name-shadow-mode`
> and `vertico--tidy-shadowed-file` can misfire if you're reading a file
> name which will not be passed to `substitute-in-file-name`.
> ...
> To do it right, we'd need completion tables to provide some kind of
> "tidy up" or "simplify" or "canonicalize" method, I think.

Thank you for the clarification. I agree. A while ago when fiddling with
file based commands I had wondered why completing-read or the UI can
even return shadowed paths leading to complications down the road. A
canonicalize method would be a good way to achieve this generically. Are
there more examples where one would want to do such a canonicalization?

In the case of file name canonicalization, one has to consider - the
file name is allowed to contain environment variables. This is a feature
which I would like to retain at the UI level. It would be good if the
returned string is canonicalized, but I do not want to dynamically
expand the environment variable while the user enters input. In
contrast, with shadowed paths I am perfectly fine if the UI removes that
shadowed path automatically, like Icomplete and Vertico do it.

What do you mean by "providing a method"? Add a method to the completion
table function itself or to add a completion metadata
`canonicalize-function`? Modifying the completion table specification
itself is more problematic since it is not extensible in its current form.

Daniel