[Перевод] Семантический перенос строк
От переводчика:
Некоторое время назад на Хабре публиковался перевод статьи под названием «Искусство командной строки». Среди прочего, в статье было рекомендовано освоить vim. Исходник статьи, выложенный на Гитхаб, по иронии судьбы, оказался совершенно непригодным к редактированию именно этим редактором, так как в нём на один параграф приходилась ровно одна строка.
Я тогда выразил своё недоумение автору и попросил его выровнять текст на 80 символов. Но после непродолжительной дискуссии в коментариях дали ссылку на описание форматирования исходников литературных текстов по семантическому принципу. Идея, заложенная в этом принципе в общем довольно простая, но я был поражён её глубиной, которой, пусть и запоздало, хочу поделиться с окружающими.
Хочу предупредить, что не все ссылки в статье работоспособны, но я решил оставить их как есть — мало ли что.
Итак, статья.
Семантический перенос строк
На ежегодном ликбезе по Sphinx проводимом в рамках PyCon я регулярно даю один совет. Благодарный слушатель спросил, где я сам почерпнул эти знания. Я провел археологические изыскания и теперь у меня есть ответ на этот вопрос. Позвольте рассказать вам про «семантические переносы строк», а потом я открою источник этого знания — которое, как выясняется, было явлено миру когда мне было всего несколько месяцев от роду!
На лекции я задаю вопрос — предполагается ли, что Sphinx файлы будут доступны для чтения конечному пользователю. Если нет, то я призываю слушателей рассматривать файлы как «исходник», который можно форматировать семантически. Вместо возни со строками каждого параграфа с целью подогнать их к одинаковой ширине, можно заканчивать строку в любом месте, разделяющим две мысли.
Результат может оказаться замечательным.
Если начинать каждое предложение с новой строки и делить сами предложения на высказывания, текстовые файлы становится гораздо проще редактировать и хранить в системе контроля версий. Текстовые редакторы отлично умеют работать со строками поэтому если каждое предложение представлено блоком последовательных строк, ваш редактор внезапно оказывается чрезвычайно мощным инструментом для быстрой перестановки высказываний и мыслей.
К тому же, ваша система контроля версий будет просто в восторге от семантических переносов строк. Случалось ли у вас, чтобы после изменения нескольких слов в начале параграфа, оказывалось, что система контроля версий теперь считает изменённым весь текст?
-Великолепие решения в том, что теперь, если вы
-передумаете насчёт того, как должен выглядеть
-параграф можно изменить форматирование вывода
-простым изменением определения ‘‘.PP’’ и
-перезапуском форматтера.
+Красота решения в том, что теперь, если вы
+передумаете насчёт того, как должен выглядеть
+параграф можно изменить форматирование вывода
+простым изменением определения ‘‘.PP’’ и
+перезапуском форматтера.Если каждое предложение и высказывание начинать с новой строки, вы можете произвести те же самые изменения в том же самом параграфе не изменяя большую его часть.
-Великолепие решения в том,
+Красота решения в том,
что теперь, если вы передумаете насчёт того,
как должен выглядеть параграф
можно изменить форматирование вывода
простым изменением определения ‘‘.PP’’
и перезапуском форматтера.«Семантические переносы строк,» как я их называю, облегчают мне жизнь уже более двадцати лет, и диктуют устройство моих текстовых файлов под капотом независимо от используемой разметки, будь то 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. В разделе «Советы по подготовке документов» Керниган делится своей мудростью:
Советы по подготовке документовБольшинство документов успевает сменить несколько версий (всегда больше, чем кажется в начале) перед тем, как работа над ними будет завершена. Соответственно, следует делать всё возможное для облегчения внесения изменений.
Прежде всего, когда вы занимаетесь чисто механическим набором текста, набирайте так, чтобы облегчить дальнейшее редактирование. Начинайте каждое предложение с новой строки. Делайте строки короткими и заканчивайте строки в естественным образом подходящих для этого местах, таких как запятые и точки с запятыми, а не где придётся. Так как у большинства людей правки состоят из переписывания фраз и добавления, удаления, а также перестановки предложений, эти меры упрощают любую дальнейшую редактуру.
— Брайен В. Керниган, 1974
Заметьте, как питонически звучит его совет — он заменяет выдумки о документах написанных «раз-и-навсегда» реалистичным подходом — написанием текста, который просто редактировать в дальнейшем.
Я, должно быть, прочитал это когда впервые изучал UNIX и пронёс сквозь все эти годы. Тот факт, что совет данный в 1974, и изначально ориентированный на облегчение редактирования текста в чудовищно ограниченном редакторе ed можно с тем же успехом применить в современном мире разноцветных полноэкранных редакторов, таких, как Emacs и Vim и распределённых систем контроля версий, совершенно немыслимых в 1970-х, очень многое говорит о мощи юниксового подхода.
Если вас интересует ранняя документация к UNIX — в том числе Второе Издание Руководства для Начинающих Кернигана — посмотрите на 7th Edition manuals благородно выложенное Bell Labs в сеть в виде PDF файлов, а также в виде текстовых файлы, с разметкой для troff. Обратите внимание — из troff файлов и по сей день можно собрать готовый документ, который можно просматривать современными средствами — попробуйте-ка провернуть этот фокус с форматированным текстом из любых других редакторов 1970-х!
Послесловие от переводчика:
Почему я созрел опубликовать этот перевод только сейчас? Всё в общем просто. На Хабре недавно появилась поддержка формата Markdown, чему я был несказанно рад. Только вот выяснилось, что строки Хабр почему-то не склеивает, хотя Markdown не должен склеивать строки если только они кончаются двумя висячими пробелами.
И выходит, что я не могу писать статьи в любимом редакторе, хранить их в любимой системе контроля версий, а потом просто копипастить на Хабр. Хабр! Как так то? Почему? Сделай, пожалуйста чтобы строки склеивались! Видишь, сам Керниган сказал, что это правильно!
