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

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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?

Answer 4

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 :).

Answer 5

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!

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

I switched from Latexian to TeXlipse and had a problem with compiling my old documents that had been soft wrapped in Latextian. The auto compiling feature in the background on Latextian was nice when you finished a line it would show in the preview. I had trouble figuring out what was causing the problem compiling the old documents in TeXlipse. I had to manually edit the old documents to remove whatever Latextian had put into the line to wrap the text. I was not able to copy and paste the documents over.

TeXlipse allows soft wrapping but it is not the default and it says that it is experimental. I'm using the auto hard wrapping now, but it does create an extra step when editing a paragraph. You select the lines that are incorrectly wrapped and select "correct line wrap" or Esc-Q. It fixes it. I'm a fan of the TeXlipse now with skim as the viewer, although there are still some little bugs.

Answer 11

To add just one other thing to what has already been mentioned (and I find it quite interesting no one else has said it before):

I prefer short lines for debugging purposes.
In most cases, my texts come from XML that has been created in the author mode of some XML editor. This in most cases leads to lines with well over 5000 characters; if this gets transformed 1:1 and I get a TeX line with several thousand characters and many calls to the same command (e.g., footnotes), it is a really hard and frustrating job to find the exact place of your current problem and keep an eye on its surroundings at the same time.
Short lines make this a lot easier as the error will give a more precise location.

Answer 12

After testing out most of the editors for a while, the two I like best are Atom and Emacs. Emacs is the one I use. If there is something in another editor I like, I can easily add the feature or theme to Emacs. Emacs has a lot of documentation and once you get used to it, the other editors seem to pale in comparison. It does take a while to customize and get used to though. If you are not into that then Atom is good, because it can be made similar to Emacs in many ways, and the interface is a bit slicker on initial install. There are sometimes little bugs in how the Emacs interface works. If they could somehow combine the Atom interface with the Emacs, that would be awesome.

Emacs comes as a shell that you have to setup according to your needs and tastes. You can integrate R and Latex with code completion easily in both. There is also Intellij Idea community edition with various builds for various purposes. I tested that out. It has good completion and some good plugins, but more difficult to customize the themes and for other coding languages, it can be pricey for someone on a tight budget unless you are doing java development it seems. I'm happy with Emacs. As far as the wrapping, I tend to prefer the Visual Line Mode word wrap in Emacs for most stuff when writing text. You can Trunkate the long lines later if you need to. It makes it easier to read the changes when you send it to the version control.