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

Previous Next

Full log

Message #92 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: Mon, 14 Jan 2013 19:04:15 +0100

> Would something like this be good enough?
>
>   (save-excursion
>     (move-beginning-of-line 1)
>     (setq pos1 (posn-at-point)))
>   (save-excursion
>     (move-beginning-of-line 2)
>     (setq pos2 (posn-at-point)))
>
> Then use the Y member of the returned information in pos1 and pos2.

Looks like this should work.  But at the moment I'm a bit lost with the
information returned by `posn-at-point': What precisely stands the value
of (nth 2 (posn-at-point (point-max))) for?  If my buffer ends with a
newline, is that the value of the lowest pixel of the chararacter box of
the character just above the cursor?  Can it include line spacing?

I wonder because I find this calculation in `posn-col-row' confusing:

	      (- (/ (cdr pair) (+ (frame-char-height frame) spacing))
		 (if (null (with-current-buffer (window-buffer window)
			     header-line-format))
		     0 1))))))))

It does not round values, so the value of rows can be less than needed
for showing the entire text.  OTOH it seems to apply spacing to the last
line of a buffer.  Finally, if a buffer wants a headerline, evaluating
(posn-col-row (posn-at-point (point-min))) gives (0 . -1).  Is that
useful?

So I'm working with the raw data returned by `posn-at-point' and the
results are not worse than with the current approach.  But I still seem
to lose some pixels somewhere ...

martin

Previous Next

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