Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 22 Nov 2021 15:50:20 +0100
> 
> I think it's generally useful.
> 
> > If it's the former, we need to talk about the design, because the way
> > you wrote the code, it violates several protocols of the display
> > engine, and that needs to be fixed first (and will probably also fix
> > the problems you have with the cursor).
> 
> Sure, talk away.  😀  This is my first attempt at implementing something
> in the display engine (as opposed to tweaking bits), so as much advice
> as possible will be helpful.

For starters, here's a thought: why not make this feature a variant of
the 'display' property, rather than inventing a new kind of property?
We already have similar variants of 'display': (height HEIGHT) and
(raise FACTOR), and this one sounds similar enough.  The advantage of
doing that is that you will then have much of the infrastructure and
the framework into which to drop your additional code: the
handle_display_prop function, the handle_single_display_spec function,
and the code there which shows how this stuff is done.  You will also
have display_prop_end function, which will help you know where the
text with this property ends (so you know where to produce the stretch
glyph).  In short: the processing of 'display' properties is already
well integrated into the overall design of the display engine, so
adding there one more variety should be relatively easy.

And one other important thing: never call append_FOO_glyph directly.
Instead, call produce_FOO_glyph.  That's because produce_FOO_glyph
already takes care of many things that you otherwise will have to do
manually (and make mistakes).  For example, this:

> +static enum prop_handled
> +handle_min_width_prop (struct it *it)
> +{
> +  if (STRINGP (it->string) || !it->glyph_row)
> +    return HANDLED_NORMALLY;

is unacceptable: when it->glyph_row is NULL, it usually means we are
emulating redisplay without producing glyphs, but the data in 'it'
still needs to be maintained as if we did, because otherwise stuff
like vertical-motion and its callers will stop working.  You will see
in produce_stretch_glyph that it does get this case correctly.