Воззрения кота Manual’а. Инструменты сочинителя. Общее введение

Алексей Федорчук

manul-logo-100

Однажды юный Карел Чапек обратился к своему почти тёзке и коллеге по ремеслу, Карелу Матею Чапек-Ходу с вопросом: «Как пишутся романы?» На что маститый писатель натуралистического направления ответил: «Сидя, молодой человек».

Вступление

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

Именно свои воззрения на технику сочинительного ремесла кот Manual и изложит на последующих страницах. Ту технику, которая стала возможной с приходом в нашу обыденную жизнь персональных компьютеров, во-первых, возможности запуска на них различных UNIX’а, средства работы с текстами которых мощны и просты, во-вторых, и, наконец, в-третьих, общедоступность и самих UNIX-подобных операционок в лице Linux’а, и всего спектра приложений для них.

Рассказ начнётся с описания примера реального процесса подготовки электронной публикации — достаточно простой, но довольно объёмной. А далее будет рассказано, почему тексты надо готовить в текстовом редакторе, а вовсе не в word-процессоре (по недоразумению называемом текстовым), и о том, какой из текстовых редакторов для этой цели выбрать, и о тех случаях, когда в процесс сочинительства целесообразно вклинить прямые директивы командной строки. Не будет обойдён вниманием и вопрос иллюстрирования текстов.

Однако сначала — вводные установки. Издание материалов «на бумаге» ныне находится в глубоком кризисе (некоторые причины которого изложены в соответствующем цикле). Поэтому большая часть того, что составит предмет следующих очерков, касается в первую очередь публикаций электронных. Это первое. И второе — автор исходит из того, что все описываемые действия выполняются на машине с ОС Linux (дистрибутив которой может быть почти любым), с помощью, по возможности, инструментов с открытыми исходниками, и распространяемых свободно. Последнее, разумеется, не догма, и здравый смысл говорит, что при необходимости следует привлекать и софт проприетарный. Хотя лично у нас с котом Manual’ом такая необходимость за последние 15 лет возникала крайне редко.

Начнём с примера

Итак, условия задачи: некий материал, объёмом около 2 печатных листов (примерно 80 тысяч символов). В формате, разумеется, MS Word’а чёрти какой версии, но понимаемом, например, LibreOffice. Текст достаточно просто отформатирован, разделяется на несколько глав, никак, однако, не размеченных к качестве заголовков. Требуется: привести его к форме, пригодной для размещения на сайте, работающем на движке WordPress, с минимальными затратами сил и времени.

Напрашивающееся решение — считать исходный файл в LibreOffice Writer’е и экспортировать его в HTML — будет далеко не оптимальным: полученный таким образом код будет довольно страшненьким и избыточным, ибо будет дублировать обеспечиваемое движком WP обрамление (DOCTYPE, charset и так далее).

Как ни странно, в данном конкретном случае (очень просто отформатированного документа) приемлемым окажется ещё более простой вариант — Copy&Paste LibreOffice Writer’а в окно редактирования WP, переключённого в текстовый (не визуальный) режим. Это гарантирует от появления «паразитных» тегов, однако всю дальнейшую работу (например, по разметке рубрик) придётся проделывать вручную.

Так что я опишу некий абстрактный метод действий в общем случае — хотя в случае конкретном некоторые из последующих действий могут показаться избыточными. Который предполагает, что скопированный из LibreOffice Writer’а текст вставляется сначала в текстовый редактор. Какой? По причинам, о которых будет сказано в одном из последующих очерков, редактор может быть любым их числа продвинутых — например, Geany, Komodo Edit или Kate. Я в данном случае остановился на первом из этого списка.

