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

Previous Next

Full log

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 13399 <at> debbugs.gnu.org
Subject: Re: bug#13399: 24.3.50;
	Word-wrap can't wrap at zero-width space U-200B
Date: Fri, 11 Jan 2013 13:50:00 -0500

>> In the case of the mouse-face property that means you can use (list
>> 'my-face) on the chunk you want to make sure it's not `eq' to an
>> adjacent chunk.
> Good to know that trick (undocumented I presume).

Maybe it's documented somewhere, but at least the doc of the
`mouse-face' text property doesn't mention how boundaries are
determined, indeed.

>> W.r.t. functions that return the pixel width/height of a string, I guess
>> you'd presume that the string would be displayed at the leftmost
>> position on a line, since the width/height of a string will depend on
>> where it's displayed in the window (which affects the width of TAB
>> chars, and the placement of line wraps).
> Yes.  In my use case the buffer has no newline.

Does the absence of newline make a difference to the problem?

> How could `posn-at-point' possibly work if the display is not up to
> date?

Actually, it does not require the display to be up-to-date, only the
glyph-matrices.

> And what I want to avoid is the redisplay.

You should be able to update the glyph-matrices without causing the
display to immediately reflect the changes.  E.g. window-end with
a non-nil `update' argument should do that, IIUC.


        Stefan

Previous Next

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