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

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

[Garreau, Alexandre]

Hi,

Keeping seeing differently column-filled messages, and noticing
sometimes this occupy too few columns and too much lines while it is
inferior to 66 (the optimum, I read somewhere (some LaTeX doc I
believe)), I’d like to see text filled differently.

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.

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?

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.  Maybe while filling
at fill-column behind the scenes.  So I stop hitting M-q
(`fill-paragraph') repetedly while word-wrap is on (isn’t this what
word-wrap is supposed to stop?) to make text readable.

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

[Eli Zaretskii]

> 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?

> 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?

> 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.

Right, see above.

> 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.

> 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.

Patches are welcome to implement any of these useful features.

Thanks.

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

[Stefan Monnier]

> 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).

> 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.
[ 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.  ]

> 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.  Maybe while filling
> at fill-column behind the scenes.  So I stop hitting M-q
> (`fill-paragraph') repetedly while word-wrap is on (isn’t this what
> word-wrap is supposed to stop?) to make text readable.

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

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.

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).

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".


        Stefan

detect sentence/paragraph ending (was: refill paragraph but visually (like visual-line-mode)?)

[Van L]

> 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).

Can Deep Learning and Machine Learning be leveraged to automatically detect 99.999% cases based on crowd sourced examples and deciders collected in test/lisp/progmodes, test/lisp/textmodes?

Those files will have templates like Org Mode’s example and result block which people append to as they come across an OddOne™ which then feed into DL, ML to produce the necessary regexp (and rx) expressions.

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

[Stefan Monnier]

> 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".

I just pushed a visual-fill-mode to GNU ELPA which tries to do
just that.


        Stefan

Re: detect sentence/paragraph ending (was: refill paragraph but visually (like visual-line-mode)?)

[Emanuel Berg]

Van L wrote:

> Can Deep Learning and Machine Learning be
> leveraged to automatically detect 99.999%
> cases based on crowd sourced examples and
> deciders collected in test/lisp/progmodes,
> test/lisp/textmodes?

Sure - get a Git repository and start coding :)

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: detect sentence/paragraph ending (was: refill paragraph but visually (like visual-line-mode)?)

[tomas]

[-- Attachment #1: Type: text/plain, Size: 621 bytes --]

On Tue, Oct 16, 2018 at 11:51:12AM +0200, Emanuel Berg wrote:
> Van L wrote:
> 
> > Can Deep Learning and Machine Learning be
> > leveraged to automatically detect 99.999%
> > cases based on crowd sourced examples and
> > deciders collected in test/lisp/progmodes,
> > test/lisp/textmodes?
> 
> Sure - get a Git repository and start coding :)

If you want to have a ton of fun (and lots, *lots* of preconditioned
data), look here:

  http://www.conceptnet.io/
  http://blog.conceptnet.io/

An Emacs interface to the ConceptNet web service would be huge.
Perhaps there /is/ one already?

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: detect sentence/paragraph ending (was: refill paragraph but visually (like visual-line-mode)?)

[Emanuel Berg]

tomas wrote:

> An Emacs interface to the ConceptNet web
> service would be huge.

No kidding :)

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: detect sentence/paragraph ending (was: refill paragraph but visually (like visual-line-mode)?)

[Van L]

>> An Emacs interface to the ConceptNet web
>> service would be huge.
> 
> No kidding :)

Super. And, thanks.

I will add this a list I picked up
from Jensen Huang’s keynote in EU
within the last week for the 
foundation of ML since 2006:

	• hadoop
	• numpy
	• scikit-learn
	• pandas
	• dask (2016)
	• arrow (2016)
	• spark
	• rapids (2018)

Huge isn’t greater than 400GB dataframe
stretching 16 years for all customer
mortgages belonging to a big business?

I was struck by the idea of games with 
a purpose. Assassin’s Creed Odyssey and
Thucydides’ Peloponnesian War is meaningful
to the region ULA is about to launch a
satellite over in a day or two for relaying
high priority messages. The players have
come within 14m of each other out in the 
shallow sea. That might’ve been the second 
time lucky.

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.

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

[Garreau, Alexandre]

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.

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

[Garreau, Alexandre]

On 2018-10-15 at 22:36, Stefan Monnier wrote:
>> 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".
> 
> I just pushed a visual-fill-mode to GNU ELPA which tries to do just
> that.

Mmmmh, wow I like it much: it automagically takes care of prefixes, and
plays very well with adaptive-wrap and visual-line (though having
continuation marks in fringes about when a line would have been splitted
by word-wrap without visual-fill would have been interesting but maybe
too complex to be worth it) modes …and gets amusing behavior with
highlight-current-line-minor-mode: first of all it highlight prefixes
when they really are in buffer but not when these are inserted by a
mode, and second you see hard lines highlighted instead of visual ones
so you see the difference between both… if you fill-paragraph that
usually plays well except in some cases (I guess because of
word-wrapping).

The two only current drawback is, first of all, when you insert a
newline, it is not hidden, and then that it garbles with message-mode
headers, whose newlines are (exceptionally) of semantic relevance (but
maybe someone could like it as well): maybe something specific to each
mode should specify where newlines (or something else) might be of
semantical relevance.

Damn, this mode makes me enthusiast of word-wrap, maybe even hoping for
hyphenation or advanced high-level things like that I wouldn’t ever have
expected in emacs before.

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

[Joost Kremers]

On Wed, Oct 17, 2018 at 12:54:42PM +0200, Garreau, Alexandre wrote:
> On 2018-10-15 at 18:21, Eli Zaretskii wrote:
> > 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?

No, it does something very different to achieve basically the same effect. It simply widens the margins, which aren't used to display text, so the text area is reduced.

