Не столь давно на этом сайте я уже приподнимал тему регулярных выражений и поисковых шаблонов. В прошлый раз это было что-то вроде сжатого ликбеза. Теперь можно начинать вкидывать примеры из реальной жизни, и сегодня таким примером будет подгонка больших простыней текста под 80-символьный формат.

Зачем?

Эта традиция имеет долгую историю. Представим где-то примерно 80-е и начало 90-х годов, когда документы печатали на матричных принтерах, мониторы были пузатыми, а терминал был не программой в составе ОС, а отдельной железкой. Компьютеры могли иметь отдельные видеорежимы для работы с текстом (чтоб не хранить в памяти каждый пиксель), а терминал чаще всего итак работал только с текстовой информацией. В таких случаях пользователя мало волнует разрешение экрана в пикселях, куда более уместен вопрос: "Сколько текста можно впихнуть на этот дисплей?" Размер 80 на 24 символов был одним из стандартов и поддерживался терминалами VT52 и VT100. Иногда насчёт количества строк не заморачиваются и говорят просто 80-column display.

Сейчас всё это - лишь занимательная археология. Теперь у нас широкие мониторы и разрешение мы измеряем в пикселях. Но стандарт как бы остался, его иногда стараются придерживаться, и в этом есть некоторый смысл. Среды разработки часто имеют возможность открыть несколько вкладок с кодом на одном экране (Split View или типа того), с которыми будет удобнее работать, если текст ограничен по ширине. Да и вне программирования текст небольшой ширины проще читать: его можно открыть в терминале или текстовом редакторе, и при этом не разворачивать окно во весь экран и не включать перенос строк. Под 80-символьный формат можно подгонять всякие readme.txt, деловую переписку и т.д..

Ладно, и как?

Перепахивать большой текст вручную было бы очень трудозатратно. Вместо этого воспользуемся текстовым редактором с поддержкой регулярок. Например, на винде таким редактором скорее всего будет Notepad++, но можете попробовать найти что-то другое.

Предположим, что в обрабатываемом тексте слова в абзацах идут сплошняком, то есть лишних переводов строки мы не делали. Такой текст мы могли вбить вручную со включеным автопереносом строк или скопировать его из текстового процессора.

Поисковый шаблон будет иметь вид:

Он ищет последовательность любых символов длиной от 60 до 80. Она должна находиться в начале строки, поэтому в начале стоит якорь ^. При этом слова не должны обрываться посередине, так что справа от последовательности нужно ещё обнаружить признак конца слова в виде пробела или другого пробельного символа (перевода строки или табуляции) - для этого можно использовать \s или \b.

Шаблон для замены имеет вид:

То есть когда в совпадении набралось достаточно целых слов, чтобы длина строки была от 60 до 80, совпадение заменяется само на себя плюс перевод строки.

В Notepad++ достаточно один раз нажать "Заменить всё" (со включеными регулярками), и весь текст будет перелопачен. Похоже, что после каждой замены Np++ автоматически делает новый поиск по шаблону и поэтому видит, что каждый раз появляется новая строка и якорю ^ есть за что зацепиться.

Другие редакторы могут вести себя по-другому. Например, xed в составе Linux Mint при нажатии "Заменить всё" обрабатывает те совпадения, которые смог найти за первый проход, то есть первую порцию символов в начале абзаца. Чтобы обработать весь текст в xed, мне пришлось многократно натыкивать кнопку замены.

В качестве альтернативного решения на Linux можно воспользоваться консольной утилитой sed. Шаблон будет почти тот же, но без якоря начала строки. Важно вызывать со флагом -r, чтобы группировка \1 сработала.

Так же можно попробовать утилиту fold.

Но подвох в том, что fold не поддерживает Юникод и обрабатывает файл побайтно, судя по всему. Если вы скормите файл в UTF-8 c кириллицей, ширина текста может получиться в 2 раза меньше, так как символы кириллицы занимают по 2 байта.