GNU bug report logs - #13399
24.3.50; Word-wrap can't wrap at zero-width space U-200B

Previous Next

Full log

Message #101 received at 13399 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: monnier <at> iro.umontreal.ca, 13399 <at> debbugs.gnu.org
Subject: Re: 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.