Doing this in the line-wrapping code (i.e., make the wrap coordinate controllable by the user) might be the better way to implement it, because it should theoretically become possible to exclude certain parts of the buffer from wrapping, i.e., tables or source blocks in Org files. (I've had this request for visual-fill-column-mode once or twice, but it's simply not possible.)

But if the line-wrapping code is already devilishly complicated, as Eli says, it's probably unlikely to happen...

-- 
Joost Kremers
Life has its moments

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

[Eli Zaretskii]

> From: "Garreau\, Alexandre" <galex-713@galex-713.eu>
> Cc: help-gnu-emacs@gnu.org
> Date: Wed, 17 Oct 2018 12:54:42 +0200
> 
> > 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?

No, far from it.  visual-fill-column-mode sets the window's display
margins, it doesn't change anything in the display code.

> >> 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.

As I tried to explain above, this kind of algorithm is usually a
non-starter in the display engine.

> > 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?

No need to submit patches for something visual-fill-column-mode
already does well enough.

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

[Eli Zaretskii]

> Date: Wed, 17 Oct 2018 17:52:20 +0200
> From: Joost Kremers <joostkremers@fastmail.fm>
> Cc: Eli Zaretskii <eliz@gnu.org>, help-gnu-emacs@gnu.org
> 
> But if the line-wrapping code is already devilishly complicated, as Eli says, it's probably unlikely to happen...

I also said that this particular change could be not so hard.  One has
to try to know, maybe we are lucky.

And, as long as I'm around, I can help people understand that code.

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

[Garreau, Alexandre]

On 2018-10-17 at 19:00, Eli Zaretskii wrote:
>> From: "Garreau\, Alexandre" <galex-713@galex-713.eu>
>> Cc: help-gnu-emacs@gnu.org
>> Date: Wed, 17 Oct 2018 12:54:42 +0200
>> > 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.
>
> As I tried to explain above, this kind of algorithm is usually a
> non-starter in the display engine.

Maybe I misexplained what I meant: keep the code as now, don’t re-fill
the lines, don’t display indentation without storing it somewhere, just
support too-long lines.  So “first line” (of paragraph) should begins
after the last “;” for instance, or anything that is indeed a newline in
the file (that should exist).

I wasn’t speaking about indenting everything without even a newline.

So I’m *not* proposing to refill, wrap and indent something such as
" inst;if (expr) inst;\ninst;inst;" to, without changing to-be-saved
content, display as "  inst;\n  if (expr)\n    inst;\n  inst;".

I’m proposing to wrap and indent (without refilling) something such as

#+BEGIN_SRC c
  inst(that, should, be, wrapped); inst;
  if ((long) expression(that, should, also, be, wrapped))
    other(very, very, verylong, instruction);
  inst(verylong, verylong, instruction);
#+END_SRC

be *wrapped* like (given very low `fill-column', so to better give an
example):

#+BEGIN_SRC c
  inst(that, should, 
       be, wrapped); inst;
  if ((long) 
      expression(that, 
                 should, 
                 also, 
                 be, 
                 wrapped))
    other(very, very, 
          verylong, 
          instruction);
  inst(verylong, verylong, 
       instruction);
#+END_SRC
 
There is still a newline in file being hardcoded, plus an hardcoded
indentation following it: couldn’t it be used for indenting?

It could even stay partially wrong by just taking the same indentation
as it should just after the first line, so it would give:

#+BEGIN_SRC c
  inst(that, should, 
       be, wrapped);
  if ((long) 
      expression(that, 
      should, 
      also, 
      be, 
      wrapped))
    other(very, very, 
          verylong, 
          instruction);
  inst(verylong, verylong, 
       instruction);
#+END_SRC

Hence in “most of cases” it would be okay.  The important is not to
“break” indentation by wrapping so that the wraped portion of text will
“cut” the indented block.  More radically, even the following would be
more acceptable than the default:

#+BEGIN_SRC c
  inst(that, should, 
  be, wrapped);
  if ((long) 
  expression(that, 
  should, 
  also, 
  be, 
  wrapped))
    other(very, very, 
    verylong, 
    instruction);
  inst(verylong, verylong, 
  instruction);
#+END_SRC

And I tried: turns out it *already works out of the box* by just
enabling adaptive-wrap-prefix-mode.  So my initial question is more than
half-answered now.

Because it is still better as the (current default):

#+BEGIN_SRC c
  inst(that, should,
be, wrapped);
  if ((long) 
expression(that, 
should, also, be, 
wrapped))
    other(very, very, 
verylong,
instruction);
  inst(verylong,
verylong,
instruction);
#+END_SRC

…where indentation becomes pretty useless only because someone used long
lines.

Okay with the standard 72 columns that’s going to never happens, but
just in case it happens, it is *really* nice to get it work by default.
Now I realize I mostly regret for adaptive-wrap-prefix-mode not to be
the default for wrapping (what drawbacks does it have?).

> No need to submit patches for something visual-fill-column-mode
> already does well enough.

So what where you talking about patches?

PS: sorry for lengthiness but I hope this is all because of examples and
that they are fast to get a glance at.

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

[Eli Zaretskii]

> From: "Garreau\, Alexandre" <galex-713@galex-713.eu>
> Cc: help-gnu-emacs@gnu.org
> Date: Wed, 17 Oct 2018 22:53:40 +0200
> 
> > No need to submit patches for something visual-fill-column-mode
> > already does well enough.
> 
> So what where you talking about patches?

I thought you were talking about changing the display code that
implements word-wrap (a.k.a. "visual-line-mode").  It turns out you
weren't, so just ignore me.