Hacker News Digest

В монширинтовом тексте выравнивание по правому краю или центрирование требует подсчёта пробелов, а полное выравнивание выглядит плохо из-за неравномерно больших промежутков между словами. Дефисы в таком шрифте привлекают лишнее внимание и ломают копипаст, поэтому полное выравнивание в текстовых файлах почти не используется. Однако есть альтернатива: тщательный подбор слов так, чтобы каждая строка заканчивалась точно на нужной позиции без двойных пробелов. Именно этим методом пользовался rs1n в конце 1990-х, создавая руководство по Super Metroid для GameFAQs. В нём более 17 000 слов выровнены по правому краю идеально — каждое предложение подобрано так, чтобы длина строки совпадала с пределом в символах, без использования специальных инструментов. Автор подтверждает в FAQ: никаких программ, только аккуратный подбор лексики в ASCII-редакторе. Этот приём напоминает ручную настройку строк в интерфейсах, когда разработчики часами подбирают формулировки для тултипов или кнопок, чтобы они точно укладывались в отведённое пространство — знакомое ощущение для каждого, кто сталкивался с жёсткими лимитами ширины в плотных UI.

Тред содержит практические примеры и личные истории о ручном выравнивании текста в монопространственных средах — от старых email до комментариев в коде, а также современные подходы (LLM, автоматические скрипты) и критику полного выравнивания. - Макрос в vim с вызовом fmt переформатирует комментарии до фиксированной ширины (например, 79 символов), а подбор слов убирает резкие правые края. - Ограничения выравнивания заставляют искать новые формулировки, что улучшает качество письма (@unicorn_platfor). - В UI‐строках длинные подписи могут обрезаться при увеличении масштаба (@gyomu). - Правило «выбирать слова тщательно» улучшает читаемость справочных сообщений CLI‐утилит (@sodimel). - Парные слова одинаковой длины (old/new, head/tail, fast/slow) поддерживают вертикальное выравнивание в коде (@AgentOrange1234). - Перенос пунктуации на пробел правее («висячая пунктуация») делает правое выравнивание визуально приятнее (@bhaak). - LLM могут автоматически подбирать слова для заполнения строк до нужной ширины (@ivw). - «Рваный» правый край легче воспринимается; полное выравнивание часто даёт странные пробелы (@brooke2k). - Полное выравнивание — плохая практика; @wraptile ввёл lint‐правило, запрещающее justify в CSS, ради предсказуемости чтения. - В сценариях (например, X‐Files) писатели избегали «вдов» и «сирот», подгоняя диалоги под макет (@sho_hn). - В Laravel‐комментариях строки часто оформляются блоками, где каждая следующая короче на три символа (@easydidit). - В 1990‐х авторы выравнивали текст в монопространственных email, но переход к пропорциональным шрифтам сделал это невозможным (@lproven).

Проект playball позволяет смотреть трансляции матчей MLB прямо в терминале через ASCII-графику. Вместо видео поток передаётся текстовыми символами, имитирующими поле, игроков и мяч, что создаёт минималистичный, но на удивление детализированный опыт просмотра.

Для работы требуется аккаунт MLB.tv и настроенный доступ к их стриминговому сервису. Инструмент написан на Python, использует библиотеку curses для отрисовки интерфейса и парсит данные в реальном времени. Это интересный пример того, как ностальгический формат терминала может быть адаптирован для современных развлечений, экономя трафик и ресурсы.

• Участники обсуждают проект терминального просмотра текстовой трансляции бейсбольных матчей MLB, отмечая его удобство и связь с хакерской культурой.
• Поднимается тема доступности данных MLB через API и существования аналогичных инструментов для других видов спорта (NBA, NFL, крикет, футбол).
• Обсуждаются исторические и экономические причины снижения популярности бейсбола, а также преимущества MLB в области стриминга по сравнению с другими лигами.
• Упоминается практика ведения текстового протокола игры (scorekeeping) и то, как хорошо бейсбол подходит для текстового формата из-за своей структуры.
• Высказываются пожелания по развитию проекта, включая анимацию, поддержку других лиг и

UTF-8 — гениальное решение: 1–4 байта на символ, полная совместимость с 7-битным ASCII.
Старший бит первого байта сразу говорит, сколько байт идёт дальше:

Паттерн 1-го байта	Длина	Пример
0xxxxxxx	1	ASCII
110xxxxx	2
1110xxxx	3
11110xxx	4

Продолжения всегда 10xxxxxx.
Программа читает байт, по префиксу понимает длину, выделяет «полезные» биты, получает кодовую точку Unicode и выводит символ.

Пример:
хинди «अ» = 11100000 10100100 10000101 → U+0905.

Файл Hey👋 Buddy (13 байт):
H e y 👋 B u d d y
👋 кодируется 4 байтами 11110000 10011111 10010001 10001011 → U+1F44B.

• UTF-8 — гениальное, простое и обратно-совместимое с ASCII решение, придуманное Кеном Томпсоном и Робом Пайком за ужином.
• Продолжение-байты 10xxxxxx позволяют за O(1) найти границы символа, не парся весь поток.
• Критика: Unicode «раздулся» (комбинирующие символы, эмодзи, 25-байтовые «графемы»), а UTF-8 не сам компактен для нелатиницы.
• Спор о «переполнении»: 4 байт хватает на 21 бит → 2 097 152 кодовых точек; 5-6 байт запрещены специально.
• Некоторые считают, что красота UTF-8 — не комитетное изобретение, а удачный частный хак, вышедший в мировой стандарт.

