The problem of wrapping
Starting from July 2016, I use Vim to edit my past writings. When editing human-readable text, rather than computer code, text wrapping can be a problem in Vim, because Vim isn’t intended to show long lines.
There are two choices of wrapping, both having their problems. For convenience, I say that a physical line is a line delimited by newline characters, and that an apparent line is a line displayed as in the current window. And I say that a text file is softly-wrapped if physical lines are allowed to be longer than current window width, and that a text file is hard-wrapped if every physical line is broken to agree with apparent lines. In other words, soft wrapping keeps the paragraph intact, and hard wrapping inserts newlines to format it on the screen. Which will you use when writing prose, soft or hard wrapping?
Soft wrapping
Supporters of soft wrapping hold that the source should be easy to read, which is the original mindset of Markdown. If Markdown source visually resembles the output, we no longer need to see compiled pdf on the facing side when working on it, like when we use TeXstudio to edit LaTeX sources. Besides, hard wrapping isn’t something that laypersons spontaneously do, and thus it makes no semantic sense.
Now, the irritation is that the remaining space in the current window isn’t enough for the next physical line. If so, the next line isn’t shown, and the remaining space is wasted. A partial workaround is to toggle between displaying part of the next line as much as possible:
noremap <silent> <leader>\ :call ToggleDisplayLastLine(
And we define ToggleDisplayLastLine() as thus:
function! ToggleDisplayLastLine()
if (&display=='')
let &display='truncate'
else
let &display=''
endif
endfunction
Still, scrolling is awkward. Especially, as I scroll a whole frame ( <ctrl>f and <ctrl>b ), Vim reserves 2 lines, repeated both in the previous and the present frame. To stop it from reserving lines, I have mapped as thus:
nnoremap <c-f> <c-f><
nnoremap <c-b> <c-b><
Moreover, the line numbering can be problematic too. Line numbers are crucial in navigating in Vim, but it is really twice the paragraph number, and such information isn’t helpful. Ironically, in Microsoft Word, apparent line numbers may be shown. In Microsoft Word or TextEdit for example, this need not be the case, but sometimes the first apparent line in the new frame may start from anywhere in the previous paragraph.
These solutions aren’t ideal in the presence of long paragraphs, but long paragraphs shouldn’t be the norm either, I will probably write paragraph as long as this very seldom (Unless I wish to write a continuation of «In Search of Lost Time», or of the last chapter of «Ulysses»).
Hard wrapping
Instead, many Vim users are inclined to hard wrap. Supporters might maintain that it isn’t the source that matters, but the output. And so we are free to manipulate the source to facilitate editing.
In Vim, newlines may be inserted automatically with (say):
set textwidth=74
See formatoptions in the help for relevant settings. The default is tcq, meaning respectively automatic wrapping, wrapping code comments, and allowing formatting of comments.
Unfortunately, when I rearrange material, the physical lines become uneven, making it hard to count the words in the present paragraph.
To make lines even, there is an automatically reformatting command gqap, but it only applies to the current paragraph. While we may define a shortcut, reformatting when typing can be a distraction.
More problematically, automatic reformatting doesn’t work for Chinese characters, or I don’t know how to do that in Vimscript. Besides, what if I want to copy and paste the hard-wrapped prose into somewhere else, like WordPress or Facebook?
Someone recommends: :%norm vipJ, but the result isn’t reliable. Indented code blocks sometimes get merged with preceding and following paragraphs, even if delimited with a blank line, and shorter paragraphs are swallowed.
Newline sensitivity
Apart from the debate of wrapping, there seems to be some controversy on whether newlines should be rendered by Markdown compilers. In the source, some compilers render every single newline as line break, and some render only two or more newlines. I call them respectively newline-sensitive and newline-insensitive. (In comparison, LaTeX compilers are always newline-insensitive.) Thus there are 4 cases, and only when the text is hard wrapped, and the compiler is newline-sensitive, do we get incorrect results.
Actually, Gruber’s original specification didn’t resolve the parsing issue unambiguously; such a mess motivated CommonMark, an attempt to standardize Markdown. Nevertheless, GitHub, Pandoc, Stack Overflow, and CommonMark Spec are all newline-insensitive. The Wikipedia interpreter, though different from Markdown, is also newline-insensitive. In contrast, WordPress is newline-sensitive. There is also a debate on Meta Stack Exchange about this, and it seems newline-insensitiveness is the consensus.
Halway wrapping
A compromise is always breaking at every end of sentence; I call this halfway wrapping. This way, every physical line is a meaningful entity, and it makes sense to go up, go down, cut, or paste an entire line. Again, newlines can be removed by J.
Halfway wrapping also produces uneven apparent lines, making it hard to count words, but it is better than soft wrapping.
After a long contemplation on the matter, I think halfway wrapping really is the way to go. I will always halfway-wrap TeX and Markdown sources.
However, to me the best scenario is that Markdown be universally newline-insensitive, and that Vim show apparent line numbers, rather than physical line numbers, and that we always soft-wrap. Though understandably Vim is a line editor, I hope a future version will include this feature. To cater both code-writers and prose-writers, there can even be a setting that toggles line number style between them.
❧ January 21, 2017; shortened and rewritten July 29, 2021