What are the pros and cons of using hard wrapping, and why is it so common with LaTeX?

It seems that hard-wrapping - i.e. inserting a newline when the line reaches a certain threshold - is extremely common in the LaTeX source when writing technical papers, either by manually inserting it or by letting the text editor take care of it.

After years of writing text in soft-wrapping environment (text is displayed wrapped, but no newline is actually inserted), I find it hard to understand why hard-wrapping is so commonly used. I think understanding the reason(s) behind it will make me less resentful about using it.

What are the disadvantages and advantages of using hard-wrap vs. soft-wrap, and why is hard-wrap so commonly used with LaTeX?

-

Many text-comparing tools like diff use line-by-line comparison. This can be explained by their origin as programmers' tools. When lines are short enough, these tools work well with TeX sources - especially when combined with version control systems. Of course, there are tools like latexdiff (highly recommended!), which do not take into account line lengths.

Also, since TeX comments start from % and continue to the end of line, short lines make easier to comment the code.

Last but not least, many TeX authors use programmers' editors like Emacs or vi, which use hard line wrapping. This makes the code more readable - and TeX source is primarily a code.

Anyway, TeX itself, of course, does not care about your line length.

-
Im Vim (and I'm pretty sure in Emacs, as well) you can select, if you want soft or hard wrapping. The editors support both. –  Marco May 2 '12 at 21:12
Yes, it's also true for emacs. –  jon May 2 '12 at 21:19
I meant the default settings. Of course any good editor allows to change them to almost anything –  Boris May 2 '12 at 21:45
Plus, of course, most VCSs store their changesets as line diffs, which, for a big project, could make a difference in space, and possibly time. –  Brent.Longborough May 2 '12 at 23:38
Wow, I didn't know about latexdiff. Seems like a much-needed tool. It should be said, however, that version management is the main reason for me to use hard wrapping and there you probably can't just get rid of line-based diffs (altheugh latexdiff does support svn post-hoc as it seems). –  Christian May 3 '12 at 7:04

There are no pros of hard-wrapping and no cons of soft-wrapping. It's just habit that makes us hard-wrap, that and not knowing about M-x longline-mode. TeX doesn't care about single newline characters[1], treating them as normal spaces. So as far as the document is concerned, there's no argument for one over the other.

But wrapping is useful for us, the authors. Suppose we stuck to using
double-newlines for paragraphs (thus in practice avoiding the input-buffer issue). A typical paragraph goes over 80 characters (a usual
width of screen for editors) and thus either disappears off the end (not very helpful) or the editor wraps it. The editor can hard-wrap or soft-wrap it. If
it hard-wraps (ie inserts literal newline characters) then there's a problem with editing the paragraph later: one generally wants the paragraph to reflow on editing otherwise it ends up looking
awful.
But reflowing a TeX document is quite an art. A real danger is reflowing comments: if a line ends in a comment %something like this one
then it is extremely important that the wrapping not remove that newline. A situation less drastic for TeX but highly irritating for an author is wrapping environments and certain other commands. It's quite useful to be able to easily see where an \item starts, for example, and this is easier if it is at the start of a line (possibly indented) than somewhere in the middle.

Several others have also mentioned diff. This is another case where one wants to be able to control the newlines carefully. If I have a paragraph that is hard-wrapped to 80 columns (or 72 or whatever) and I change one small bit at the start, and then reflow the text, that might change every line in that paragraph. Running diff on the resulting file will produce every line as having changed but all I really want to know is the change at the start. So in the file you really do want to have some newlines, but this is really the main reason for having newlines in the file so the newlines in the file should be chosen in such a way that they answer the question "When I run diff on this file and there's a change here, what extra information do I want to see?". For me, that's usually just the sentence that the change is in so I put a newline after every sentence. I tend also to separate out large chunks of inline maths as well and a few other things.

So what one wants is a system whereby it is possible to specify certain newlines as immutable and others as flowable. A fair amount of the immutable newlines can be predicted (comments, certain commands) but a useful system will make it easy for an author to specify them as they go along. Emacs does this with its longline-mode. Author-inserted newlines are respected, auto-inserted newlines are not. Best of both worlds. Any respectable editor will have similar functionality. If not, your editor is forcing you to adapt to its idiosyncrasies whereas it should be the other way around.

(I encountered this first when I switched to using a VCS. I wrote up my experiences on my website.)

[1] There are three cases that I know of where newlines matter:

1. A newline marks the end of a comment
2. It is possible to force TeX to interpret newlines as \par tokens, the verbatim environment does this as does \obeylines.
3. If everything were on one line then as TeX reads the document a line at a time it may be possible to overwhelm the input buffer.
-
Well a buffer overflow used to be the indication of wrong line endings when transferring files between systems (I think the TeX executable will accept all combinations of CR/LF nowadays). So it isn't really a fringe case that the buffer overflows if everything is on one line. Furthermore, in the XML world, a lot of producers don't see a point in inserting line feeds anywhere, so those XML files will be inaccessible for direct parsing with TeX. –  Stephan Lehmke May 3 '12 at 9:42

Another answer is that TeX has a fixed maximum size of input lines, that is, if a non-wrapped line exceeds a certain length, there will be an error message.

This limit is quite large nowadays. You'll find it in your texmf.cnf:

buf_size = 200000


But it used to be smaller in the past, and anyway, who wants to think about something like this while writing text?

-

I study computer science, therefore my answer is strongly biased. Anyway, it is considered good practice keeping 80 cols as maximum width. The reason is quite funny as well, it is related to the dimension of the punched cards used in the old days.

Hard wrapping makes the code nice and tidy, as there are some editors that do not wrap lines when you open a new file.

Bottom line, the code works, no matter how you decide to format it, anyways, good indentation and good wrapping make it more readable by most of users. Please do take it as a habit :).

