Soft wrap width option

[WillDHB]

When using the "wrap" option, it would be convenient to be able to specify a width (comparable to the textwidth option for hard line wrapping) rather than tying the soft wrap to the window width.

[black-puppydog]

There is quite a bit of demand for this, actually.

Over at neovim: https://github.com/neovim/neovim/issues/4386 On stackoverflow: https://stackoverflow.com/questions/989093/soft-wrap-at-80-characters-in-vim-in-window-of-arbitrary-width

I also came here after searching for a solution, and there just doesn't seem to be one, really. My use case is writing latex (i.e. text, not code) using the terminal in i3wm. I use multiple windows within vim, but each is usually >>80 chars wide, which makes text unnecessarily hard to write and navigate. Since the terminal usually fills all the screen (as in any tiling window manager) resizing the terminal is a bit uncomfortable.

[Jorenar]

Continuation of #10825

@brammool

Yes, if you can't change the Vim window width, then splitting vertically does that. You can leave the window on the right empty, then you simply have the vertical separator as the boundary. That's not really a problem, is it?

It only works if I have only one vertical window.
If I want to have two vertical windows, then I need to resize both and add third for padding. If I want to have two vertical windows and second one starting at half of the screen, I need 2 padding windows:

| <- 80 -> | <- 25 -> | <- 100 -> | <- 6 -> |
| ~~~~~    | XXXXXXXX | ~~~~~     | XXXXXXX |
| ~~~      | XXXXXXXX | ~~~       | XXXXXXX |
|          | XXXXXXXX | ~  ~~~~   | XXXXXXX |
| ~~~~~~   | XXXXXXXX |           | XXXXXXX |

And of course, every other :vnew, :resize or closing of window will ruin the layout.
Additionally, window navigation also is more annoying, since instead of <C-w>l, not it would need to be <C-w>l<C-w>l.
It also shrinks statusline and tabline, while I would like them to remain unchanged.

@arp242

Using set columns=80 works reasonably well btw, although it will be reset on a window resize. Can probably use an autocmd for it.

This solution has essentially all drawbacks of padding window, but now also requires handling that option ("also", because padding windows are unavoidable for layouts any more complex than one window).

[Jorenar]

I'll also allow myself to quote a reply from neovim/neovim#4386 by @ZyX-I:

1. This taints window navigation, also some plugins: e.g. aurum when committing by default displays diff in the biggest window adjacent to commit one, this will much likely be “wrap” window.
2. This solution shrinks status line. Also do not forget that something needs to be done to border window’s status line.
3. This solution makes some :windo commands more complex, and if one hides the presence of windows it is easy to forget to add an if.
4. This solution will hide all ~ characters, not only characters in the border window, making it impossible to see where file ends without &number or something like this.
5. This solution will hide all window borders.

[Artii4]

This feature would be really nice especially when working with TeX or markdown, where you don't want the editor to insert actual line break.

[Jorenar]

Some idea would be to have an option wrapwidth which would control at what width the wrapping would occur. Its values could have the following meaning:

• 0 - use window width
• positive number - "at that column regardless of window width"
• negative number - "at that column, unless window narrower"

[arisolt]

Bumping this, as it would make life considerably better for people using vim to write long form text (inlcuding personal wikis), because we often deal with long paragraphs and depending for soft wrapping on the dimensions of the terminal screen is not ideal.

[rickhowe]

I have found that vim post-9.0 patches and nvim 0.10.0 have a inline virtual-text feature to realize this. I tried to implement the plugin. Hope to help you.

[Shane-XB-Qian]

@rickhowe perhaps dynamically set the colorcolumn with it maybe more outstanding: e.g if &wrap && !&tw | exe 'setl colorcolumn=' .. (!get(w:, 'wrapwidth', 0) ? '' : (get(w:, 'wrapwidth', 0) + 1)) | endif but on your event and when changed the wrapidth.

[rickhowe]

@rickhowe perhaps dynamically set the colorcolumn with it maybe more outstanding: e.g if &wrap && !&tw | exe 'setl colorcolumn=' .. (!get(w:, 'wrapwidth', 0) ? '' : (get(w:, 'wrapwidth', 0) + 1)) | endif but on your event and when changed the wrapidth.

I added a b:wrapwidth_hl or g:wrapwidth_hl option on 1.1. You can specify a highlight to make virtual spaces visible.

[Shane-XB-Qian]

@rickhowe i may prefer colorcolumn, but ok if you like that alternative line hl

but looks it has some issue when reset wrap back // above case was wrap 78 on your readme.md and line 13 // that wrapped word 'screen' was flaky flied to somewhere.. :smile:

[Shane-XB-Qian]

it seems you did not trim these spaces ahead wrapped words when reset wrap/linebreak etc? // anyway, looks this a useful plugin, specially if to view, take your time, i may check later.

[rickhowe]

it seems you did not trim these spaces ahead wrapped words when reset wrap/linebreak etc? // anyway, looks this a useful plugin, specially if to view, take your time, i may check later.

Let me ask you to post it on the issue page of the plugin.