Если вы пробовали вкатиться в GNU Emacs, расскажите, что пошло не так

multiple-cursors.el

У меня в ~/.bash_aliases команда для этого тоже есть. Но я часто конфиг меняю, когда для книги какие-то фишки описываю, так что мне можно.

Ух, я аж статью на тему написал однажды: Вы неправильно настраиваете Emacs: не пытайтесь сделать из него что-то другое.

Да, я читал.

Поддержка LSP

Eglot «из коробки» с версии 29.1

проверка орфографии

Flyspell из коробки, Jinx сам поставишь.

возможность свернуть функции

hs-minor-mode из коробки, просто выучи последовательности.

Eglot «из коробки» с версии 29.1

Как сейчас не знаю, на 29.1 это нормально не работало.

Flyspell из коробки, Jinx сам поставишь

Flyspell я отключил, мой пк его не вывозит. На попытки полноценно прикрутить проверку орфографии к емаксу я потратил часов 10. Не вышло, это была познавательная экскурсия по утилитам и словарям в линуксе, и как проверка орфографии в редакторах работает. Теперь могу сам спелчекер написать для какого-нибудь helix-а.

Сложность в том, что пытаясь загуглить свои проблемы с проверкой орфографии ты натыкаешься на мешанину из разных рецептов в сети разной степени актуальности, которые копились там годами. Приходится погрузиться в историю развития спелчекеров в линукса, понять что такое ispell, aspell, hunspell, а потом вникать в особенности реализации в емаксе.

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

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

В этом вся суть юзер экспириенса при использовании емакса. И чем больше у тебя в нём накручено, тем жизнь становится интереснее. Спелчекер, lsp? А как насчет того, чтобы они вместе нормально работали? Кому багрепорты в этой ситуации слать?

Открываешь вот это: https://www.emacswiki.org/emacs/FlySpell

И это малая часть от того, что придется прочитать и во что придется вникнуть во время многократных подходов по тюнингу спеллчека.

Ух, я аж статью на тему написал однажды: Вы неправильно настраиваете Emacs: не пытайтесь сделать из него что-то другое.

Вот поэтому у меня нет надежд на емакс и я просто продолжаю использовать его местами по инерции. С балластом виде исторически сложившихся привычек сообщества он с каждым годом всё больше будет отставать от других редакторов.

• В отличие от фреймов, окна можно использовать даже в том случае, когда Emacs запущен в терминале.

Если было бы нельзя использовать фреймы, то зачем бы тогда нужно было меню Frames при работе с -nw ? 🤔

c==>*Completions*  *%
f==>Frames
n==>Next Buffer  C-x <right>
p==>Previous Buffer  C-x <left>
S==>Select Named Buffer...  C-x b
l==>List All Buffers  C-x C-b
0==>Select Buffer In Project...  C-x p b
L==>List Buffers In Project...  C-x p C-b

Зачем тогда нужна такая среда.

Конгениально! Ни за чем она не нужна, бинго!

Это не просто приложение, которое экспортирует API для плагинов. Это среда программирования

манипуляция терминами никак не отменяет того факта, что будь это хоть среда, хоть пятница, это было, есть и останется говном собачьим

Я пользовался емаксом довольно долго. Когда пытаюсь вернуться, то больше всего бесят громоздкие регулярки. Да, я знаю, что есть пакеты, которые добавляют нормальный синтаксис.

Пользовался geany. В geany есть (на мой взгляд) киллер фича: по F5 соберёт\запустит любой код в новом окне терминала будь то C++, perl, bash, python и т.д. без предварительной настройки … очень удобно когда из редко пишешь код (не забыть установить xterm и сделать chmod +x file ).

В рамках самообразования решил изучить emacs как редактор кода. Запасся шпаргалками, почитал про лучшие практики и компетенции, смотрел видосы Прота по emacs … ))) … Попытался реализовать сборку\запуск кода по F5 но мне как новичку это сделать не удалось … вернулся на geany.

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

