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 #74 received at 61283 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 5/18/2023 6:30 AM, Stefan Monnier via Bug reports for GNU Emacs, the
Swiss army knife of text editors wrote:
>> ... 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.
>
> I'll see your "last char" and raise you a "the whole string" (and then
> use the property on the first char where it's found, using
> `next-single-property-change`)?
After thinking this over some more, how about a completely different
strategy like the following? This uses a programmed completion
function[1] to supply an annotation-function as appropriate.
This also fixes a tangentially-related issue where long options that
take an argument added an extraneous space after the trailing "=". (This
bit is actually the original patch I was working on before discovering
the issue described in this bug.)
Pcomplete might have some issues with handling programmed completion
functions like this, but I *think* it makes sense to go this route if
possible: making Pcomplete work more like the rest of Emacs' completion
code would be very nice.
[1] "Programmed completion" vs "programmable completion (Pcomplete)":
*that's* definitely not confusing at all. ;)
[0001-WIP-Use-a-programmed-completion-function-to-handle-l.patch (text/plain, attachment)]
This bug report was last modified 1 year and 278 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.