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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: monnier <at> iro.umontreal.ca, 13399 <at> debbugs.gnu.org
Subject: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B
Date: Sat, 02 Feb 2013 20:36:10 +0200

> Date: Sat, 02 Feb 2013 19:20:44 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: monnier <at> iro.umontreal.ca, 13399 <at> debbugs.gnu.org
> 
>  >> +  /* 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.

Because there was no need.  Now there is.

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

It should be simple enough to add them up externally.

Adding a member to 'struct it' has the downside of enlarging the
structure, which slows down any code that copies such structs.  We are
going to punish all the users for the benefit of just one.  So I think
we should avoid that.

>  > 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?

Yes.

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

Then how about text-pixel-size?

>  >> +  /* 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?

move_it_to might overshoot in those cases, i.e. you get more pixels
than strictly needed.  But OTOH, I see no way of asking for more
specific limits in these cases, nor a use-case where that could be
needed.  So I guess we are okay until someone hollers.

Previous Next

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