Теперь надо расставить теги заголовков для глав, например, <h2></h2>. Это можно сделать автоматически, поиском и глобальной заменой во всём документе, используя Escape-последовательности, благо Geany поддерживает и их, и регулярные выражения. Однако я, параллельно с этим, просто читал текст — не редактирования ради, а исключительно удовольствия души для. И потому пошёл по пути полуавтоматическому, вставляя тег заголовка, когда доходил до очередной главы, с помощью очень простого макроса — Geany поддерживает возможность создания оных просто протоколированием действий. И потому набор макросов для ввода самых употребимых тегов HTML был заготовлен у меня с давних пор.

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

Метод простой и не требующий напряжения, но уж больно скучный. Потому что можно вспомнить три обстоятельства:

  • обрабатывать тексты в формате plain text можно не только в текстовом редакторе, но и с помощью подходящих утилит командной строки (далее — утилит CLI);
  • в текстовом редакторе Geany (и, кстати, в Kate, но, увы, не в Komodo Edit) имеется встроенный терминал, который можно синхронизировать с текущим документом;
  • среди утилит CLI есть одна, которая специально предназначена для разбиения файла на фрагменты, границы которых определяются (почти) произвольным образом.

Имя этой утилите — csplit, и в данном случае её, предварительно синхронизировав пути документа и терминала, можно применить в такой форме:

$ csplit -f moscva60- moskva-60e.txt '/^<h2>/' '{*}'

Результат во встроенном терминале будет выглядеть так:

$ ls
moscva60-00  moscva60-02  moscva60-04  moscva60-06  moscva60-08
moscva60-01  moscva60-03  moscva60-05  moscva60-07  moskva-60e.txt

Нетрудно догадаться, что moskva-60e.txt — это исходный текст, файлы от moscva60-01 до moscva60-08 включают в себя главы соответствующих номеров, а файл moscva60-00 — вступительную часть вне рубрик.

Очевидно, что к циклу из девяти страниц не худо бы добавить оглавление. И это делается, не отходя от кассы терминала, такой командой:

$ echo 'Оглавдение' > moscva60-content

В результате чего к списку файлов текущего каталога добавляется ещё один, moscva60-content. Пока — пустой, если не считать строки заголовка. Но превратить его в болвану оглавления не трудно — понадобится только серия команд вида

$ head moscva60-01 -n 1 >> moscva60-content

И так далее. В результате к файлу moscva60-content будут добавлены первые строки их файлов >moscva60-01, то есть названия глав (в данном случае — просто глава 1, глава 2 и так далее).

За всеми стадиями процесса можно наблюдать в (почти) реальном времени — и во встроенном терминале, и в дереве файлов проекта — Geany предоставляет и ту, и другую возможность:

intro_001

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

Описанное выше — ни в коем случае не догма, и даже не руководство к действию. А лишь достаточно элементарный пример того, как можно работать с уже готовым материалом в формате plain text, чередуя применение функций текстового редактора и команд шелла. Выбор редактора будет рассмотрены позднее. Потому что прежде всего требуется обоснование того, почему для сочинительских целей целесообразно использовать редактор, а не процессор.

Терминологическое введение

Прежде чем переходить к предмету, необходимо сказать несколько слов о терминологии, ибо она часто является предметом недоразумений. Во-первых, сразу оговорюсь, что в эти очерки посвящены исключительно работе с «мирными», то есть нарративными (повествовательными) текстами, от заметок и статей до романов и монографий. О сочинении программ, которые изначально также пишутся в виде текстов (так называемых исходников) здесь не будет говориться ни слова.

Во-вторых, далее речь пойдёт о двух разновидностях софта для работы с нарративными текстами. Первая из них объединяет программы, которые так и называются — текстовые редакторы (text editors). Они служат для набора текстов и их редактирования. Результат работы в них сохраняется в виде обычного текста (plain text) или в виде документов, содержащих разметку в одном из языков, специально для того предназначенных — TeX, HTML, Markdown etc. Которые, для отличия от языков программирования, именуются языками разметки.

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

Вторая разновидность программ работы с текстами на вражьей мове называется word processor’ами. Поскольку на Руси импортозаместители водились ещё в те далёкие времена, когда об импортозамещении никто и не слыхал, в русскоязычной литературе за такими программами закрепилось исконно славянское имя «текстовые процессоры», что в корне неправильно.

