bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting

[Eli Zaretskii]

> Cc: joaotavora@gmail.com, monnier@iro.umontreal.ca, 48841@debbugs.gnu.org,
>  47711@debbugs.gnu.org
> From: Daniel Mendler <mail@daniel-mendler.de>
> Date: Mon, 16 Aug 2021 10:48:19 +0200
> 
> On 8/14/21 9:12 AM, Eli Zaretskii wrote:
> >> Since up until now completion-pcm--hilit-commonality copied all strings 
> >> before modifying, completion tables such as described (with "shared" 
> >> strings) have all been "legal". Suddenly deciding to stop supporting 
> >> them would be a major API breakage with consequences that are hard to 
> >> predict. And while I perhaps agree that it's an inconvenience, I don't 
> >> think it's a choice we can simply make as this stage in c-a-p-f's 
> >> development.
> > 
> > This sounds like an argument against Daniel's approach as well, no?
> > Because if a completion API returns strings it "doesn't own", there
> > will be restrictions on Lisp programs that use those strings, because
> > those Lisp programs previously could do anything they liked with those
> > strings, and now they cannot.  Or am I missing something?
> 
> No, in my patch the displayed candidate strings are still copied before
> the text properties are attached. The strings are kept intact as they
> are now.

I was talking about the infrastructure that produces the completion
candidates, not about the application that uses them.  My point is
that your approach requires the applications using the candidates to
copy them, whereas previously they could use them without copying.