От переводчика: Некоторое время назад на Хабре публиковался перевод статьи под названием "Искусство командной строки". Среди прочего, в статье было рекомендовано освоить vim. Исходник статьи, выложенный на Гитхаб, по иронии судьбы, оказался совершенно непригодным к редактированию именно этим редактором, так как в нём на один абзац приходилась ровно одна строка.  Я тогда выразил своё недоумение автору и попросил его выровнять текст на 80 символов. Но после непродолжительной дискуссии в коментариях дали ссылку на описание форматирования исходников литературных текстов по семантическому принципу. Идея, заложенная в этом принципе в общем довольно простая, но я был поражён её глубиной, которой, пусть и запоздало, хочу поделиться с окружающими. Хочу предупредить, что не все ссылки в статье работоспособны, но я решил оставить их как есть — мало ли что. Итак, статья. Семантический перенос строк На ежегодном ликбезе по Sphinx  проводимом в рамках PyCon я регулярно даю один совет. Благодарный слушатель спросил, где я сам почерпнул эти знания. Я провел археологические изыскания и теперь у меня есть ответ на этот вопрос. Позвольте рассказать вам про “семантические переносы строк”, а потом я открою источник этого знания — которое, как выясняется, было явлено миру когда мне было всего несколько месяцев от роду! На лекции я задаю вопрос — предполагается ли, что Sphinx файлы будут доступны для чтения конечному пользователю. Если нет, то я призываю слушателей рассматривать файлы как “исходник”, который можно форматировать семантически. Вместо возни со строками каждого абзаца с целью подогнать их к одинаковой ширине, можно заканчивать строку в любом месте, разделяющим две мысли.  Результат может оказаться замечательным. Если начинать каждое предложение с новой строки и делить сами предложения на высказывания, текстовые файлы становится гораздо проще редактировать и хранить в системе контроля версий. Текстовые редакторы отлично умеют работать со строками поэтому если каждое предложение представлено блоком последовательных строк, ваш редактор внезапно оказывается чрезвычайно мощным инструментом для быстрой перестановки высказываний и мыслей.  К тому же, ваша система контроля версий будет просто в восторге от семантических переносов строк. Случалось ли у вас, чтобы после изменения нескольких слов в начале абзаца, оказывалось, что система контроля версий теперь считает изменённым весь текст? Если каждое предложение и высказывание начинать с новой строки, вы можете произвести те же самые изменения в том же самом абзаце не изменяя большую его часть. “Семантические переносы строк,” как я их называю, облегчают мне жизнь уже более двадцати лет, и диктуют устройство моих текстовых файлов под капотом независимо от используемой разметки, будь то HTML, TeX, RST, или почтенный troff . Откуда же я узнал об этой штуке? Долгое время я думал, что моим источником было Руководство по инструментарию для созданию UNIX документации. Инструментарий был попыткой AT&T продвинуть на рынок операционную систему, которая стала культовой среди инженеров Bell Labs, путем добавления в систему мощнейших инструментов по офомлению текста. Попытка конечно провалилась — говорят, что в AT&T с маркетингом всё было просто ужасно, также как и в Xerox, где понятия не имели что делать с идеями бурлившими в PARC в 1970-x — но мой отец работал в Bell Labs и у него дома был экземпляр документации к Инструментарию. (В интернете я копии найти не смог — может быть, все доступные копии были уничтожены во время разрушительной войны за копирайт которая совершенно заслуженно привела SCO к краху?) Но в результате тщательных поисков, я обраружил более ранний источник и с радостью узнал, что источник моего вдохновения не кто иной, как Брайен В. Керниган! Он опубликовал “UNIX для начинающих” в качестве технического меморандума Bell Labs 74-1273-18 29 октября 1974 года. В нём описана гораздо более простая версия операционной системы, чем в его более известной и широкодоступной “UNIX для начинающих — Второе Издание” 1978 года. В результате долгих поисков я обнаружил одинокую копию, ссылка на которую приведена выше, размещённую на малоизвестном японском сайте, посвящённом UNIX 6th Edition. В разделе “Советы по подготовке документов” Керниган делится своей мудростью: Заметьте, как питонически звучит его совет — он заменяет выдумки о документах написанных “раз-и-навсегда” реалистичным подходом — написанием текста, который просто редактировать в дальнейшем. Я, должно быть, прочитал это когда впервые изучал UNIX и пронёс сквозь все эти годы. Тот факт, что совет данный в 1974, и изначально ориентированный на облегчение редактирования текста в чудовищно ограниченном редакторе ed можно с тем же успехом применить в современном мире разноцветных полноэкранных редакторов, таких, как Emacs и Vim и распределённых систем контроля версий, совершенно немыслимых в 1970-х, очень многое говорит о мощи юниксового подхода. Если вас интересует ранняя документация к UNIX — в том числе Второе Издание Руководства для Начинающих Кернигана — посмотрите на 7th Edition manuals благородно выложенное Bell Labs в сеть в виде PDF файлов а также в виде текстовых файлы, с разметкой для troff. Обратите внимание — из troff файлов и по сей день можно собрать готовый документ, который можно просматривать современными средствами — попробуйте-ка провернуть этот фокус с форматированным текстом из любых других редакторов 1970-х! Послесловие от переводчика: Почему я созрел опубликовать этот перевод только сейчас? Всё в общем просто. На Хабре недавно появилась поддержка формата Markdown, чему я был несказанно рад. Только вот выяснилось, что строки Хабр почему-то не склеивает, хотя Markdown не должен склеивать строки если только они кончаются двумя висячими пробелами. И выходит, что я не могу писать статьи в любимом редакторе, хранить их в любимой системе контроля версий, а потом просто копипастить на Хабр. Хабр! Как так то? Почему? Сделай, пожалуйста чтобы строки склеивались! Видишь, сам Керниган сказал, что это правильно! Software developer