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

[Eli Zaretskii]

> From: Ivan Shmakov <ivan@siamics.net>
> Date: Fri, 23 Jan 2015 19:45:31 +0000
> 
>  > format=flowed etc. is already supported by word-wrap, isn't it?
> 
>       Not in its entirety; consider, e. g. (section 4.1 of RFC 3676):
> 
>    If the line ends in a space, the line is flowed.  Otherwise it is
>    fixed.  The exception to this rule is a signature separator line,
>    described in Section 4.3.  Such lines end in a space but are neither
>    flowed nor fixed.
> 
>       I know of no way to make the Emacs display engine wrap one line
>       but not the other in the very same buffer.

But then the feature you suggest will have the same problem, since it
will be build on the same infrastructure as word-wrap.

>  >> 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.
> 
>       I guess I can, but most probably /not/ in the next few months.

There's no rush.

> 
>       (The biggest problem for me would be the change of the tools and
>       the workflow.  Say, nothing like eval-defun is going to be
>       available while working on the C code.  Also, I’m not really
>       keen when it comes to non-tty Emacs frames, – never felt those
>       as of being of much value for my tasks.)

Something to learn, I guess.

>  > 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.
> 
>       “Physical” as in “display” or “buffer”?

In the buffer, i.e. up to the next newline.

>  > 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.
> 
>       Basically, yes, I thought about the display engine keeping track
>       of the latest “wasted” rectangular chunk of screen space, and
>       allowing for it to be occupied by the text coming later in the
>       “buffer” order.  (Or perhaps up to two such chunks: one to the
>       right and one to the left of the text being drawn.)

That's the whole problem: the current display engine doesn't manage
any rectangular space.  It proceeds one line at a time.

>       IIUC, display_line would potentially have to be called several
>       times to draw a single display line.

Several calls is not the problem.  The problem is how to know with
which buffer position to call it.

>       And all this behavior only triggered when the text being drawn
>       has some specific property; once the property value changes, —
>       the state is reset.

Redisplay will take care of that, so again, this isn't the problem.