Re: feature/icomplete-vertical

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Cc: ghe@sdf.org,  spacibba@aol.com,  emacs-devel@gnu.org,
>   casouri@gmail.com,  juri@linkov.net
> Date: Mon, 05 Oct 2020 20:32:26 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I think can understand some of Gregory's frustration.  If those problems
> >> are real, it should be possible to showcase them.
> > The second one was showcased by Gregory himself.
> 
> If I read that correctly that was a synthethic, not a real-life example.

I fail to see how that is a disadvantage.  Most examples that
illustrate some point are synthetic, because real-life examples run
the risk of hiding the important stuff behind gobs of irrelevant code.
That's why, for example, we ask for simple reproduction recipes when
people report bugs.

> > Sorry, I'm unable to encourage Gregory to understand the shortcomings,
> > no matter how much I tried, I guess it's my fault.
> 
> It's not a question of "fault" or persuasion, it's a simple question
> that code speaks louder than words: good examples can be taken through a
> debugger and revealing where in actual code the shortcomings of a given
> approach manifests themselves.

I'm sorry, but I can only afford hand-holding up to a limit.  I
provided explanations and described how the relevant parts of the
display engine work.  I also reiterated considerations that should be
apparent even without any details, such as that global variables get
in the way of reentrancy, even if they are buffer-local variables.  I
invite you to read the 3 relevant threads and see for yourself.  If
that is not enough, and if the Emacs code doesn't speak loud enough to
be of help, then Gregory should simply take my word for it, as someone
who has many more hours hacking Emacs than he does.  I simply cannot
afford investing so much of the little time I have into educating
people here, and expecting that would be unreasonable and even unfair.

> > Although it sounds like the same situation is repeating with Martin's
> > advice regarding mini-window resizing, so maybe it isn't entirely my
> > fault after all.
> 
> If I read correctly, Martin reinforced how non-trivial calculations
> regarding mini-window sizing is, thus _strenghtening_ the case for
> having a solution where the application isn't responsible for that, as
> you suggest.

That's not my interpretation.  Gregory said that measuring the
pixel-size of text is hard, to which Martin replied that resizing the
mini-window accurately can be even harder.  Then Gregory dismissed
Martin's opinion out of hand.  Martin has more experience with the
window- and frame-related code in Emacs than all the rest of us, so
dismissing his opinions on that is not recommended.