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

[Stefan Monnier]

Daniel Mendler [2021-05-06 13:07:40] wrote:
> On 5/6/21 12:01 PM, Lars Ingebrigtsen wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> IOW I consider the existence of `vertico--tidy-shadowed-file` as a bug
>>> in itself ;-)
>> Skimming this thread, I'm not sure whether there's anything to be done
>> in Emacs here?

There is, but it's not a simple "bug fix".  What I meant above is that the
existence of `vertico--tidy-shadowed-file` reflects a shortcoming of the
completion API, which does not offer any way for the completion-table to
explain this kind of "shadowing", so the UI is stuck using ad-hoc tricks
by trying to detect use of some specific completion tables (e.g. by
testing `minibuffer-completing-file-name`) and then using
"inside-knowledge" of the semantics behind it.

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

> @Stefan The existence of this function is a bug for people who want to
> keep their shadowed paths. This is a matter of preference. For me
> shadowed paths are a cheap means of changing the directory during
> completion and I usually don't want to go back to the old path in the
> process. Icomplete has the same function, but guarded behind a
> customization option. Why do you prefer to keep the shadowed paths?

I don't.  I think it makes a lot of sense as a UI feature.

To do it right, we'd need completion tables to provide some kind of
"tidy up" or "simplify" or "canonicalize" method, I think.


        Stefan