[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B
From: |
martin rudalics |
Subject: |
bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B |
Date: |
Sat, 02 Feb 2013 19:20:44 +0100 |
>> + /* Maximum x pixel position encountered within a display line. */
>> + int max_current_x;
>
> Adding a struct member for the sake of just one user sounds
> unjustified. Can we instead make move_it_to accumulate the value
> internally and return it?
I don't know. IIUC most iterator functions never return something
useful. And if one wants to glue together the results of subsequent
calls of move_it_to, it might make sense to not reset the value
internally.
> In any case, the comment is inaccurate, since the value is accumulated
> across all the display lines traversed by the iterator, not computed
> per display line.
Would "within any line traversed by the iterator" be better?
>> +DEFUN ("window-buffer-pixel-size", Fwindow_buffer_pixel_size,
Swindow_buffer_pixel_size, 0, 5, 0,
>
> Why not window-text-pixel-size? The "buffer" part doesn't belong
> here, I think.
Since I also look at buffer portions outside the window, such a term
wouldn't be very accurate either.
> "Lines starting below Y_LIMIT" is ambiguous. I suggest
>
> Lines whose y-coordinate is beyond Y_LIMIT will not be scanned.
OK.
>> +Since calculating the pixel-height of a large buffer can take some time,
>> +it makes sense to specify this argument if the size of the buffer is
>> +unknown. */)
>
> The doc string keeps silent about arguments FROM and TO.
... because I only added them later on ;-) Initially I always scanned
from `point-min' to min (`point-max', y_limit) but later I noticed that
with side-by-side windows it makes sense to start at `window-start'.
>> + /* Actually, we never want move_it_to stop at to_x. But to make sure
>> + that move_it_in_display_line_to always moves far enough, we set it
>> + to MOST_POSITIVE_FIXNUM and specify MOVE_TO_X. */
>> + move_it_to (&it, end, MOST_POSITIVE_FIXNUM, max_y, -1,
>> + MOVE_TO_POS | MOVE_TO_X | MOVE_TO_Y);
>
> Did you test what this does when END is covered by a display string?
No. I didn't try invisible text and other atrocities either. In fact,
I never experimented with a non-ZV end position so far. Which problems
do you see?
martin
- bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B, martin rudalics, 2013/02/02
- bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B, Eli Zaretskii, 2013/02/02
- bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B,
martin rudalics <=
- bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B, Eli Zaretskii, 2013/02/02
- bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B, martin rudalics, 2013/02/03
- bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B, Stefan Monnier, 2013/02/03
- bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B, Eli Zaretskii, 2013/02/03
- bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B, martin rudalics, 2013/02/04
- bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B, Eli Zaretskii, 2013/02/04