Linux Mint и его Cinnamon. Очерки применителя

Федорчук Алексей Викторович

В репозитории для Gedit доступно несколько плагинов, большинство из которых ориантировано на специальные задачи разработчиков или Tex-верстальщиков. Однако пакет gedit-plugins — более общего назначения, почему и подлежит и подлежит установке:

$ apt install gedit-plugins

После этого во вкладке Модули добавляется ряд новых функций, таких, как автоматическое закрытие скобок и кавычек, знакомство с которыми оставляю на усмотрение заинтересованных лиц.

Мне Gedit кажется откровенно скучным. Кроме того, не вполне понятно его позиционирование: в качестве лёгкого редактора, предназначенного для правки конфигов (подобно Mousepad или Leafpad) он явно избыточен, а для всамделишней

работы с большими текстами — недостаточно функционален, даже при условии установки дополнительных плагинов. В частности, в нём напрочь отсутствует возможность работы с проектами, что обесценивало для меня любые иные его достоинства, даже если бы таковые нашлись. И потому в следующих очерках я обращусь к возможным альтернативам Gedit'а.

Альтернативные редакторы: введение

Таким образом, Gedit не подходит для сочинения объёмных материалов, хотя бы серии статей в рамках одной темы, не говоря уже о книгах, когда приходится работать со множеством взаимосвязанных текстовых документов. И тут, как ни странно, оказывается, что требования к текстовому редактору со стороны применителя-текстовика часто пересекаются с таковыми разработчика, сочиняющего что-либо посложнее Hello, world!, с некоторым, иногда большим, числом файлов, предназначенных для реализации одной задачи. И потому обоим нашим героям от текстового редактора требуется средства управления проектами и манипуляций файлами. Причём не обязательно файлами только текстовыми — ведь некоторые авторы имеют обыкновение иллюстрировать своим материалы.

Кроме того, сочинение оригинальных материалов не сводится к их набору из головы (ну или кто чем эти материалы сочиняет). Потому что набор текста оказывается неотделимым от его редактирования. Под которым в рассматриваемом случае подразумевается не только (и не столько) исправление орфографических ошибок и опечаток, сколько стилистическая правка. Которая часто требует свободного перемещёния между строками, абзацами и даже страницами уже набранного текста. И тут очень важной оказывается развитая система кейбиндингов, позволяющая мгновенно, без нудного стучания по клавишам Left и Right, Up и Down, переместиться к участку текста, требующего стилистической правки.

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

Ай да я, ай да сукин сын: так здорово придумал — и забыл...

Наконец, ещё одна составляющая набора и редактирования текста — разметка. Да, я понимаю стремление отделить

мух от котлет

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

ветра в поле

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

В штатном режиме текстовые редакторы предполагают единственный способ ввода тегов (или элементов разметки TeX'а, если речь идёт о подготовке к «бумаге»): вручную. Что а) скучно, б) долго, в) чревато ошибками. И, наконец, просто отвлекает от процесса сочинительства. Но тут на помощь приходит режим записи макрокоманд, привязываемых к хоткеям. А вот этот режим в текстовом редакторе может отсутствовать или присутствовать. А если

присутствует — может быть реализованным по разному: просто, но слабо, мощно, но сложно; в идеале, конечно, мощно и просто.

Так что выбор редактора очень сильно влияет на эффективность работы с текстом на всех её стадиях — от сочинения до разметки. И эффективность эта определяется не только наличием «рюшечек и менюшечек» или их отсутствием, а зависит от многих факторов. И потому следующие несколько абзацев посвящены этому вопросу. Только сразу предупреждаю: тем, кто полагает, что Vim/Emacs наше фсио, лучше их не читать. Как, впрочем, и весь этот очерк...

Программисты находят решение своих задач в применении всякого рода IDE, то есть интегрированных сред разработки (Integrated Development Environment). Интегрированных сред для сочинительства нарративных текстов ещё никем не придумано. Но в этом качестве отлично могут выступить программы, которые лежат там, где кончаются текстовые редакторы и начинаются IDE. А вот их список оказывается очень коротким. Если исключить практически сошедший со сцены NEdit и его клон QEdit, так на эту сцену и не вышедший (в причины обоих явлений вдаваться не буду), то он сведётся к двум с половиной позициям: Komodo Edit за номером один, Geany за номером два и Kate за номером полтора.

Почему столь унижен Kate? Да потому, что, хотя в нём собственные средства управления проектами появились едва ли впервые среди текстовых редакторов такого рода (апологеты Vim и особенно Emacs, подождите немного), по сию пору остаются в зачаточном состоянии. Хотя этот редактор несравненен по части управления файлами, но это — лишь одна из сторон проектного менеджмента. К тому же Kate, будучи приложением KDE, не очень хорошо вписывается в среду Cinnamon.

Между тем Geany, хотя по части управления файлами он и отстал от Kate, все остальные аспекты управления проектами развивались со страшной научно-фантастической силой. И ныне этот некогда просто текстовый редактор именуется обычно лёгкой IDE. Хотя именно вследствие своей лёгкости, то есть — не перегруженности чисто программистскими фичами, он отлично подходит на роль основного инструмента применителя-текстовика.

Однако оказывается, что Komodo Edit превосходит Geany и по части управления проектами (в частности, позволяя одновременно держать открытыми несколько разных), так и в плане файловых манипуляций, включая в себя полноценный файловый менеджер с функциями просмотра изображений. Средства навигации по тексту в нём чрезвычайно изобильны и настраиваемы беспредельно. А уж по части сочинения макросов с ним не может конкурировать ни один текстоый редактор из тех, что я видел.

А что же Emacs и Vim? — спросите вы меня. Отвечаю: это те самые попытки с негодными средствами, о которых я упоминал в начале этой страницы. Да, и из того, и из другого мострактора (монстроидального редактора) можно сделать интегрированную среду для разработки любого рода текстов — от исходников до «нарративников». Но её придётся делать, затрачивая силы и время. А подчас ещё и приобретая по ходу дела некие специфические навыки, например, для Emacs'а — программирования на Lisp. Навыки, которые применителю-текстовику больше никогда и нигде не понадобятся.

Поэтому меня умиляет, когда на всяких форумах на вопрос о выборе текстового редактора технологически продвинутые граждане в качестве универсального решения предлагают Vim/Emacs (в зависимости от своей религиозной ориентации). Для меня это просто показатель непонимания означенными гражданами специфики сочинительской работы. А ведь профессиональный сочинитель воспримет (и воспринимает) такой совет как форменное издевательство. Ибо в том же Geany или Komodo Edit он мог бы иметь всё ему необходимое «искаропки» — хотя он об этом пока и не подозревает.