[Top][All Lists]

[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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]