[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problems with move_it_in_display_line_to X when tabs exist.
From: |
Eli Zaretskii |
Subject: |
Re: Problems with move_it_in_display_line_to X when tabs exist. |
Date: |
Tue, 16 Jan 2018 19:00:43 +0200 |
> Date: Mon, 15 Jan 2018 20:41:52 -0800
> From: Keith David Bershatsky <address@hidden>
> Cc: address@hidden
>
> The following screenshots with stderr results were obtained by calling the
> function debug-tab-pixel-width, which is contained in the attached
> patch.diff. I saw that x_produce_glyphs is able to achieve the correct
> it->pixel_width for the STRETCH tab when x0 >= it->lnum_pixel_width; however,
> it is run subsequent in time to when we call move_it_in_display_line_to.
>
>
> 0. Opening screenshot -- just setting up the test buffer.
>
> https://www.lawlist.com/images/tab_width_bug_00.png
>
>
> 1. Place the cursor on the line that begins with a tab, and press the f5 key
> once.
>
> https://www.lawlist.com/images/tab_width_bug_01.png
>
> OBSERVATIONS (w->hscroll == 1): The expected result is that the STRETCH
> tab will have an it.pixel_width of 42. The third (3rd) iteration/loop has
> the wrong value; i.e., 49. The fourth (4th) iteration/loop has the correct
> value; i.e., 42. x_produce_glyphs runs subsequent in time and contains the
> desired value of 42 when x0 >= it->lnum_pixel_width.
What do you mean by "x_produce_glyphs runs subsequent in time"? The
value of it->pixel_width is updated by x_produce_glyphs, so before it
was called, that value is outdated (belongs to the previous glyph).
If that is what you observe, then it's the expected behavior, and not
a bug.