GNU bug report logs -
#47678
27.1; `completion-boundaries` assertion failure for file
Previous Next
Full log
View this message in rfc822 format
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
This bug report was last modified 4 years and 8 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.