bug#61283: 29.0.60; pcomplete-completions-at-point loses text properties, breaking pcomplete-from-help annotations

[Jim Porter]

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
Description: Text document