Re: Pixel-based display functions

[Eli Zaretskii]

> Date: Sun, 01 Feb 2015 19:09:22 +0100
> From: martin rudalics <address@hidden>
> CC: address@hidden, address@hidden, address@hidden
> 
>  > The problem, as I understand it, is to find the place where to insert
>  > these breaks, when column text is wider than the column.  And
>  > window-text-pixel-size cannot tell you that, it can only tell whether
>  > the chunk of text fits or not.
> 
> IIUC he would have to check each word whether it still fits into his
> column including a leading space.  Maybe he could start with some n
> words and remove those that don't fit.

Yes, that's possible.  But font-get-glyphs allows to do this directly,
without iterations.

> I have no idea how Emacs deals with line-breaking embedded R2L text
> anyway.

The same as it does with L2R text.  Line breaking in Emacs works in
visual order.

>  > It's not kaput.  The problem happens only if its results are used for
>  > inserting a newline in order to break the line in two.  In all other
>  > use cases, it does exactly TRT.
> 
> I haven't looked into this yet but am afraid that if FROM or TO are
> somewhere within R2L text it won't necessarily report the maximum length
> of a line.

I don't see why it wouldn't report the maximum length.  It actually
reports the maximum X coordinate, so bidirectional reordering cannot
break that, since pixel coordinates are still measured left to right.

Unless, that is, you mean R2L lines (and not R2L text within a L2R
line), in which case you indeed need to offset the X coordinate by the
window's text-box width.  This needs to be done in move_it_to.  See
near the end of pos_visible_p for how this is done.