bug#19661: wrapping before window-width (new wrap-column text property?)

[Eli Zaretskii]

> From: Ivan Shmakov <ivan@siamics.net>
> Date: Fri, 23 Jan 2015 13:17:08 +0000
> 
>       Please provide support for window-width-independent wrapping in
>       the Emacs display engine; possibly by the means of a new
>       wrap-column text property (and still perhaps complemented by a
>       eponymous buffer-local variable), treated similarly to the likes
>       of wrap-prefix.
> 
>       This feature could be used to display format=flowed (RFC 3676)
>       MIME parts, as well as enriched-mode documents, documents using
>       MediaWiki markup, SHR-rendered HTML documents, and pretty much
>       any other kind of text which allows for /both/ wrappable and
>       preformatted parts at the same time.

format=flowed etc. is already supported by word-wrap, isn't it?

>       I admit that I know very little of the current Emacs display
>       implementation.

How about biting the bullet and trying to do this yourself?  I can
provide guidance and advice, if needed.

>       Yet, provided that some other property is switched on, the Emacs
>       display engine may decide to show it like this instead:
> 
> This is an example       This is yet another example sentence with line-prefix
> sentence with            and wrap-prefix both set to (space :align-to 25), –
> wrap-column set to 23.   or something like that.

This is a much harder nut to crack, and having wrap-column doesn't
help with that.

The fundamental problem here is that the Emacs display engine is based
on an "iterator" object that basically walks a buffer and generates
"glyph" objects that are then given to the display back-end for actual
display.  The iterator object has only a very myopic view of the text
it walks through.  Before Emacs 24, that view was one-character long
-- we only looked at the next character in the logical order.  With
Emacs 24's bidirectional display, the field of view became slightly
wider, but it is still limited to a single physical line, and most of
the display doesn't even know about that, the single exception being
bidi.c.

Now, the current display engine's workhorse is display_line, which
produces glyph objects for a single screen line.  What it does is call
a function to find the next "display element" (character, image,
composition, etc.) to display, produces glyphs for it, and goes to the
next display element in the visual order.

With your suggestion, once the width of the laid out glyphs reaches
some pixel value, the next display element will need to come from a
different part of the buffer.  But how to know where in the buffer is
that?  You cannot know that until you are done with layout of the
entire visible portion of the left-side pane, the one that in the
above example ends with "set to 23."

So either we need a deep surgery of display_line, so that it acquires
the ability to produce layout of each screen line in several parts, or
we write some tricky code that would perform all the necessary
calculations to find the buffer position of "This yet another example"
when we are done producing "This is an example" and want to continue
with the same screen line.

The former alternative means significant changes all over the display
engine, the latter means redisplay will be slower (not sure by how
much).  So both are highly non-trivial.

>       As already imagined in the preceding discussion, forward- and
>       backward-char commands would then still follow the logical order
>       of text in the buffer (that is: the “23” sentence, then the “25”
>       one), while left-char, etc. would follow the visual order
>       (assuming visual-order-cursor-movement.)

That's the least of our trouble: the function that finds the place to
put the cursor (set_cursor_from_row) already thoroughly analyzes the
window display, and in Emacs 24 was rewritten to make it independent
of many assumptions that were broken by bidirectional display.

Perhaps you think that Emacs moves cursor visually, in which case it
would have had problems when the logical flow of text is broken like
that.  But that's not what Emacs does to move cursor: it moves point,
updates the display, and then figures out where in the new display to
put the cursor.