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

[João Távora]

On Mon, Aug 16, 2021 at 11:53 AM Daniel Mendler <mail@daniel-mendler.de> wrote:

> >> There are serious drawbacks of attaching "private" string properties to
> >> arbitrary strings. For once it complicates debugging seriously if there
> >> are suddenly string properties attached to symbol names. It also leads
> >> to a potential memory leak.
> > Please, in the name of the sanity of this discussion, justify these two
> > statements with examples or follow them with a clause like "because...".
> João, I am giving hard examples here.

If I say to you:  "It's quite obvious your patch breaks all Git repositories
in Kathmandu, Nepal"  I am expected to demonstrate how a patch to
Emacs, leads to a obscure security flaw in the Linux operating system,
that tickles a butterfly at a certain angle that causes an earthquake
in the Kathmandu data center, literally breaking their Git repositories.

This is the the kind of statement you are making to me and the kind
of logical reasoning I'm looking for.

Alternatively, you can provide an actual experiment I can run in
my computer that demonstrates the bug.

I am not a native English speaker, and maybe you don't understand
my language.  Another way to explain what I am talking  is to talk about
"bug reproduction".  You say there's a bug in my patch, I am asking you
for a "bug reproduction recipe" as defined by most,  if not all, the results
you get by searching "bug reproduction recipe" in the Google search engine.

> goal is not to be right here just for the sake of being right. As Eli
> said, nobody has to prove anything.

This is clearly not what he said.

> >> 3. The `completion-filter-completions` API is the fastest possible API
> >
> > Again that's quite a statement that I cannot evaluate the veracity of
> > without hard proof.
>
> As I said, I will ensure that my API does not introduce performance
> regressions.

Not only that, to produce  veracity on that statement you would need
some much more demanding proof, which is somehow be able to
evaluate all possible APIs to compellingly demonstrate that yours
triumphs.

>  I have a patch for Vertico which shows
> this. I can provide patches for 'icomplete-mode' separately later on.

Yes, please do. The earlier, the better.

> No, we should not merge this problematic patch of yours. See the many
> arguments against this proposal.

I'm sorry to speak this child-like language, but a problem is a "bad thing".
An undesirable thing that happens when presumably safe and good
action(s) is taken by some user.  Can you explain how, given my patch,
a user would take a sequence of innocent actions that would lead to a
"bad thing" that would _not_ happen if the same sequence of innocent
actions were taken  in a version of Emacs without the patch applied?
That, to me, is what constitutes "a bug/problem in the patch".

Let me give you an example: if I make a patch that deletes `/lisp` in
the Emacs source tree, the innocent action "make"  would probably
not work.  That would be the problem/"bad thing"/bug in that patch.

We cannot proceed this discussion without these explanations.  Mind
you, I'm not stating, because it is impossible to prove, that my
patch cannot possibly generate problems, subtle or obvious (that, by
the way, is my interpretation of what Eli meant). But since you so
confidently state that it does, it's quite reasonable that I ask you
for examples that demonstrate it.

Once you do demonstrate these bugs, it's reasonable I will go about
fixing them.  Exactly as you say you are going to do.  I demonstrated
with code and numbers a regression in _your_ patch, and you say are
going to fix it.  That's great, and that's the way it should be.  But
you possibly wouldn't go about fixing it if I hadn't demonstrated the
regression compellingly, just as I can't go about fixing a "memory leak"
or "debugging difficulties" if you don't explain what these things mean
to you or how my patch causes them.

João