Semantic line break

From the translator:

Some time ago, a translation of an article titled "The Art of the Command Line" was published on Habré. Among other things, the article was recommended to master vim. The source code of the article, laid out on Gitkhab, ironically, turned out to be completely unsuitable for editing by this editor, since in it there was exactly one line per paragraph.

I then expressed my bewilderment to the author and asked him to align the text by 80 characters. But after a brief discussion in the comments, they gave a link to the description of the formatting of the sources of literary texts according to semantic principle. The idea embodied in this principle is generally quite simple, but I was struck by its depth, which, albeit belatedly, I want to share with others.

I want to warn you that not all links in the article are workable, but I decided to leave them as they are - you never know what.

So, article.

Semantic line break

At the annual educational program on Sphinx conducted within the framework of PyCon, I regularly give one piece of advice. A grateful listener asked where I myself learned this knowledge. I conducted archaeological research and now I have the answer to this question. Let me tell you about the "semantic line breaks", and then I will reveal the source of this knowledge - which, as it turns out, was revealed to the world when I was only a few months old!

At the lecture, I ask the question - is it supposed that Sphinx files will be available for reading to the end user. If not, then I encourage listeners to treat files as a “source code” that can be semantically formatted. Instead of messing with the lines of each paragraph in order to adjust them to the same width, you can end the line in any place that separates two thoughts.

The result may be wonderful.

If you start each sentence with a new line and divide the sentences themselves into statements, text files become much easier to edit and store in the version control system. Text editors are great at working with strings, so if each sentence is represented by a block of consecutive lines, your editor suddenly turns out to be an extremely powerful tool for quickly rearranging sentences and thoughts.

In addition, your version control system will simply be delighted with semantic line breaks. Did it happen to you that after changing a few words at the beginning of a paragraph, it turned out that the version control system now considers the entire text as amended?

-   ,  ,   -  ,    -     -   ''.PP''  - . +   ,  ,   +  ,    +     +   ''.PP''  + . 

If each sentence and statement begins on a new line, you can make the same changes in the same paragraph without changing most of it.

 -   , +   ,  ,     ,            ''.PP''   . 

“Semantic line breaks,” as I call them, make life easier for me for more than twenty years, and dictate the layout of my text files under the hood, regardless of the markup used, be it HTML, TeX , RST , or the venerable troff .

Where did I find out about this thing?

For a long time, I thought that my source was the UNIX Documentation Toolkit Guide. The toolkit was an attempt by AT & T to market the operating system, which became a cult among Bell Labs engineers, by adding the most powerful text-breaking tools to the system. The attempt failed of course - they say that everything was just awful with marketing at AT & T, as well as at Xerox, where they had no idea what to do with the ideas that boiled at PARC in the 1970s - but my father worked at Bell Labs and was at his house a copy of the toolkit documentation. (I could not find a copy on the Internet - maybe all available copies were destroyed during the destructive copyright war, which quite deservedly led SCO to collapse?)

But as a result of a thorough search, I turned over an earlier source and gladly found out that the source of my inspiration is none other than Brian V. Kernighan !

He published UNIX for Beginners as a Bell Labs 74-1273-18 technical memo on October 29, 1974. It describes a much simpler version of the operating system than in its more well-known and widely available “UNIX for beginners - Second Edition” of 1978. As a result of a long search, I found a lonely copy, the link to which is above, posted on a little-known Japanese website dedicated to UNIX 6th Edition . In the section “Tips for the preparation of documents” Kernighan shares his wisdom:

Document preparation tips

Most documents have time to change several versions (always more than it seems at the beginning) before the work on them will be completed. Accordingly, everything possible should be done to facilitate changes.

First of all, when you are engaged in purely mechanical typing, type so as to facilitate further editing. Start each sentence with a new line. Keep the lines short and end the lines in naturally suitable places, such as commas and semicolons, and not where. Since for most people, edits consist of rewriting phrases and adding, deleting, and also rearranging sentences, these measures simplify any further editing.
')
- Brian V. Kernigan, 1974

Notice how his advice sounds pythonically - it replaces inventions about documents written “once and for all” with a realistic approach - writing text that is easy to edit later.

I must have read it when I first studied UNIX and carried it through all these years. The fact that the advice given in 1974, and initially focused on facilitating text editing in a monstrously limited editor, can equally well be applied in the modern world of multi-colored full-screen editors, such as Emacs and Vim, and distributed version control systems, completely unthinkable in 1970 says a lot about the power of the unix approach.

If you are interested in early UNIX documentation - including the Second Edition of Kernighan Beginners Guide - look at the 7th Edition manuals nobly posted by Bell Labs to the network in the form of PDF files and also in the form of text files, with markup for troff . Please note - from the troff files to this day you can collect the finished document, which can be viewed with modern means - try to turn this focus with formatted text from any other 1970s editors!

Afterword from the translator:

Why am I ready to publish this translation just now? Everything in general is simple. On Habré recently appeared support for the Markdown format, to which I was overwhelmingly pleased. Only now it turned out that for some reason Habr does not glue strings, although Markdown should not glue strings if they only end with two hanging spaces.

And it turns out that I can't write articles in my favorite editor, store them in my favorite version control system, and then just copy-paste to Habr. Habr! How is that? Why? Please make the lines stick together! See, Kernighan himself said that this is correct!