Re: Bug in zero-length extents
Hrvoje Niksic <hniksic(a)arsdigita.com> writes:
I don't have a fix.
Or do I? Not really, but at least I have a clue where to look at if
someone is willing to investigate. redisplay.c's create_text_block()
contains this code:
/* If there are end glyphs, add them to the line. These are
the end glyphs for the previous run of text. We add them
here rather than doing them at the end of handling the
previous run so that glyphs at the beginning and end of
a line are handled correctly. */
else if (Dynarr_length (data.ef->end_glyphs) > 0)
{
*prop = add_glyph_runes (&data, END_GLYPHS);
if (*prop)
goto done;
}
/* If there are begin glyphs, add them to the line. */
else if (Dynarr_length (data.ef->begin_glyphs) > 0)
{
*prop = add_glyph_runes (&data, BEGIN_GLYPHS);
if (*prop)
goto done;
}
And this is our culprit. This code is in a loop that runs as long as
there's something to do. It deliberately first handles the
"END_GLYPHS" case and then the "BEGIN_GLYPHS" case. Therefore
it's
tempting to try to fix it by swapping the two. I've tried that, and
it fixes the zero-length extent problem. But...
But it breaks another case. Consider two adjacent extents, touching
side by side:
extent a
extent b
12345678901234567
So, extent A is [1, 9), and extent B is [9, 17). Now imagine they had
begin and end glyphs like this:
[extent a]
{extent b}
12345678 90123456 7
You would want this to be displayed like this:
[extent a]{extent b}
12345678 90123456 7
And that's exactly how it's displayed -- and that's one case where it
makes sense to process end glyphs first. After reversing the order of
the two above blocks in create_text_block, you get:
[extent a{]extent b}
12345678 90123456 7
There might be a simple way of solving it, but it will have to be
devised by someone who actually understands the redisplay code. The
only solution I can think of is to extend the "extent fragment" with
some additional information about the begin/end glyph.
For example, we might have a flag denoting whether the glyph belongs
to a zero-length extent. That way we could first display the
end-glyphs of non-zero-length extents, then the begin-glyphs of
zero-length extents, then the end-glyphs of zero-length extents, and
finally the end-glyphs of non-zero-length extents. (At least I
believe that is the most desirable ordering.)
There could be even more complex ordering based on the length of the
extents ("display order" and all that), but I don't think anyone sane
would want to depend on that.