Я -- увы -- решил забить на попытку слезть с emacs'а на cudatext. Я напишу сюда почему так, не с целью поспорить о вкусах фломастеров или объяснить, что вы делаете всё не так -- нет, я отдаю себе отчёт, что вы не пытаетесь повторить emacs, -- я это сделаю в надежде, что может быть это как-то покажется полезным вам. Если не покажется, то простите за стену текста, которую вам пришлось читать.Во-первых, когда я запустил cudatext и попытался им пользоваться я столкнулся с кучей вещей, которые работают не так или просто не работают, много непривычностей, которые воспринимаются как неудобства. Я ждал именно такого и был готов одолевать непривычности посредством тонкой настройки текстового редактора или ломанием привычек. И я был готов к необходимости ломать привычки в большом количестве. Но в конечном итоге я нашёл две отсутствующие фичи, без которых я не очень представляю как жить.
0. Это не киллерфича, но мне кажется надо объяснить проблемы с установкой, с которыми я столкнулся, которые, полагаю, всё ж больше проблемы gentoo, нежели cudatext или lazbuild. То есть мне так и не удалось получить seamless experience при сборке -- я пересобирал его ещё пару раз, и при самой хорошей попытке мне пришлось лишь один раз запускать lazbuild вручную для сборки bgraimagepack -- почему-то он так и не собирался скриптом. Но всё остальное собралось и подцепилось при сборке cudatext.
Я нашёл там пачку скриптов промеж сорцов, не разбирался с ними, но было бы круто там иметь скрипт install с аргументом --install-root=<dir>, чтобы все файлы нужные для работы cudatext были бы отделены от того, что не нужно, и разложены по директориям. Чтоб затем я мог бы закончить установку так, как считаю нужным. Скажем скопировать всё это дерево в ~/local, где у меня есть ~/local/bin, ~/local/share, ~/local/lib, и переменные окружения настроены так, чтоб оно всё оттуда подцеплялось бы. Сложно сказать как сделать, чтобы cudatext находил бы свои файлы там: он умеет находить относительно расположения бинаря, и это в принципе ничотак подход. Можно его дополнить опцией командной строки/переменной окружения (типа --install-root=$CUDATEXT_PATH), чтобы прямо направить его куда надо. Это решит все проблемы потенциальных мейнтейнеров, которые захотят собрать пакет для любого дистра, как бы там им не хотелось разложить файлы cudatext по файловой системе: через install-root cudatext найдёт свой конфиг, а в конфиге можно хоть что понаворотить.
1. Автоиндент. Я _не_представляю_ как люди живут без этой фичи. Это же постоянное отсчитывание пробелов глазами. Опеннет очень любит обвинять python, что он приводит к такому, я никогда не понимал этого, а сейчас я заподозрил, что опеннет пробовал python в блокноте. Да, без автоиндента жизни нет. И не только в пайтоне.
Автоиндент позволяет сконцентрироваться на написании кода, а идентация отдельных строчек -- это следствие синтаксиса, который я пишу (даже в пайтоне: я пишу "if блаблабла:" нажимаю enter и курсор на следующей строке стоит в столбце на один tab вправо относительно положения if, и я даже не знаю как текстовый редактор достиг этого: вставлением пробелов или tab'ов -- это не моя проблема, хотя, конечно, это конфигурируется, если надо). То есть это можно использовать (и я использую) для грубой проверки синтаксиса: если я где-то обсчитался со скобочками (не важно какими {}()[]<>, или даже begin/end, любыми которые описаны в mylang-mode как скобочки), то у меня "поедет" идентация следующих строк, и это будет сложно не заметить. Забытые/лишние , и ; иногда выявляются таким способом (была забавная ситуация с вопросом студента: "почему цикл не отрабатывает ни одной итерации", я скопировал текст в emacs, и не мог понять в чём дело, пока случайно не триггернул emacs'овый автоиндент на строчке следующей за "for(i=0; i<N; i++);", автоиндент поставил однострочное тело цикла на уровень for'а, и я такой "чтоза?!... ахтыжматьтваюзаногу..."). В пайтоне так забытые/лишние ":" выявляются.
Мне не надо отсчитывать пробелы -- если я написал my_func(arg1, arg2,..., argN,) и решил argM написать с новой строки, то выровнять этот argM на нужный столбец -- это задача текстового редактора. Мне не надо тыкать в tab, подбирая выравнивание так, как надо.
Кстати некоторые emacs'овые режимы меня бесят, скажем режим для pascal'я выравнивает не просто добавляя пробелов в начале строки, он начинает выравнивать, скажем, декларации переменных в блоке var так, чтобы все ':' находились бы в одном столбце. Получается красиво, но это вкус фломастеров. Наверное, это можно настройками исправить, но я не к тому, что pascal-mode плохой, а к тому, что можно делать за программиста _ещё_ больше. Но много не обязательно, главное чтобы в начале строки нужное количество tab'ов и space'ов было вставлено само тогда, когда я начал новую строку, или когда я тыкнул в tab, чтобы выровнять строку явно.
1a. Это не одна из двух "ломающих" фичей, просто мелочь в довесок к автоинденту. Когда я в emacs'е пишу )}>], то есть любую закрывающую скобку, он подсвечивает соответствующую открывающую скобку. Это может не очень важно в языках типа C, Pascal, rust, java (в них это полезно, но редко), но в lisp'е, для которого нормально иметь в сорце много вхождений строки ))))), это просто киллер-фича: я всегда знаю какую скобку я только что закрыл. Если я запутался, я могу удалить ))))), и написать заново наблюдая за мерцанием подсветки на экране. Я не знаю как без этого можно писать на lisp'е. autoindent по идее должен помочь, но в lisp'е с этим проблемы: там, как правило, выходит много уровней вложенности, поэтому в качестве размера табуляции используется всего два пробела, и если я работаю со структурой в полэкрана размером по высоте, то бывает очень сложно понять, на каком из уровней сейчас находится курсор.
2. Невозможность тайлового расположения файлов. Я очень часто использую два одновременно отображённых файлов на экране. Я нашёл в cudatext возможность split tab, но это split TAB, не split window. Это удобно для того редкого (но несомненно важного) случая, когда я хочу один и тот же файл в двух разных местах видеть, но это неприменимо к случаю, когда я хочу два места двух файлов видеть. Я смотрел видяшку на ютубе, и неверно её понял, подумал что этот split создаёт два подокошка, и в каждом свой набор вкладок. Мне показалось это стрёмно: вкладку можно отображать только в одном из окошек? А если я захочу отобразить два файла из одного набора вкладок? Но с другой стороны мне показалось, что это будет круто: у каждого окошка список табов поменьше и одни и те же файлы отображаются в одних и тех же окошках: проще искать нужный открытый файл. Хотя вот сейчас я думаю: а как же при таком подходе при этом один и тот же файл открыть дважды?
2a. И я не нашёл способа с клавиатуры переключаться между разными подокнами. Надо тянуться за мышкой и кликать ею. В emacs'е shift со стрелками позволяет прыгать между окнами, и это удобно.
Ну и так, по-мелочи.
Поиск по сути своей неинкрементальный. К нему запилена возможность использовать его как инкрементальный, но она приделана задним числом и неудобна. Очень удобно когда строка ищется по тексту по мере набора этой строки (да, это не работает с регекспами, и поэтому поиск регекспами я использую как last resort). Очень удобно, когда подсвечиваются _все_ вхождения строки попадающие на экран. (Хотя с учётом minimap, может быть стоит подсвечивать вообще все). Очень удобно иметь на клавиатуре клавиши "вперёд"/"назад", которые можно нажимать вперемешку с символами (добавляющимися к строке поиска), не заботясь о том, что уже набранная строка поиска оказывается выделенной, и поэтому любое неудачное нажатие не допишет символ к строке поиска, а заменит строку поиска на этот символ. С этим я в принцип был готов смириться, думая, что если сломать привычки не удастся, то я пропатчу тот поиск который есть, чтобы он норм работал. По-хорошему ведь, надо лишь поменять кейбинды; отломать выделение уже набранного; при каждом нажатии "не кейбинда", менять поисковую строку и делать find-next и позиционировать курсор на начало находки (хотя хочется ведь возможности произвольно миксовать find-next и find-prev, и может с позиционированием курсора пришлось бы сложнее как-то решать); а при нажатии esc возвращать курсор туда, откуда всё началось. Ну и ещё какой-то способ добавить остановить процесс поиска с курсором там, где он сейчас находится. Это я б сделал за вечер хаков, не проблема.
Я не нашёл как сделать, чтобы клик средней кнопки мышки не переставлял бы курсор в тексте. В результате из буфера выделения вставляется не туда где курсор, а туда куда я ткнул мышкой. С учётом того, что я мелкие шрифты использую, сложно попасть мышкой куда надо, надо как следует прицелится. Удобно разделять прицеливание и вставку: сначала левой кнопкой позиционировать курсор, средней кнопкой вставить. Но эта фишка, я думаю, мало кому нужна: emacs тоже это по-дефолту неправильно делает.
Ещё раздражает untitled. Зачем он нужен? То есть, он не мешает в принципе -- одной вкладкой больше или меньше, какая фигня. Но cudatext каждый раз спрашивает при выходе "сохранить ли untitled". Нет конечно, не сохранять. Я ведь даже не менял этот файлик, он _неизменённый_, можно ведь догадаться, что не надо его сохранять? И, кстати, было бы удобно при закрытии cudatext получить список изменённых файлов, чтобы с каждым можно было бы разобраться исходя "сохранить/вышвырнуть изменения/оставить изменения на будущее".
А, кстати, он не смог найти libpython3.so в моей системе, легко исправляется правкой конфига, то есть не проблема, но его легко найти в любой системе, сделав, например, что-нибудь типа:
$ python3-config --libs | sed 's|.*-l\(python[^ ]*\).*|\1.so|'
python3.6m.so
Сложно сказать когда это надо делать, потому что если сделать при сборке cudatext, то потом python обновится, и имя dll сменится. Но с другой стороны, вполне норм при обновлении системы пересобирать весь софт, зависящий от обновлённых dll. При этом, я полагаю, будут проблемы написать скрипт, который обновляет конфиг при старте cudatext, потому как для запуска такого скрипта будет нужен python3.so, который собственно нужно найти.
