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

[Garreau, Alexandre]

On 2018-10-15 at 11:56, Stefan Monnier wrote:
>> The current problem of visual-line mode and why I almost never use is
>> up to three reasons:
>>
>> 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).  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.
>
> You might like the visual-fill-column packaqe which widens the margin
> such that your 111-wide window only has 66-wide columns (sounds like
> a big waste to me: I'd rather make the window narrower and use the
> remaining space for something else, but to each his own).

At beginning I was fearing you were speaking about increasing the
fringes width, as I first saw in “emacs’ strip tease” or something, so
I’ve feared I couldn’t profit of splitting my screen without loosing a
lot of space…  But actually it plays nice with splitting!  I didn’t know
there were “visual margins” which were different from the fringes (but
now I begin thinking using the fringes instead of these “visual
margins”, would have been better, but putting them inside as well is
weird but just as functional).

>> In second stance, when reading source code, and this is normally the
>> case I’d find word-wrap the most useful, the wrap just happens to
>> continue the logical line from the *beginning* of the next visual
>> line.  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?
>
> You might like the adaptive-wrap package for that.

Interesting, yet this does not support using indentation commands for
that…  adaptive-fill seems to support using a function, it may be
trivial to use indent-for-tab-command in it if it was asking for an
imperative procedure like emacs have tons of, instead of a function
returning the prefix…

> [ Here again, I'd suggest to shorten the source lines as a better
>   solution, because long lines in source code are just an abomination,
>   but admittedly if it's not your code adaptive-wrap-prefix-mode might
>   be helpful.  ]

In source code I would indeed just shorten the lines at 72 columns
(sometimes 66, sometimes 68, with a stated max of 80) as this is
standard and sometimes I’d even say somewhat linked to backward
compatibility (however I find sad that something that is not semantic
and user-configurable has crystalized this way).

> But I guess if you do it without modifying the buffer (i.e. only using
> features which affect the display but not the buffer's contents), the
> warts would at least be "harmless".

That’s the point.

> There's `refill-mode` which provides a related feature, but it just
> does the M-q for you while you edit the text, which won't help you if
> you're only reading the text.

But I indeed as you guessed wanted something visual so not to bother
with modifying anything.

> I don't have a package to suggest here :-( Hopefully, one exists, tho.

Are you speaking of `refill-mode' ?

> The main difficulty here is that to do a proper refill, you need to find
> the paragraph boundaries and there's no reliable rule for that (only
> heuristics and conventions), so doing it 100% automatically tends to
> come with warts and all (which is why refill-mode only performs the
> refill for the paragraphs which you do edit, for example).

I’m fine with the TeX / org-mode standard, followed by fill-paragraph,
of an empty line to separate paragraphs. This just works.

The only exception I still find, is for some lines (that coincidentally
would match `adaptive-fill-regexp') such as enumerations (like in
org-mode), like the following:
  – this is a list item;
  – this is another one, but very very very long so that it will be
    interesting to refill if ever you insert something at some line of
    it non-being the last;
  — this is a last list item.

A more complex case is for programming: there you may not use a such
feature, or have something complicated use it that you would configure
such as, for instance, in C-like, to go fill until next “;”.

At a time in human texts I used alineas (represented by indentation at
the beginning of a line) inside paragraphs, themselves separated by an
horizontal space (empty line most of time), but as nothing supports it I
stopped and began using only one alinea at a time, without indentation,
even in french, so to let clients display as they wished.

Except these cases, I don’t see any other border cases.  Maybe there
are, but just the org-mode/TeX/fill-paragraph things would be
appreciable enough, as I feel many people could constrain themselves to
it (after all it is how software might treat it to later render,
convert, translate, or export it).

If ever we were to consider these cases, these would be, I find, pretty
equally well to consider for making compatible with the already existing
and assuming `fill-paragraph', so it wouldn’t require anymore (like it
happens to me sometimes) to insert empty lines (and afterwards removing
them) here and there to use it.