Re: word-wrap and wrapping before window-width

[Ivan Shmakov]

>>>>> Eli Zaretskii <address@hidden> writes:
>>>>> From: Ivan Shmakov  Date: Wed, 31 Dec 2014 17:55:33 +0000

 >>> And Firefox does that too: it inhibits word wrap when horizontal
 >>> scrolling is in effect.  It just doesn't unwrap what was already
 >>> wrapped, that's all the difference.

 >> Frankly, I’m not so sure of this interpretation.  Anyway, from the
 >> user’s perspective, – is there a difference between “not unwrapping”
 >> and “wrapping at an arbitrary column”?

 > This is emacs-devel, not help-gnu-emacs ;-)  So our perspective is
 > different.

        My understanding of how CSS support is implemented is that
        window geometry changes are one but by no means the only way
        that may lead Firefox to recompute the container widths.  Once
        the width is computed, – the text is wrapped at that exact point
        (if at all.)

        In the case at hand, the width of the container was constrained
        to be no less of the contained object (<pre /> in this case.)
        Which gave the behavior observed.  This is a sure possibility,
        but I know of nothing in the specifications that’d suggest
        that’s a necessity.

 >>> Yes, but Emacs has a harder job to do: the above model is
 >>> problematic with bidirectional text when a single buffer has
 >>> paragraphs of different directionality (which Firefox doesn't seem
 >>> to support).

 >> You mean, your install Firefox install doesn’t cope with, say, the
 >> simplistic example document shown at [2]?

 >> [2] 
 >> https://ru.wikibooks.org/wiki/HTML_в_профилях/Базовый_профиль#multilingual.html

 > No, I meant it cannot determine the base paragraph direction
 > automatically, as Unicode requires.

        I presume that Unicode paragraphs are not meant to be exactly
        the same thing as HTML5 paragraphs?

        Anyway, the HTML5 TR clearly specifies at which point the
        paragraph direction is reconsidered; see [1].  For one thing,
        the directionality of the <pre /> contents is (AIUI) determined
        on per line basis.

[1] http://www.w3.org/TR/html5/dom.html#the-dir-attribute

 > Also, its horizontal scrolling of mixed-directional paragraphs makes
 > it hard to read the stuff, because scrolling to the right makes RTL
 > text at the beginning of a line disappear.  Emacs does a much better
 > job in that respect.

        I do not think I understand.  Care to provide examples?

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A