В общем emacs это как то муторно, требует изучения, обкатки, внедрения … Для меня очень сложно … ((( …

про Jinx не слышал

По сути вы правы, это костыль.

EmacsWiki

Моя книга начинается с этого:

EmacsWiki

Не путайте с WikiEmacs и никогда, ни при каких обстоятельствах не пользуйтесь материалами с этого ресурса!

Причины:

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

Короче, ссылаться на EmacsWiki - плохая идея и не аргумент в споре.

В режиме сервера Emacs может работать и в терминале, и в GUI одновременно. Почему бы не подключиться из терминала и не создать фрейм, раз GUI доступен?

Не вижу противоречий.

Не удалось реализовать сборку / запуск кода по F5

В старых Emacs:

(global-set-key (kbd "<f5>") 'compile)

Если у тебя новый Emacs (29+), то ещё проще:

(keymap-global-set "<f5>" 'compile)

В общем emacs это как то муторно, требует изучения, обкатки, внедрения

Да.

Да, для тех, кто уже знает язык редактирования vi/emacs. Но мне кажется, что разница не велика.

Может и не велика. Но и камешек в ботинке тоже не велик. Но выводит из себя неимоверно. Когда в каждом, вообще в каждом случае знаешь, что та же задача в emacs’е решается быстрее и лучше, использование Acme становится формой аскезы, если не самоистязания.

могу выразить всё то же самое без специального языка,

Не можете. Чтобы магия сработала вам точно так же нужно написать некий скрипт, на некоем языке.

Я так держу команды Def Ref Impl Form Watch go vet в самом начале файла, который всегда открыт в самом верху. Переход к определению сводится к нажатию на символ и аккорду 2-1 на Def.

Отличный трюк, не спорю. Но это 6 (шесть) команд. А в emacs’е их тысячи. Из которых нужны и пользуются — сотни.

Не вижу противоречий.

Если Emacs запущен в терминале, а «GUI» доступен только как tui в этом терминале, что нам мешает создать несколько фреймов, и переключаться между ними в этом терминале?

В чем смысл этого противопоставления?

• В отличие от фреймов, окна можно использовать даже в том случае, когда Emacs запущен в терминале.

Когда Emacs запущен в терминале, мы можем открыть файл в текущем окне, выделить для него новое окно, или создать для него отдельный виртуальный экран(фрейм). Разве нет?

Emacs и vim это лень во первых, ты годами точишь конфиг и учишь хоткеи чтоб получить то, что даже vs code умеет без лишнего секса, а самое интересное умеет делать это лучше. Про луддитов сидящих в телеге/лоре/почте из имакса я молчу. Во-вторых, у меня сложилось стойкое впечатление, что если хочется быть прям ъ ымаксером надо так или иначе изучать elisp

Emacs и vim это лень во первых,

Vim для ленивых, а Emacs таки для очень ленивых:

ты годами точишь конфиг …

Чтобы по одному аккорду форматировать текст в целой книге, и вот это все (Emacs = Editing Macros).

Во-вторых, у меня сложилось стойкое впечатление, что если хочется быть прям ъ ымаксером надо так или иначе изучать elisp

Кэп подсказывает, что в 70-х LISP был естественным пререквизитом в среде, откуда вырос EMacs.

Короче, ссылаться на EmacsWiki - плохая идея и не аргумент в споре.

Эти пункты - неизбежная реальность во время поиска решений при проблемах с емаксом. У всех свой емакс, с самописными костылями и плагинами. И они копятся десятилетиями.

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

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

А конфиг=код и переписывание редактора приводят к тому, что эти решения, по сути, накапливающиеся патчи к программе. И эти патчи люди по началу накладывают на оригинальный емакс, а потом уже на свой собственный. Когда приходят изменения и появляются решения лучше им часто сложно или не до того, чтобы пересмотреть свои патчи на программу, отказаться от устаревших подходов и переделать всё «правильно». Ему проще адаптировать своё устаревшее решение так, чтобы оно продолжило работать. И это всё копится в сети.

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

Если обобщить, то ПО в котором конфиг это код и через него можно это ПО переписать ведет к тому, что твой конфиг начинает вникать в реализацию этого самого ПО и обрастать уникальными решениями. Такими решениями тяжело делиться и по мере формирования сообщества это создаёт проблему для разработчиков. Они теперь не могут что-либо кардинально поменять в ядре, так как у сообщества построен замок на его внутренних особенностях. Разработчики вместо нормальной перестройки и улучшения ядра начинают поставлять фичи на тех же условиях, что и его юзеры. Какой-нибудь eglot - не встроенная поддержка lsp в емаксе, это предзагруженный костыль. Единственное отличие которого от стороннего - идущая в комплекте версия совместима с версией емакса. По началу стройные решения в таком ПО из года в год становятся всё сложнее и уродливее.

RMS хотел, чтобы мы батарейку из телефона выдёргивали

\begin{теория заговора}

именно поэтому сейчас почти все телефоны с несъёмными батареями

\end{теория заговора}

у меня сложилось стойкое впечатление, что если хочется быть прям ъ ымаксером надо так или иначе изучать elisp

https://www.gnu.org/gnu/rms-lisp.ru.html

Emacs для Multics имел большой успех — программирование новых команд редактирования было таким удобным, что даже секретарши в его конторе начали учиться пользованию им. Они пользовались руководством, которое кто-то написал и в котором было показано, как дополнять Emacs, но там не говорилось, что это программирование. Так что секретарш, которые думали, что не могут программировать, это не отпугивало. Они читали руководство, обнаруживали, что могут делать что-то полезное, и учились программировать.

Прям Ъ емаксерам нужно было овладеть TECO (и DDT)

https://people.csail.mit.edu/devon/teco/

Когда в каждом, вообще в каждом случае знаешь, что та же задача в emacs’е решается быстрее и лучше, использование Acme становится формой аскезы, если не самоистязания.

Ну вот у меня такое же чувство в сторону vi. Неприятно для каждой новой задачи придумывать новую клавиатурную команду.

У меня был заметный прогресс, когда вместо клавиатурных команд я записывал множество различных команд текстом, например e! file.c (открыть файл) или find . -type f |grep something |sed 's/^/e! /' и выполнял их с помощью восьми постоянных клавиатурных команд. Было бы идеально, если бы этих восьми команд хватило для всего.

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

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

могу выразить всё то же самое без специального языка,

Не можете. Чтобы магия сработала вам точно так же нужно написать некий скрипт, на некоем языке.

Это да. Но я имел ввиду только аспект UI.

Но это 6 (шесть) команд. А в emacs’е их тысячи. Из которых нужны и пользуются — сотни.

Не могу представить, чтобы мне нужны были сотни команд, точно не в один и тот же день.

Если в данный момент времени нужен какой-то особый набор команд, то их также можно вынести куда-нибудь в видимое место. Например, у меня сразу под командами LSP обычно, если я вношу изменения в проект, идут команды git, последнее время в таком формате:

gitadd . gitcheckout . gitreset . <gitdiff
<git status --short --untracked-files

	gitcommit --amend -m 'wip'

	gitbranchforce gitcheckout master
	<git branch --show-current
	gitpull gitpush --force

	<git diff master...HEAD
	<git log --oneline master..HEAD
	git merge --squash 2ba149a52

Это своего рода многострочное меню для самых повторяющихся действий. Допускаю, что это может быть медленнее клавиатуры, зато это наглядно и не обязывает заучивать потенциально полезные клавиатурные команды.

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

В Русском языке сотни тысяч слов. И они нужны все. Хотя и в каждый момент времени используется только малая часть, а для минимального общения и вовсе слов 500 хватает, полноценное мышление и речь человека невозможны без наличия свободного доступа ко всей языковой базе.

Также и в emacs. В каждый конкретный момент времени мне нужна только малая часть его функций, но важно, что в любой момент для любой задачи у меня будет под рукой любая его возможность. Вот, например, только что я оформлял commit message, естественно в emacs через magit, и мне понадобилось проверить себя, были сомнения насчёт одной языковой конструкции. C-c t — и google translate перевёл мою мысль обратно на Русский. Если автопереводчик понял её правильно, значит и для человека сгодится, продолжаю работать дальше. И этот режим, кажется, впервые понадобился за неделю. Но всё это время был рядом, в быстром доступе.

Естественно, если б мне нужно было наперёд подумать какие режимы могут сегодня понадобиться, чтобы разложить файлы с подсказками/командами на нужном месте, магия бы не сработала, пришлось бы покинуть emacs и идти в браузер. А это медленно, хлопотно, да и само по себе говорит о недостатке избранного подхода.

Обратите внимание: никто из свиты не сбежал через Верхний Ларс. А ведь этим людям, как никому больше, было что терять.

Нет это потому что они там не нужны местным элитам. Для бегунков есть шанс закончить как Саддам или Каддафи, если это не верные подсосы-либерахи, типа Рыжего.

Нет это потому что они там не нужны местным элитам. Для бегунков есть шанс закончить как Саддам или Каддафи, если это не верные подсосы-либерахи, типа Рыжего.

Можно подумать, что обосравшиеся айтишники, не получившие повесток и сбежавшие через Ларс, нужны тамошним элитам. Не нужны, половина вернувшихся во всяком случае.

Так айтишнки для элит не интересны хоть наши, хоть их местные. Я олигархов и политиков подразумевал.

Мои 5 коп.: попробовал, потыкал 10 минут, и понял что не вижу смысла в таком редакторе. Я беру другой редактор и IDE, и всё что медленно делается - хоткеи ищу или задаю свои

Может emacs обладает плагинами, крутым безграничным скриптованием, всяческими наворотами? Может быть, но из всех коллег видел только одного на emacs

Здесь не поспоришь. Я тоже знаю языки редактирования текста (awk, ed, sam, sed), но не использую постоянно. Мне ближе подход упрощать наиболее распространённое действие, отсюда примеры (они все имеют ограниченное применение). Этот же принцип во многом сделал Acme таким, какой он есть. Если емаксеры убеждены, что редкие действия тоже должны быть простыми, go for it. Я пробовал, и мне это не понравилось. Возможно, это можно приготовить хорошо, но энтузиазм пропал и любой список «хоткеев» вызывает отвращение. Для меня это тяжёлая работа с сомнительной выгодой.

Но при этом я ценю глобальный интерфейс как концепцию за то, что он позволяет мне самому выбрать какое действие является наиболее распространённым, полагаясь только на обычный текст и привычные абстракции юникса (файл/путь/программа/шелл), а не заранее установленный огромный набор опций UI.

Кстати, суть не в том, что при мышлении и на письме человек использует редкие слова. Например, «тезис» редко встречается в простой речи, но это основная, не редкая, концепция во время процесса мышления или письма.

Редкой концепцией было бы «прекрасная девушка с голубыми глазами, ростом 5’5” и 24 года от роду». Но настолько редких концепций не существует, такие сущности или группы обозначаются описательно.

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

ваще

imho emacs vs acme

это в некотором смысле (не взаимно однозначно)

жадные_алго VS «динамическое прог»

если же совсем грубо

муравьиный алгоритм оптимизации траектории

насколько репрезантативен муравейник целям (that)муравья acme vscode vim emacs

Когда б я гайки на конвейере крутил, я б согласился. Логика «частое в приоритете, редкое — по остаточному принципу» — правильная.

Однако, милостью Божьей моя работа чуть более разносторонняя. Сегодня нужно одно, завтра другое. Да, редкая возможность нужна редко (ауф!), раз в неделю. Но вся неделя наполовину состоит из вот таких нечастых операций. И получается, что я должен половину недели страдать? Ну уж нет. Я хочу, чтобы было удобно. Я хочу, чтобы всё было под рукой, когда понадобится.

И, вот, модель emacs позволяет мне это. А модель acme требует, чтобы я заранее подготовил шпаргалки с командами и метками и разложил их на нужное место. И ими всё равно будет пользоваться менее удобно, потому как клавиатура быстрее мыши. А если уж говорить о когнитивной нагрузке, то как вы

Если в данный момент времени нужен какой-то особый набор команд, то их также можно вынести куда-нибудь в видимое место.

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

Мне имхуется, acme vs emacs подобны концепт-кару супротив реального автомобиля. В одном есть интересные идеи (и я тут потому и пишу, что задумка-то концептуально интересная вышла). А в другом есть нормальная реализация, чтобы удобно и безопасно ездить по дорогам общего пользования.

проблема(реальная проблема а не смузи не той ...) что для acme требуется большая «осознаность»(саморефлексия собственных действий ) чем от в хорошем смысле ремесленного emacs/vim где дофамин от быстроклавиш (через vimscript(lua)/elisp а по факту от копролитов предшествеников)

ортогональность хрупка в малом однако без ортогональности концепций объём умопостигнутого(и как следствие переведённого в дальнейшем в рефлексы) меньше - вот такая загоГУГЛЕня

фишка всех массовых инструментов в эксплуатации(как будто что-то плохое) их демиургами трюков из hmi в оппортунистических по отношению к инструменто_пользователей целях :(

Это печально.

Это печально.

Просто возьми vscode и не печалься.

Ну если мои примеры не убедили, то ничего лучше я предложить не могу. Мне они не кажутся страданием: нужно 3-4 клика, чтобы открыть файл с командой, которой нет на экране. Это настолько проще, чем во многих программах, что даже приятно. И это только слегка медленнее, чем 2-3 нажатия.

И получается, что клавиатурный подход может всё то же самое, что и мышиный, а в обратную сторону это не работает.

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

Мне хотелось бы, чтобы у клавиатурного подхода были постоянные комбинации, которые бы не приходилось постоянно расширять для удобной работы.

Фактически, такая комбинация есть — M-x, после неё курсор перескакивает в минибуфер (нижнюю строчку emacs’а, под строкой статуса), где можно ввести команду на исполнение. При этом есть история команд и автодополнение. И это ровно то же самое действие, что и acme’вское «кликнуть по свободному месту в тексте или области меток, набрать команду, кликнуть по команде». Преимущество emacs’овского подхода в удобстве и скорости, как обычно, но acme гибче, признаю, если б emacs мог так мешать скрипты на разных языках, про elisp все давно забыли бы.

Аналогия концепт-кара имеет место быть, если под «концепт-каром» подразумевается избирательность. То есть среди всех возможных опций и вариаций выбрано только несколько.

Такой подход, по сути, не столько удовлетворяет заранее подготовленные ожидания пользователя, сколько указывает ему как нужно использовать программу. Например, ты мог бы хранить проект в /home/ugoday/github.com/username/project, но из-за ограниченного размера тега лучше /home/ugoday/project.

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

Аналогия концепт-кара имеет место быть, если под «концепт-каром» подразумевается избирательность.

Да, а ещё сам подход, когда во главу угла ставится некая идея, которую нужно максимально полно и последовательно воплотить. В противоположность этому — идти от потребностей пользователей, каждая из которых должна быть хоть как-то удовлетворена.

Насчёт копролитов — так у нас вариантов не то чтоб много. Два. Либо пользуешься горой, наваленной поколениями предшественников, либо пытаешься навалить собственную. В последнем случае легче достигнуть последовательности и согласованности, но сил и времени сделать всё в одиночку радикально не хватает.

сил и времени сделать всё в одиночку радикально не хватает.

1-2 семестра после первого-второго курса должно хватить.

Должно хватить на что?

Например, на то, чтобы сделать ещё один emacs

Второй вариант позволяет сделать достаточно хороший ресёрч, чтобы повлиять на горы и они наваливались в правильную сторону.

Например, в JetBrains есть возможность исполнить HTTP-запрос прямо из текста. Очевидное влияние REPL-интерфейсов.

А сколько нужно времени, чтобы переделать расширения для emacs’а? Для простоты, ограничимся теме, что включены в melpa.

переделать расширения для emacs’а

Это?

https://melpa.org/#/2048-game

Все.

если б emacs мог так мешать скрипты на разных языках

Вообще говоря, есть штуки типа shell-command (M-!), которые уже позволяют выполнить скрипт на любом языке. Если какую-то из них допилить, чтобы вызываемая команда получала текущий буфер/регион на стандартный ввод, а её стандартный вывод заменял содержимое текущего буфера/региона — будет примерно оно самое.

Похоже что ты говоришь об org babel blocks

А ещё для полноценной интеграции нужна возможность создавать-изменять переменные, вешать свои обработчики на hook’и, дёргать elisp-функции и позволять другим пакетам дёргать твои. Вот, если б emacs мог экспортировать свою внутрянку в виде псевдофайловой системы в стиле plan9, то это был бы хороший фундамент для такой системы. И Acme как раз тут и хорош. Но всё остальное у него получилось хуже. Так и живём.