Как Return стал Enter

Переход от пишущих машинок к компьютерам в массовом сознании выглядит прямолинейным: к машинке прикрутили процессор и экран — получился компьютер. На деле всё было запутаннее, и ни одна клавиша не отражает этот путь лучше, чем Return.

От рычага к клавише

На механических машинках рычаг «carriage return» одним движением переводил каретку в начало строки и прокручивал бумагу. Это была чисто механическая операция, и до электрификации 1940–50-х она не могла стать клавишей. Когда же электромоторы взяли на себя работу, рычаг исчез, а на его месте появилась клавиша Return (иногда Electric Return или Power Return). В IBM Selectric инструкция говорила о «carrier return», но на клавиатуре всё равно писали Return.

Смысл и коды

Машинки не понимали смысла текста: не было цифр 0 и 1 — печатали O и l; знак $ получали, наложив I на S. Return тоже был просто «перевод строки» без контекста. Компьютеры же разделили функции:

• Carriage Return (CR) — возврат каретки, код 13.
• Line Feed (LF) — перевод строки, код 10.

В Unix оставили только LF, в DOS/Windows — CR+LF, а в старых Mac — только CR. Эти разногласия живы до сих пор.

Появление Enter

В 1960-х терминал Teletype ASR-33 ввёл клавишу ENTER для подтверждения команд. Она генерировала CR, но уже несла смысл «ввод». Мэйнфреймы IBM разделили:

• Return — новая строка в тексте.
• Enter — «отправить» команду.

На ранних ПК (Apple II, Commodore) была одна клавиша Return. IBM PC 1981 добавила справа отдельную Enter на цифровом блоке, но оставила Return в основной зоне. Постепенно оба названия стали обозначать одно и то же, а на некоторых клавиатурах 1980-х можно было встретить оба лейбла сразу.

Итог

Сегодня Return и Enter — это одна клавиша, но внутри она может посылать CR, LF или CR+LF в зависимости от системы. Рычаг 1870-х превратился в символ «⏎», а его история — это квинтэссенция перехода от механики к цифре.

• IBM PC не переименовал Return в Enter, а просто дал одной клавише две функции.
• Некоторые жалеют, что вместо CR/LF не использовались ASCII-символы FS/RS, чтобы избежать проблем перевода строк.
• На старых клавиатурах Return и Enter были разными клавишами; ISO до сих пор различает Return в основном блоке и Enter на цифровой панели.
• У Apple всегда была клавиша Return, а Enter — только на нумпаде; у IBM/PC клавиша в основном блоке сразу называлась Enter.
• Пользователи вспоминают путаницу между Return и Enter в старых программах и то, что стрелка ↵ всё ещё напоминает о механическом возврате каретки.

Monodraw — редактор ASCII-графики для macOS (11 Big Sur+).
Пробная версия бесплатно, лицензия — $9.99, скидки для учебных заведений.

Возможности

• Диаграммы: структуры данных, алгоритмы, ER-диаграммы (нотация «Crow’s Foot»).
• Mind-map: свободное размещение текста на бесконечном холсте.
• Баннеры: 148 встроенных шрифтов FIGlet, изменение размера и выравнивание.
• Инструменты: прямоугольники, линии (ортогональные, лестницы), текст, карандаш, ластик, заливка, пипетка.
• Точки крепления: линии автоматически цепляются к фигурам.
• CLI: генерация документации в хуках Git, экспорт JSON.
• Группы, направляющие, фокус-режим, горячие клавиши для быстрой работы.

Экспорт: PNG, SVG.

• Разработчик Monodraw отвечает на вопросы; пользователи делятся альтернативами (asciiflow, textik, durdraw, REXPaint).
• Все хвалят чистоту результата, низкую цену ($10 навсегда) и удобство вставки ASCII-диаграмм прямо в код или документацию.
• Основные сценарии: комментарии в исходниках, схемы сетей, баннеры серверов, ASCII-анимации, план кухни.
• Главный недостаток: приложение только для macOS; много просьб портировать на Linux.
• Новая текстовая разметка (апрель 2025) улучшает работу с системами контроля версий.

ASCII-вывод в D2 0.7.1
Файлы с расширением .txt теперь рендерятся в ASCII. Пример: при сохранении .d2-файла Vim-плагин мгновенно показывает ASCII-превью.

Для документации кода
ASCII-диаграммы удобно вставлять в комментарии: выделите блок d2, плагин заменит его ASCII-версией.

Unicode или чистый ASCII
По умолчанию используются символы Unicode, но флаг --ascii-mode=standard вернёт строгий ASCII.

Ограничения (альфа-версия)

• Без стилей: animated, font, темы не поддерживаются; цвета в терминале — возможно позже.
• Неравномерные отступы из-за дискретной сетки.
  Сообщайте о багах: github.com/terrastruct/d2/issues.

Попробуйте сейчас
Откройте пример в D2 Playground.

• Представлена новая альфа-функция D2: рендеринг диаграмм в ASCII.
• Пользователи сравнивают D2 с Mermaid, отмечают лучший внешний вид и CLI без Chromium, но упрекают в отсутствии GitHub-рендеринга и сложных grid-раскладок.
• Появились вопросы о браузерной офлайн-работе, vim-/emacs-плагинах, Python-обёртке и возможности ручной подгонки элементов.
• Автор подтвердил, что WASM-версия (d2.js) уже работает в браузере, но пока неанонсирована; официальный релиз и поддержка PR-диаграмм ожидаются позже.