Vim, LaTeX, word-wrapping, and version control

Question

I'm writing a LaTeX document in vim, and I have it hard wrapping at 80 characters to make reading easier. However, this causes problems with tracking changes with in version control. For example, inserting "Lorem ipsum" at the beginning of this text:

1 Dolor sit amet, consectetur adipiscing elit. Phasellus bibendum lobortis lectus
2 quis porta. Aenean vestibulum magna vel purus laoreet at molestie massa
3 suscipit. Vestibulum vestibulum, mauris nec convallis ultrices, tellus sapien
4 ullamcorper elit, dignissim consectetur justo tellus et nunc. 

results in:

1 Lorum ipsum dolor sit amet, consectetur adipiscing elit. Phasellus bibendum
2 lobortis lectus quis porta. Aenean vestibulum magna vel purus laoreet at
3 molestie massa suscipit. Vestibulum vestibulum, mauris nec convallis ultrices,
4 tellus sapien ullamcorper elit, dignissim consectetur justo tellus et nunc.

When I review this change in git, it tells me that all the lines of the paragraph have changed because of the wrapping, even though only one semantic change has occurred. One way around this problem is to have every sentence on its own line. This looks the same in the rendered document, but the source now is harder to read, because each line has quite a different line length:

1 Lorum ipsum dolor sit amet, consectetur adipiscing elit.
2 Phasellus bibendum lobortis lectus quis porta.
3 Aenean vestibulum magna vel purus laoreet at molestie massa suscipit.
4 Vestibulum vestibulum, mauris nec convallis ultrices, tellus sapien ullamcorper elit, dignissim consectetur justo tellus et nunc.

(If I soft wrap at 80, things still look bad, just in a different way.)

Is it possible to have my text on disk with one newline per sentence, but display and edit it in vim as if the text of each paragraph was one long line, soft wrapped at 80 characters? I assume it requires some vim-foo rather than tweaking git or LaTeX.

Answer 1

No need to introduce weird editing policies: the git feature you are looking for is using git diff --color-words to review changes.

Answer 2

I think an alternative way is to change the width of the vim window like what I did usually:

1. at first, put "set wrap" in the .vimrc to enable the "wrap" feature;

2. For running vim in a virtual terminal, I always set the terminal's window width as 80 characters (like "urxvt -geometry 80x38"). Thus, anytime I edit a file in vim in the virtual terminal, it will automatically wrap when a line contains more than 80 characters.

3. If you prefer the gvim (gtk-vim, gnome-vim), you can just set the size of the gvim window by adding a line in .gvimrc, like "set lines=38 columns=80".

Hope that helps. :-)

Answer 3

I've been wondering about things like this myself, and in the end I just had to try a few different approaches to see what works. One thing I'm definitely not happy with is hard breaks (which can be acheived by set textwidth=80), for several reasons:

• Whenever I go back to edit previous text the hard linebreak will be on the wrong place. It will either go beyond my 80 character limit, or it will be too far from my 80 character limit. Sure, I can fix this in Vim by using different variants of the gq operator (e.g. gqip, gqap, visual mode and then gq), but this is tedious, and I often miss my target area with gq. This is for me the biggest disadvantage with hard breaks. (If you do use gq to fix paragraphs you may want to use set nojoinspace to avoid getting annoying double spaces after every period.)
• I often have Vim and the PDF open side-by-side. Whenever I want to edit something at a specific place in my PDF I just search for fragments of the text. You'd be surprised at how few places in a text you use two rather common words in a particular order, so this really works quite well. Unless you have hard breaks in the middle of the sentece that breaks between the words you're searching for. This delays my workflow rather frequently when using hard breaks.
• I often navigate within senteces using f, F, t or T. This only works within the same line.
• There's also the problem mentioned by the OP that Git doesn't handle hard breaked paragraphs very well. Sure, you can make the diff look nice nevertheless, so it's not really a big problem.

For me, using soft breaks (and having for instance one sentence or paragraph per line) is not a "weird editing policy" I adopt to suit Git. It's a (perhaps weird) editing policy I use to facilitate convenience and efficiency while editing. In particular the soft line breaks occuring in the middle of words I agree look ugly, but that can be turned off using set linebreak.

If, in addition, you use one paragraph per line, you should get about the same "look" as with hard breaks (which is properly maintained with gq), and you can navigate from sentence to sentence with ( and ). With one sentence per line you will get a more ragged right edge, but with the advantages Git and Vim offers by having one sentence per line. Try both and see what you prefer (I haven't decided yet myself).

Answer 4

This is how I solve the problem. First you may use vim command (in normal status) to search your tex file for the lines longer than 80 chars:

/\%81v.\+/

you may define it as a macro so as not to remember the commands. Then you type in the normal status

nF a

(that is, a little "n", a capital "F", a space " ", a little "a", an "Enter", and an ). This help you break your line softly after some word. You may record this five key strokes as a macro (howto: in normal status press "qa" to start recording and just do the steps "nF a" and then press Esc and "q" to stop. When playing, press "@a" because we have stored the macro into "a". To play the macro 100 times (it does not hurt if you play it too many times; it just automatically stops when finishing all the job) by pressing "100@a" in normal status)

Does this solve your problem?