Дело в том, что текстовые процессоры (text processor) — это совсем отдельный класс программ, также предназначенных для работы с текстами. Но в них тексты не набирают и не редактируют, они осуществляют неинтерактивную обработку уже набранных и должным образом размеченных документов. Наиболее известными примерами настоящих текстовых проце+ссоров являются groff или тот же TeX.

Что же до word-процессоров (за неимением лучшего (придётся использовать этот корявый термин, благо поминаться они далее будут не часто), то это программы, объединяющие функции набора и редактирования текстов, их интерактивного оформления и моментальной визуализации результатов оного, работающие в так называемом режиме WYSIWYG. За примерами далеко ходить не нужно: это MS Word из комплекта MS Office и модули по имени Writer из аналогичных наборов LibreOffice и Apache OpenOffice. Полноты картины ради можно упомянуть также считающийся лёгким Abiword и своеобразный «процессор документов» LyX.

В отличие от редакторов, результаты работы в word-процессорах (которых ещё иногда уж совсем не по чину тоже величают редакторами) сохраняются в файлах собственного формата. Конечно, они тоже основаны на языках разметки — потому что больше им не на чем основываться. Так, формат ODT, умолчальный для обоих «открыто-свободных» офисов, и docx из современного Word’а, представляют собой компрессированный XML-файл, который в принципе можно выковырять и редактировать напрямую (иногда такая необходимость возникает), в основе LyX’а упрятан TeX, старые word-процессоры, ныне практически вышедшие из употребления, основывались на каких-то вариантах SGML. Ну а на чём основывается формат doc из прежних версий MS Word, который до сих пор в ходу — одному Ахурамазде ведомо.

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

Текстовый редактор или word-процессор?

Прояснив разницу между текстовыми редакторами и word-процессорами, пора перейти к теме выбора между инструментами того или другого класса. И на первый взгляд ответ здесь очевиден, да ещё и подкрепляется традицией, сформированной годами засилья Windows. В которой текстовый редактор (в виде убогого Notepad’а, присутствующего в системе по умолчанию) представляется средством для составления мелких и несерьёзных текстиков. Тогда как могучий MS Word, да ещё в обрамлении своих офиных собратьев, кажется специально созданным для работы настоящими Текстами и даже Текстищами.

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

Тому в сети мы тьму примеров сыщем,
Но мы про Windows не пишем.
А вот дела как наши обстоят.

А наши, то есть Linux’овые, дела обстоят с точностью до наоборот: текстовые редакторы широко применяются в самых серьёзных проектах, тогда как word-процессорам обычно отводится скромная роль инструментов для создания всякого рода бюрократических бумажек, а также для обмена материалами с применителями Windows. Почему? Тому есть несколько причин.

Первая из них — так сложилось исторически. Первыми применителями Linux’а были в основном разработчиками софта и системные администраторы. А и для тех, и для других текстовый редактор является чуть ли не главным орудием производства, поскольку самый мощный и функциональный word-процессор не пригоден ни для написания исходников программ, ни для правки конфигурационных файлов. И потому когда и программистам, и сисадминам по жизни требовалось сочинять обычные тексты, им чисто психологически было проще не разучивать специально для этой цели какой-либо word-процессор. А обратиться к «знакомым пистолетам». То есть любимому текстовому редактору, например, Emacs’у или Vim’у.

Предвижу возражение: но данный-то цикл посвящён технике составления нарративных текстов. И разве не специально для этого создавались word-процессоры?

Ответом на это будет вторая причина. Мне психологически трудно представить инструмент, менее подходящий для банального набора текстов «из головы», чем любой word-процессор: уж слишком в нём много отвлекающих факторов, так и провоцирующих заниматься не сочинительством, а украшательством.

Согласен, это во многом вопрос самодисциплины. И надо приучиться давать себе по рукам всякий раз, когда вместо сочинения очередной страницы бессмертного романа или катрена гениального стиха тянет поменять шрифты, отцентрировать заголовки и так далее. Или даже, достигнув определённого минимума квалификации в обращении с word-процессором, начинать присваивать стили разным фрагментам сочиняемого текста.

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

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

Так что без каких-то элементов форматирования смог бы обойтись разве что Джеймс Джойс с его «потоком сознания». Но при использовании word-процессора приходится всё время себя ограничивать. Конечно, приучиться к этому можно, но надо приучаться.

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

intro_002

Конечно, возможность эта есть и у пользователя word-процессора — но он имеет хороший шанс утонуть в изобилии уже предопределённых хоткеев, большая часть которых ему, скорее всего, не понадобится никогда в жизни.

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

Для документов, созданных в любом word-процессоре, это не так просто. Ряд из них практически невозможно прочитать вне «породившей» программы или специальных конверторов (которые не всегда имеются). Представители информационно старшего поколения помнят мучения, которые испытывались при попытках доступа к файлам из таких некогда популярных word-процессоров, как Chiwriter или WordPerfect, особенно их «наколенно-локализованных» модификаций. Эти же сложности сейчас можут возникнуть и с doc-файлами прежних версий MS Word.

Конечно, ныне, с распространением формата ODT и внедрением в MS Word сходного по устройству формата DOCX, проблема так остро не стоит: если жареный петух клюнет — и те, и другие файлы можно распотрошить и прочитать как тексты, размеченные в XML. А если петух клюнул в интимное место, даже отредактировать и собрать обратно. Однако, как было показано в одном из примеров, удовольствие это существенно ниже среднего.

Наконец, причина четвёртая (но ещё не последняя): с документами текстовых редакторов можно работать в пакетном режиме, с помощью классических UNIX-утилит обработки текстов, которые и создавались для автоматизации часто повторяющихся действий. Во втором очерке цикла я пытался показать (хотя и не на самом впечатляющем примере), что прямые командные директивы прекрасно дополняют работу в редакторе. Для файлов же в форматах word-процессоров это невозможно.

Подведу итог. Текстовые редакторы специально создавались для работы с текстами, в том числе большими и иногда сложно структурированными, и с этой задачей они прекрасно справляются. Назначением же word-процессоров изначально было создание офисных (и всяких прочих) документов, оформленных в соответствие с общепринятыми правилами — вспомним «резинового Полыхаева» с его бессмертным шаблоном любой резолюции.

Так что пятая причина применения текстовых редакторов в сочинительском ремесле — самый обычный здравый смысл: офису оставить офисово, но сочинителево воздать сочинителю.

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

Классификация редакторов

Итак, основные инструменты для работы с текстами были разделены на текстовые редакторы и word-процессоры, и сделан выбор в пользу первых. Из которых тоже надлежит выбрать наиболее подходящего для сочинительских целей представителя. Однако прежде давайте посмотрим, какие вообще бывают редакторы. Для чего расклассифицируем их. Что можно сделать по двум независимым критериям — режиму работы и полноте функционала.

По первому критерию традиционно выделяются так называемые «консольные» редакторы (столь же условно именуемые «редакторами текстового режима») и редакторы режима графического. В первом случае определение взято в кавычки, потому что нынче «консольные» редакторы запускаются обычно в Иксовых терминалах, да и «голая» консоль в большинстве современных дистрибутивов поддерживает графику через frame buffer (подробнее об этом говорится во введении к соответствующему Manual’у). Так что главных различий между двумя этими группами, с точки зрения применителя, два:

  • «консольные» редакторы, как только что было сказано, запускаются в терминальном окне, обычно прямой командой, редакторы графического режима — в собственных окнах, и, как правило, через меню;
  • в «консольных» редакторах, в отличие от редакторов графического режима, мышь работает не столько как указательно-позиционирующее устройство, сколько как средство выделения, копирования и вставки фрагментов текста.

Оба эти фактора достаточно условны. Так, «консольный» mcedit можно запустить из меню, а, скажем, Kate — одноимённой командой в терминале. А мышь в некоторых «консольных» редакторах, собранных должным образом, может обрести «указательно-позиционирующие» свойства.

Важно, однако, что в «консольных» редакторах не поддерживается перетаскивание мышью, вовсю используемое в редакторах графического режима. Хотя тоже не во всех — например, в Atom’е эта функция отсутствует как класс.

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

Наиболее известными представителями «консольных» текстовых редакторов являются nano, vim, emacs. Среди редакторов графического режима можно назвать такие имена, как Gedit, Kate, Geany и многие другие.

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

intro_003

А среди реакторов графического режима к таким базовым редакторам можно отнести Mousepad для среды Xfce, Write из KDE или «внедесктопный» Leafpad: все они не поддерживают вкладок и не имеют функции разделения окна. То есть для параллельной работы с двумя и более файлами приходится запускать по экземпляру программы. Об отстутствии более «продвинутых» можно и не говорить.

Во второй, промежуточной категории редакторов их базовый функционал может быть расширен с помощью дополнительных плагинов и (или) пользовательских макросов. В «консольном классе» к таким промежуточным редакторам относятся joe и mcedit:

intro_004

В «графическом классе» представителями редакторов промежуточного уровня являются Gedit, его клоны Pluma и Xed:

intro_005

Ко второй же категории редакторов следует отнести Kate для среды KDE — базовый функционал его, хотя и весьма обильный, лишь ограниченно расширяется за счёт сторонних средств. Хотя имеющиеся зачатки средств управления проектами сближают Kate с третьей категорией.

Наконец, третья категория файловых редакторов — «продвинутая». Её представители отличаются и расширенным собственным функционалом, и большим количеством доступных плагинов, и, в первую очередь, поддержкой проектов различной сложности. Благодаря сочетанию этих особенностей «продвинутые» текстовые редакторы часто относят к категории «лёгких» IDE (Integrated Development Environment — интегрированная среда разработки). Однако, как мы увидим со временем, в не меньшей степени они подходят и для серьёзных сочинительских задач.

Представителей «продвинутой» категории в «консольном классе» два — vim и emacs. И споры о том, кто из них является «более продвинутым», не утихают вот уже третье десятилетие. Однако по причинам, изложенным в следующем очерке, мы в них вступать не будем.

Представителей «графического класса», претендующих на «продвинутость», гораздо больше — например, к этой категории относят упомянутые выше Gedit и Kate. Однако по настоящему обоснованы эти претензии со стороны трёх кандидатов: Geany, Comodo Edit и Sublime Text. Однако в последнее время на место в этой категории нацелился и редактор Atom:

intro_006

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

Выбор редактора

В принципе, сочинять тексты можно в любом редакторе, даже в Nano или Leafpad’е. Особенно если речь идёт о сочинение небольших и сюжетно не связанных заметок. Однако как только дело доходит хотя бы до цикла как-то связщанных статей, не говоря уже о книжках, оказывается, что ни один редактор начального уровня не обеспечивает комфортной работы. Ибо тут требуется какое-никакое управление проектами.

По этой причине из рассмотрения можно исключить и почти все редакторы промежуточного типа. За, пожалуй, двумя исключениями. Первое — консольный редактор Joe с его развитой системой протоколирования макросов и интеграцией с CLI, что позволяет реализовать управление проектами своими силами. Второе же исключение — редактор графического режима Kate, в котором управление проектами, хоть и в зачаточном виде, имеется. Однако по настоящему кофортно сичинительскую деятельность лучше организовывать в редакторах «продвинутых».

На форумах Linux-тематики вопрос о выборе редактора обсуждается достаточно часто. И тут непримиримые классовые противники, сторонники Emacs’а и Vim’а, проявояют удивительное единодушие, однозначно рекомендуя сыой любимый инструмент на все случаи жизни. Мы с котом Manual’ом ввязываться в вековой спор на тему Emacs vs Vim не будем. Потому что, на наш взгляд, оба эти редактора — не самые удобные инструменты для повествовательного сочинительства.

Почему? Говорить на эту тему можно очень долго. Так что отмечу только самое главное: эффективное использование и Emacs’а, и Vim’а в сочинительских целях возможно только в том случае, если их кейбиндинги впечатались в кору головного мозга на рефлекторном уровне. Впрочем, это относится ко всем «консольным» редакторам.

Так что далее речь пойдёт только о «продвинутых» их представителях, работающих в графическом режиме. Как уже было сказано, список таковых включает четыре позиции: Atom, Sublime Text, Geany и Komodo Edit.

О первом из них я мало чего могу сказать — Atom для меня оказался неприемлемым по трём причинам:

  1. невозможности изменить шрифты интерфейса (а «прошитых» я просто не вижу);
  2. отсутствию drag&drop’а;
  3. неудобству ввода тегов HTML.

Хотя он имеет минимум один безусловный плюс — удобную работу с файлами из нескольких проектов параллельно. Так что для тех, кого три перечисленные особенности не критичны, он может быть хорошим выбором. Скачать его в виде deb- или rpm-пакета, а также абстрактного тарбалла, можно с официального сайта. На котором имеются также версии для Windows и Mac OS X.

Редактор Sublime Text пользуется популярностью среди Macintosh’ников и примкнувших к ним Linux-программистов. И популярность эта, в целом, заслужена. Кроме развитых функций редактирования, в Sublime Text существует весьма развитая поддержка проектов:

intro_007

Заслуживает быть отмеченной лёгкость переключения между существующими проектами:

intro_008

Удручённые траурностью умолчальной цветовой схемой могут подобрать себе что-нибудь более жизнерадостное:

intro_009

Вообще-то настройки внешнего вида выполняются прямым редактированием конфигурационного файла ~/.config/sublime-text-3/Packages/User/Preferences.sublime-settings. Однако эту процедуру можно проделать в отдельном окне самого редактора. При этом в левом фрейме его будет выведена достаточно подробная подсказка, что именно можно менять:

intro_010

Настройки внешнего вида можно установить отдельно для каждого проекта, если это требуется.

Важно, что Sublime Text прекрасно справляется с большими (2 и более мегабайта) файлами в разметке, например, HTML, на которых вязнет Komodo Edit (но не Geany).

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

Кроме того, следует учесть что Sublime Text — программа не только не свободная, но и, строго говоря, не бесплатная: стоимость лицензии составлят 70 долларов. Правда, с официального сайта её можно скачать абсолютно безвозмездно. Для Linux’а она доступна в виде абстрактного тарбалла и deb-пакета для Ubuntu’идов, в сборках для 32- и 64-разрядной архитектуры. Там же имеются и версии для Mac OS X и Windows.

Бесплатная версия Sublime Text не имеет никаких функциональных ограничений или «сроков давности». Единственная её особенность — написанное большими буквами слово UNREGISTERED в заголовке окна, постоянно напоминающая о том, что не худо бы обзавестись лицензией.

Но надпись, как известно, глаза не выест. И для нас с котом Manual’ом причиной, по которой мы не стали глубоко вникать в особенности Sublime Text, была не она, и даже не стоимость лицензии. А то, что в этом редакторе мы не обнаружили ни одной особенности (из числа нужных нам), которой не было бы в свободных и бесплатных Geany и (или) Komodo Edit. Причём аналогичные функции в них реализованы ни разу не хуже, а часто и лучше.

Например, по части управления проектами и входящими в них файлами Sublime Text далеко до Komodo Edit. А по части навигации по проекту и внутри открытых его файлов пальму первенства безусловно держит Geany. Который, кроме того, единственный из всех четырёх (включая Atom) «продвинутых» редакторов имеет встроенное терминальное окно, незаменимое при совместном использовании с утилитами CLI. В этом отношении с ним может соперничать только упомянутый выше Kate.

Предварительное заключение

Таким образом, осталось всего два претендента на пост главного редлактора для сочинителя — Geany и Komodo Edit. И оба они, по нашему, с котом Manual’ом, мнению, заслуживают этого высокого звания. Какой больше — можно будет определить только после более подробного с ними знакомства, которое произойдёт в следующих очерках. А пока кратко перечислим те их особенности, которые представляются нам наиболее востребованными. А также отметим отдельные их недостатки — а у кого их нет?

Сильной стороной Komodo Edit (далее — KE) является его абсолюная настраиваемость. В частности, это касается клавиатурных комбинаций. Если в Geany многие из них уже задействованы как системные, то KE позволяет переопределять последние под собственные цели применителя почти без ограничений.

Настройки и Geany, и KE глобальны, по умолчанию распространясь на все файлы и проекты. Однако в обоих редакторах для каждого файла можно установить собственные настройки, если это конечно, нужно. А вот установить разные настройки внешнего вида для отдельных проектов, как в Sublime Text, не получится. Хотя в Geany можно задать такие свойства отдельного проекта, как ширина строки, величина табуляции, замена табуляции проблемами.

Управление проектами и входящими в них файлами в обоих редакторах — на высоте, хотя и реализовано чуть по разному. Однако и в Geany, и в KE можно создавать, переименовывать и удалять файлы, как в обычном файловом менеджере. В Geany имеется встроенный терминал. Кроме того, в нём из дерева проектов можно открыть и терминал внешний. Обе эти функции в KE, увы, отсутствуют. Зато уникальной функцией KE является встроенный вьювер изображений.

Далее, макросы. Они поддерживаются обоими редакторами, и в обоих могут создаваться просто протоклированием своих действий, с последующим редактированием (или без оного). Однако в KE к протоколированию приходится прибегать не так уж часто. В частности, для ввода HTML-разметки в нём штатно содержится изрядное их количество. Возможно, потребуется только немножко адаптировать их под свои задачи. И, конечно же, приписать им удобные и привычные хоткеи. В Geany создание макросов всегда надо начинать с нуля, то есть с протоколирования действий, нуждающихся в автоматизации.

В KE список макросв, как штатных, так и собственных, можно вывести в одной из боковых колонок (по умолчанию — в правой) и запускать их непосредственно оттуда. В Geany боковая колонка всего одна, которая также может располагаться с любой строны. Однако в ней в отдельных вкладках можно вывести не только файловое древо, но и список отрытых документов или, например, заголовочныъ тэгов для файлов с HTML-разметкой.

intro_011

Пользовательские макросы и в Geany, и в KE сохраняются в их конфигурационных каталогах (~/.config/geany/ и ~/.komodoedit, соответственно), и могут переноситься в инсталляции любых других дистрибутивов. Причём в KE это делается абсолютно безболезненно. Не приходилось сталкиваться и с отказом какого-либо пользовательского макроса после обновления версии программы. А вот в Geany это имело быть неоднократно, причём даже при изменении минорных версий.

Неусточвиость работы макросов — пожалуй, один из главных недостатков Geany. Второй же — неумение окружать выделенный текст тегами, вводимыми с помощью макросов, с чем прекрасно справляетс я KE.

Впрочем, у KE тоже есть свои важные недостатки, не считатя даже отсутствия встроенного терминала и невозможности вызвать терминал внешний. Первый — отсутствие проверки орфографии «на лету», с подсветкой ошибок, даже для английского языка, не говоря уже о русском. С чем, впрочем, можно примириться.

Более важно то, что KE плохо работает с большими файлами с какой-либо разметкой. В частности, HTML-файл файл размером от 1 МБ и более он воспринимает как palin text, то есть в нём напрочь пропадает подсветка тегов. Что, конечно, не смертельно — макросы для ввода последних продолжают работать. Однако — не приятно, и именно для больших html-текстов.

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

[Общее содержание]

Оставить комментарий

Перейти к верхней панели