embark
embark copied to clipboard
oantolin
embark-target-completion-at-point does not compute full candidate
It seems the function does not calculate the full candidate based on the completion boundaries. Instead there is some special trickery for files. Is this right or did I misunderstand something? Is this intentional such that it also works if the minibuffer is dead? Only with a live minibuffer we can obtain the base string.
That is correct. It's an approximation to the full candidate that often works: usually the candidate is the full candidate, but for files the full candidate is a full path, so we try to store the appropriate default-directory in the the completions buffer (there is a function added to completion-setup-hook that stores embark's best guess at the appropriate default-directory) and use it to produce full paths.
And yes, storing the default-directory does keep the actions working after you've closed the minibuffer.
It would probably be better to store the prefix and suffix need to make the full candidate (and still store a duplicate of the prefix as the default-directory for the file case, since most file actions need the default-directory set).
Yes, storing the prefix/suffix would be good to generalize this to arbitrary completion tables using completion-boundaries. Are there any?
I can't remember many off the top of my head. The file table uses boundaries in two ways: for path components, and for embedded environment variables. I think maybe completing-read-multiple cooks up a completion table that uses boundaries to complete each portion between crm-separators.
The file table points out that maybe you don't really want the suffix. I'm not sure. If you are completing /some/|/path with | representing point, the candidates nice and fun stand for the full paths /some/nice/path and /some/fun/path respectively. If you close the minibuffer and some time later see the nice and fun candidates you'd expect them to be relative to some directory (/some in this case), even if you've forgotten which directory (you could check default-directory) but maybe you've completely forgotten they also had a suffix (/path).
I don't know. Probably the whole scenario of storing a completions buffer long past the closing of its minibuffer is fantasy anyway.
I don't know. Probably the whole scenario of storing a completions buffer long past the closing of its minibuffer is fantasy anyway.
Right, crm is an obvious example. Should have thought of that. But there are not many other tables I think.
The file table points out that maybe you don't really want the suffix...
Regarding the suffix see also https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48356.
I don't know. Probably the whole scenario of storing a completions buffer long past the closing of its minibuffer is fantasy anyway.
Maybe you are right about the completions buffer. But having an Embark Collect buffer after closing the minibuffer it is a very important feature to me. I use this all the time :)