-
Actually, I prefer 71, with 72 as the continuation column and 73-80 for sequence numbers, in case I drop the file... (;-P) –  Brent.Longborough May 2 '12 at 23:39
I don't know if goes back further, but 80-characters is the default width of a terminal window, which is why a lot of people stick with that are the max size. –  Brendan Long May 3 '12 at 2:16
@Bret. yes, it has become a standard, but as many things in computer science, there are funny historical reasons, think about "bug" :). –  Edo May 3 '12 at 6:21
For those who didn't know, it's the size of an (IBM) punched card. –  Brent.Longborough May 3 '12 at 8:43
The 72 columns have another typographical justification. Very long lines makes it harder to scan a line visually and then jump back to the beginning of the next line. Most text columns designed for long reading are designed for a width of about 2.5 to 3 alphabets, that is, about 26*2.5=65 to 26*3=78 characters wide. –  Christian Lindig May 3 '12 at 11:45

The answers so far (maybe with the exception of Andrew's – dialectical as always) have argued for the pros of hard line breaks. So let me add a somewhat different viewpoint:

(1) As a community, we do care a lot about semantical markup: We leave the actual formatting of our document's text to a post-processor (e.g., pdflatex), which does a fairly good job in breaking it into lines depending on the selected fonts, paper format, etc. We alter the actual typesetting only if there is a semantic (\emph{semantic}) cause for this. This includes manual line breaks within a paragraph with \\ or \newline; we insert them because they carry semantics.

(2) Only in a very few exceptions (for instance for typesetting code), we seek for full control. In these cases we use environments like verbatim to have LaTeX obey every whitespace and line break – because for code, every whitespace and line break carries semantics.

In my opinion, the very same principles should be applied for the formatting of the document source code! Hard line breaks should be inserted when there is a semantic reason to do so. This clearly is the case for those parts of the document that are like (2), that is, real code (in the sense of a programming language): The preamble, macro definitions, etc. This certainly also holds for the source code of packages and classes.

However, the majority of an ordinary LaTeX document (such as a book or a thesis) is about textual content, which maps to (1). Consequently, the editor should do the line breaking depending on the screen size, font size, font metrics and preferences of the human being in front of the computer. This is especially important in a collaborative setting: Why should I be forced to an artificial limit to 80 chars on my 30" screen, just because my colleague prefers this line lengths and has inserted a "semantics-free" hard line break after each line? Let everybody configure his editor as she wants!

This brings us to the question of tools: Technically and principally speaking, the "break after 80 chars" rule is archaic at best. It has a historical background (fixed width of terminal windows, line printers, etc.) and since ever than has survived as the default in many tools as nobody seems to question it. However, there are alternatives. If diff only works line-based (as it has been intended for C source code) use a word-wise diff tool. (The diff&merge tool included in TortoiseSVN, for instance, is pretty good at this.) If your editor does not support indentation of soft-wrapped lines, get a better editor! (AFAIK, Emacs supports this and for VIM there is a patch available that I have been using happily for quite a while now.)

A final thought: Most LaTeX users seem to understand a LaTeX document as "source code" (in the sense of a programming language, like C); hence, they apply formatting rules and tools intended for C programs to it. However more than 90% of a typical LaTeX document is not really "code", but "content". So apply the rules of semantic markup!

-
My only issue is that with a diff on a TeX document then I don't want "word-wise" diffs. I want context about the change, and normally that means I'd want the whole sentence in which the change was made. (Maybe that's possible with what you mention, but if so please make it clearer.) –  Loop Space May 3 '12 at 9:27
@AndrewStacey: The word-wise diff tools I am aware of typically mark every changed line (e.g. by a light red background) and than within that line the actually changed words (e.g., by a dark red background.). So the context is always there. –  Daniel May 3 '12 at 9:58
The "break after 80 chars" leads to more readable lines as well. I think you'd be hard-pressed to effectively edit text that was 30 inches wide. :) –  Reid May 7 '12 at 17:44
@ReidPriedhorsky: This is an opinion I often hear, but do not really understand: Just configure your editor to soft-wrap after at most 80 columns and there you are. The length of physical lines should depend on the content, screen lines can be configured to whatever you prefer (given a half-decent editor, of course). –  Daniel May 7 '12 at 18:53

I want my editor to display code in an indented manner as I like it. For example:

\starttext
\startsection
Some text in a section that might continue for
multiple lines
\startitemize
\item The first item which if spread over multiple lines
should indent nicely
\stopitemize

Next paragraph with proper indentation
\stopsection
\stoptext


In vim, and I think that other editors behave the same, it is easy to control how hard wrapping behaves. For example, in a regular environment I want the hard wrapped line to start from the same distance the line above it, unless the line above it happens to be \start<...> or \stop<...> or \item. On the other hand, it is not possible to control how soft wrapping is indented. This for me is the biggest reason to prefer hard wrapping to soft wrapping.

-

I insert a new line after each full stop and after each comma. One reason are tools like diff and git or subversion, but mainly I do it because the forward-inverse-search with synctex works exact to one line.

-
I do this too because I version controlled all of my documents with Bazaar. –  Dom May 8 '12 at 20:07

I find it much easier to edit text when the lines reflect the logical structure than when it is a uniform, free-flowing mass of words:

I find it much easier to edit text
when the lines reflect the logical structure
than when it is a uniform, free-flowing mass of words.


If you want to cut out or move a sentence or a part of a sentence, it is easier both to find it and to mark it if it is its own line.

Reading is a different thing, but I don't think that the best format to write and edit text must necessarily be the same as the best format to read it.

-

Hard wrapping is one of the most powerfull features of the TeX language. It allows you to concentrate on the structure of your document, leaving the rest (typography) for another phase.

Very good practice is to hard-wrap after every full stop, and after commas when the line gets too wide. I'm used to indent the second and following line of a sentence by one space so that I clearly see where the sentence begins, and it makes much easier to re-structure your document as well as to find a sentence you wish to re-word. This all is impossible for WYSIWYG editors or with languages where endline is active.

As well, soft-wrapping brings some complications with sending codes by e-mail, posting the code here on TeX.SE etc.

-