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

[martin rudalics <rudalics@gmx.at>]

 > 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