Emacs как ветвь эволюции

Поскольку "надо жить так, чтобы было о чём написать в блоге", последние 3 месяца я использовал Emacs в org-mode для управления задачами. В итоге я выбрал vim+vimwiki, но тут надо сделать несколько дисклеймеров:

  • Я использовал emacs и ранее, и, возможно, даже написал в нём несколько курсовых работ в LaTeX; это было настолько давно, что я уже и не помню (возможно, около 1999-2003-го года)
  • Цель этой статьи не в том, чтобы указать на недостатки emacs, но, скорее, ответить на вопросы "кому он может быть полезен" и "какие есть современные инструменты для того, что есть в Emacs"
  • Я не программирую, последнее время даже не пишу в LaTeX

Хотелось бы не набрасывать на вентилятор, а разобрать системно:

  • UI/UX
  • функциональность управления задачами

UI/UX

С точки зрения того, как Emacs выглядит, поражает обилие цветов и расцветок. Точнее, поражает не это, а отсутствие чувства меры при создании цветовых схем, а также при использовании подчёркиваний и шрифтов разных размеров. Например, в типографии подчёркивание считается моветоном (и на этом сайте именно по этой причине оно появляется только при наведении). В терминале подчёркивание выглядит ещё терпимо, но почему-то именно в графической версии Emacs оно напрягает. Наверное, можно его отключить, как я отключил использование жирного шрифта; и в целом тут плюс в том, что каждый может сделать, как хочет.

С точки зрения работы, после vim возникает ровно один вопрос: почему для тех же самых действий нужно использовать в 2-6 раз больше нажатий на клавиши? И дело не только в лени: каждое нажатие увеличивает вероятность ошибки, и если где-то в цепочке нажатий ты ошибся – начинай сначала. На это современный Emacs отвечает: ну так у нас есть evil-mode, который изображает vim идеально. И вот тут начинается проблема, поскольку вся документация на все режимы оказывается не применима с включением evil-mode. Более того, как в режиме вставки, так и в режиме команд продолжают действовать все сочетания клавиш Emacs, от чего крыша начинает несколько ехать.

Если брать org-mode, то нажатий в vimwiki как-то резко меньше:

  • Enter, чтобы открыть ссылку – вместо C-c C-o в Emacs
  • +, чтобы добавить ссылку, вместо C-c C-l в Emacs

И всё же vimwiki некорректно сравнивать с org-mode, который может делать вообще всё, например:

  • показывать повестку дня, то есть задачи на конкретный день
  • документировать программный код и конфиги, сразу же их выполнять или создавать конфиги на основе файла org

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

Функциональность управления задачами

Что сейчас необходимо для эффективного управления своими задачами:

  • Видеть задачи на разных устройствах, чтобы проверить / дописать
  • Работать с задачами совместно с другими людьми

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

  • Для себя: Google Keep или DropBox Paper (да, там есть возможность призвать кого-то, я в курсе)
  • Для других: трекеры, то есть систему управления задачами, + wiki

В связи с тем, что реально большие объёмы информации я храню именно в серверных приложениях, которые доступны всем, в vimwiki остаётся только структурированный набор ссылок на задачи в трекере / страницы на wiki, и выглядит у меня этот файл вообще всего крайне небольшим. И тут мы приходим к структуре.

Когда первый раз увидел org-mode, у меня последовательно возникло ровно две мысли:

  • Да они же заново изобрели Markdown!
  • Да они же изобрели его, наверное, до Markdown!

И когда думаешь о Markdown, то поражаешься, зачем заново изобретать, с одной стороны, разметку, которая будет понятна всем, а с другой инструменты экспорта из этой разметки во все типовые средства публикации: pdf, html, LaTeX и т.п. Причём тут люди угарают по хардкору, они не перегоняют содержимое org файлов в markdown, чтобы потом использовать стандартные инструменты (то есть свести задачу к предыдущей), а заново пишут экспорт для каждого формата.

Тут, наверное, можно возразить, что у org-mode есть развитая функциональность TODO, которая позволяет собирать повестку из многих файлов, накладывать её на календарь, а нигде такого нет. Но если в тексте мне нужно что-то поправить, то я просто оставлю TODO, FIXME или ещё какое-то условное слово, по которому буду потом искать, и которое будет видно в окончательной вёрстке. А если мы говорим о календаре, то я, как жалкий раб Google, использую Google календарь или другие календари, в которых можно:

  • Назначать встречи, а не только просматривать свои задачи
  • Добавлять ко встречам ссылки на Zoom
  • Добавлять повестку, которую будут видеть все, и использовать ссылку на встречу

Тут, в общем, человечество пришло к выводу, что вместе лучше, чем по одному, это кардинально поднимает продуктивность работы (кроме назначения бесполезных встреч). Надеюсь, никто не будет допиливать в org-mode возможности совместной работы.

Выводы

Я видел лекции на YouTube, где учёные рассказывали, как одновременно в одном файле org:

  • Исполняют программный код
  • Просматривают графики и вложенные файлы
  • Публикуют всё это на сайте

Да, наверное, в качестве комбайна, которому нужно всё, замены Emacs нет. Лично я не делал таких сложных формул, и у меня другой workflow: сначала всё набрать, а потом проверить. И то, что весь этот функционал доступен абсолютно бесплатно в единой среде, конечно, поражает воображение. Наверное, сейчас я думаю, что перешёл к vim, но это лишь стадия развития, и когда-нибудь вернусь на Emacs. Но хочется надеяться, что это произойдёт из-за потребностей, которые объективно нельзя решить другими способами, а не из фетишизма или желания не выходить из кокона.

@Константин Овчинников
Теги: #product management #linux #продуктивность

Комментарии