bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B
Date: Sat, 12 Jan 2013 16:56:31 +0200

> Date: Sat, 12 Jan 2013 15:29:57 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: monnier@iro.umontreal.ca, 13399@debbugs.gnu.org
> 
>  > Very simply: it simulates the display.  See pos_visible_p (which
>  > posn-at-point calls).  That's what I meant when I said that doing this
>  > for determining the line width or height should be easy.
> 
> Here I see the following call sequences:
> 
> `fit-window-to-buffer'
>    -> `count-screen-lines' -> `vertical-motion' -> move_it_to
>    -> `pos-visible-in-window-p' -> pos_visible_p -> move_it_to
> 
> So everything `fit-window-to-buffer' does ends up calling move_it_to and
> the loop called via `pos-visible-in-window-p' is likely silly.

fit-window-to-buffer should probably call pos-visible-in-window-p with
argument PARTIALLY non-nil, and then it should be possible to get rid
of the loop.

> Using
> 
> `posn-at-point' -> `pos-visible-in-window-p' -> pos_visible_p -> move_it_to
> 
> `window-end' -> move_it_vertically -> move_it_to
> 
> probably won't produce anything else.  This means that somehow
> move_it_to fails to DTRT here.

If you can show a case where it fails, it should be possible to fix
it.  OTOH, it could be that these Lisp tricks try to work around
failures in move_it_to that were already fixed.

> I don't have a deterministic scenario to produce the bug.  I attach a
> file you can try via `eval-buffer' followed by M-x foo.  After that
> you'd have to resize the frame randomly (usually shrinking it
> vertically) until it hides the last line(s) of the *foo* window.  This
> usually takes a few seconds here.
> 
> The hiding does not occur when I do not draw a box around characters.  I
> didn't try different character heights, bold face, etc. so far.  Note
> that in normal work I use a maximized frame and the bug shows up
> frequently when changing text in *foo* (using another hook) or the
> window configuration.

I think what you see only happens when the last line is partially
visible (where "partially" might mean just one of its pixels).  If
that is not desirable, then we will need to be more accurate when we
say "visible" and have a more precise definition of what exactly
constitutes a window's height when a single line, in particular the
last one, might have characters of different descent values.

In any case, this is a failure in fit-window-to-buffer, if anything,
it is not necessarily an evidence that move_it_* functions fail.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]