Word wrap for side by side by word rather than by character

[ayroblu]

Hey! This relates to #515. It would be great as a minor improvement, perhaps behind a flag to do word wrapping rather than character wrapping on the side to side view.
Example:

I think word wrapping uses " " character normally, not sure how it handles different languages

[dandavison]

Hi @ayroblu, thanks! I agree, this would be great to have. cc @th1000s -- I think you've already thought about this. Do you have a sense for how hard it's going to be?

[th1000s]

I agree, that is still sorely missing from the wrapping logic.

And this could do a bit more than finding the first transition towards a space (\w in a regex, probably via UnicodeSegmentation::split_word_bounds). Plus there must be some limit on the amount of characters which will be moved to the next line.

When the break is in a non-word region it sometimes makes sense to walk backwards beyond the previous word, and maybe beyond. A few examples and alternatives I could think of, where | is the end of the line and ¦ the improved wrap position:

foo ¦ba|r
foo¦ ba|r

some foo:¦|:bar
some foo¦:|:bar

some foo::¦|bar
some foo:¦:|bar
some ¦foo::|bar

knsh14/vim-¦g|ithub
knsh14/¦vim-g|ithub

bar<this<that>¦|>()
bar<this<that¦>|>()

bar<this<¦th|at>()
bar<this¦<th|at>()
bar¦<this<th|at>()

"some string"¦)|)

"some quoted ¦text|"

some "ab ¦b|c" text
some ¦"ab b|c" text

foo::bar::baz(¦|)
foo::bar::baz¦(|)
foo::bar:¦:baz(|)

some( foo::¦b|ar )
some( ¦foo::b|ar )

too_long_to_be_wra¦|pped
too_long_to_be_¦wra|pped

doThisAndThatAfterSometh¦|ing
doThisAndThatAfter¦Someth|ing

fn foo() -¦|> usize {
fn foo() ¦-|> usize {

------<-[+¦|]->
------¦<-[+|]->

How should the remaining room on the line be filled? Just spaces can't be used, so a placeholder is required (here: ·), or the wrap character should move to the end of the line, and if so, follow up with spaces or placeholders?

this was···↴|
   …wrapped!|

this was↴   |
   …wrapped!|

this was↴···|
   …wrapped!|

I currently prefer the first option to reduce visual noise. And someone once said "perfect is the enemy of good " - but still... :)

CC @StaticPH @disrupted @pwm @ri-aje @zifeo @jupblb @chalkygames123 @Notgnoshi @serban

[dandavison]

I agree that the first option looks nice. Just to make sure I understand, the reason you say "just spaces can't be used" is that we want to distinguish user content from artificial injected content, right?

Is another option to use … multiple times?

this was………↴|
   …wrapped!|

[th1000s]

Yes, visually it should be clear what delta inserted and what the content itself is. ↴ … · etc. are colored differently from the code (unless the syntax highlighting does something unlucky), but spaces can't really be colored.

I first tried … as well, but found it visually too "heavy", especially if repeated. But this will be configurable.

[dandavison]

this wasXXX↴|
   Ywrapped!|

It does seem like the semantics of X are very close to those of Y, which would be an argument for them using the same symbol.

[ayroblu]

fwiw, imo, I think we should break on spaces and not just non word characters, I don't think that if a word has a symbol, I don't want to break it in two in many cases.
As an alternative, more complicated example, using what the browser defaults to: https://www.w3.org/TR/css-text-3/#soft-wrap-opportunity
But that's pretty complicated I think, and I'm not sure on specifics

[dandavison]

Possibly useful? https://docs.rs/unicode-linebreak/latest/unicode_linebreak/

[StaticPH]

this was···↴|
   …wrapped!|

this was↴   |
   …wrapped!|

While I believe the former will likely be preferred by most users, I'd personally be just as satisfied by either of these two.

Yes, visually it should be clear what delta inserted and what the content itself is. ↴ … · etc. are colored differently from the code (unless the syntax highlighting does something unlucky), but spaces can't really be colored.

Are whitespace characters not already being colored within differing blocks? If there's already a way to indicate the addition or removal of a segment which happens to begin/end in horizontal whitespace, I would imagine that the code for such behavior could be reused or modified to highlight (or otherwise style/format, perhaps with an underline?) everything between the position at which wrapping occurs and the wrapping marker "↴". The same could also be applied to any characters delta inserts at the start of the following screen-line, either in addition to or in place of any ellipses. Alternatively, spaces on either side of a wrap point NOT inserted as padding by delta could be made distinct.

I first tried … as well, but found it visually too "heavy", especially if repeated. But this will be configurable.

Indeed, I find that several adjacent ellipses characters can quickly become visually noisy.
……… (x3)
……………… (x6)

fwiw, imo, I think we should break on spaces and not just non word characters, I don't think that if a word has a symbol, I don't want to break it in two in many cases. As an alternative, more complicated example, using what the browser defaults to: https://www.w3.org/TR/css-text-3/#soft-wrap-opportunity But that's pretty complicated I think, and I'm not sure on specifics

I definitely think that the ideal scenario would be to break immediately before or after visible whitespace characters. At the very least, linebreaks (along with any inserted padding) for wrapping should occur immediately adjacent to non-alphanumeric symbols when possible. I suspect that "after" placement is probably the better position in most scenarios.

[Destroy666x]

Yes please. A mode where regular words are not split in the middle and long words are split in the middle would be perfect.

[jasonmcewen]

Any further thoughts or update on this? It would be super useful for diff'ing latex documents, which often have long lines of natural text.

[brtholomy]

As an author who writes exclusively in markdown, with newlines only as paragraph markers, this would be very, very nice. delta has already made the review and proofing process much nicer: thank you.

this could do a bit more than finding the first transition towards a space (\w in a regex

i'd be happy with the simplest implementation.