GNU bug report logs -
#61283
29.0.60; pcomplete-completions-at-point loses text properties, breaking pcomplete-from-help annotations
Previous Next
Full log
Message #59 received at 61283 <at> debbugs.gnu.org (full text, mbox):
On 5/17/2023 2:20 PM, Stefan Monnier via Bug reports for GNU Emacs, the
Swiss army knife of text editors wrote:
> I think the crux of the problem is in:
>
> :annotation-function
> (lambda (cand)
> (when (stringp cand)
> (get-text-property 0 'pcomplete-annotation cand)))
> :company-docsig
> (lambda (cand)
> (when (stringp cand)
> (get-text-property 0 'pcomplete-help cand)))
>
> Rather than fetch the info directly from `cand`, we should maybe
> lookup the info from elsewhere (maybe `completions`?).
Yeah, that's what my patch does.
> Then again, I'm not sure how much `cand` can differ from the matching
> entry in `completions`: it's affected by `completion-table-subvert` and
> `completion-table-with-quoting` so in general it can be non-trivial to
> figure out which entry of `completions` corresponds to the `cand` we
> got :-(
Hmm, yeah. That would be pretty tricky to get working 100% reliably.
Like Daniel mentions, I think this doesn't come up (often?) for the
specific case in this bug, but a fully-robust solution would be ideal.
Maybe the 'metadata' operation[1] would be usable for this with some
extra work. I'll have to think about this...
... since getting a 100% reliable solution here might take quite a bit
more work than I thought, how about a not-quite-100% hack? Instead of
propertizing the first character of each candidate, propertize the
*last* character (or the entire string?). That won't get thrown out
quite so easily.
[1]
https://www.gnu.org/software/emacs/manual/html_node/elisp/Programmed-Completion.html
This bug report was last modified 1 year and 277 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.