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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: rudalics <at> gmx.at, 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, 12 Jan 2013 16:12:38 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: rudalics <at> gmx.at,  13399 <at> debbugs.gnu.org
> Date: Sat, 12 Jan 2013 08:20:50 -0500
> 
> > But why would we need that?  Most everything we need to know about
> > display is already tracked by the display iterator, so available even
> > without generating glyphs, and that's what the move_it_* functions do.
> > These function do their job by traversing only small portions of the
> > buffer, just large enough for the job at hand to be done.
> 
> What about posn-at-point?

What about it?  It already uses move_it_*, see pos_visible_p, which
does all the work.

> > OTOH, updating the entire glyph matrices of all of the windows on all
> > of the frames AFAIR takes the lion's share of time used by redisplay,
> > so we might as well force a complete redisplay when we do need
> > complete up-to-date matrices.
> 
> posn-at-point doesn't need to refresh all glyph matrices, only the one
> of the selected window.

Look at pos_visible_p, and you will see that what it does is
start_display at window top, then move the display iterator to where
point is displayed, and taking the pixel coordinates from the display
iterator when that's done.  What else is needed, that the glyph matrix
of the window would provide?

Previous Next

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