Re: refill paragraph but visually (like visual-line-mode)?

["Garreau\, Alexandre" <galex-713@galex-713.eu>]

On 2018-10-15 at 18:21, Eli Zaretskii wrote:
>> From: "Garreau\, Alexandre" <galex-713@galex-713.eu>
>> Date: Mon, 15 Oct 2018 11:35:50 +0200
>> 
>> First of all, the text ends wrapped at the right edge of window, even if
>> that means quite long lines (such as more than 66 columns: 111 is the
>> default with my default current font), which is more a pain of reading
>> (eye must move more, stuff to see are more distant from each others).
>
> Did you try to enlarge the window's display margins?

No, I didn’t know of them, only of fringes, which I recalled could be
resized, but forgot how.

visual-fill-column-mode is really great, it even centers text (I
wouldn’t have hoped so).  Then comes the other (now solved) problems:

>> Oddly I found nor in searching variables/functions nor in
>> documentation anything to limit automatic visual word-wrapping to
>> something such as 66, 72, or something more comfortable.
>
> Such options don't exist.  You need to keep in mind that
> visual-line-mode (or "word wrap", as this feature is known in the
> internals) is just a semi-kludgey hack: we tweak the line-continuation
> code to start the continuation line on whitespace characters.  Other
> than that, it's still the same continuation line, and uses the same
> code to detect when it's time to wrap the line.  And even this
> relatively simple tweak makes the line-wrapping code devilishly
> complicated and hard to wrap your head around.
>
> It is possible that making the wrap coordinate controllable by users
> is not too hard, but Someone™ should look at the relevant code and try
> making it happen.  Maybe we will be lucky.
>
> Wanna try it?

isn’t it what visual-fill-column-mode does?

>> So indentation is broken, and it hard to correctly read afterwards.
>> I guess this may be complicated to implement, but as emacs auto
>> indent works most of time, wouldn’t there a way to put visual indent
>> too?
>
> Could be, but again, Someone™ should work on this.  One potential
> obstacle to negotiate is that, unlike the existing indentation
> functions, which traverse the buffer in order to find out the
> indentation of surrounding lines, the display code cannot easily do
> that, because the display routines are expected to be able to be
> called with a buffer position from which to start display, and be able
> to lay out a single screen line without knowing anything about the
> neighboring lines.  Some algorithm is needed to calculate the right
> indentation in those cases.

I was only thinking about some sort of adaptive-wrap-prefix-mode that
would use indentation of the first line as adaptive-prefix-wrap already
does.  Yet indeed, if all visual lines are actually from a single long
continued hard line, that has to be really difficult as some special
indentation should have to be stored invisible with the rest of logical
line (ie. e.g. instruction line) so that to be used afterwards, lazily
as it is currently done.

>> And last but not least: if the text (usually human text) I’m reading
>> is already wrapped, by fill-paragraph for instance, I end up with
>> pairs of filled long-lines + very short lines (lines end) which is
>> really ugly: word-wrap only wraps, but not refill.  I’d like an
>> option or mode that puts at the end of the visual line the beginning
>> of the next logical line, just as fill-paragraph do, but only
>> visually, and keeping an (invisible) trace of the original/logical
>> newlines.
>
> This should be possible by hiding newlines behind display properties
> or overlays.

Hence visual-fill-mode, with some improvement it might work terribly
well everywhere in emacs.

> Patches are welcome to implement any of these useful features.

Patches? do you fill that would be relevant in main emacs?  maybe
keeping them as packages for a while before, so that to test them?

At least visual-fill-mode needs some twiddling related to some modes (or
maybe do modes need to specify when newlines (or any other character
such as “;” (both C and lisp), or "\n\t" (python)) are of semantical
relevance and should not be hidden, and when they’re not and should be?)
before, I’d say.