Комментарии 32
Для снижения градуса категоричности: в моём понимании альтернатива —
это не то же самое, что полная замена.
Уникальность Go, если брать конкретно мой проект, в том, что он был easy pick'ом в самом начале.
За один вечер уже был на коленке написанный транслятор, который преобразовывал Go код в
S-выражения.
Не ясно зачем тащить Go, но без рутин, без рантайма, без компиляции. Только ради синтаксиса? Вам он правда так нравится?
На мой взгляд никакой проблемы с Lisp в Emacs нет, в отличии от VimScript, который все ненавидят.
Есть проблема с очень необычным UI, построенном на очень сложных клавиатурных сочетаниях, которые имею специфичную внутреннюю логику: простота запоминания в ущерб эргономики.
Хоткейность UI у Emacs — это его основной плюс, просто надо проникнуться таким workflow, ну и с мелкой моторикой пальцев должно быть все в порядке)
Вот де факто однопоточность Emacs'а и в связи с этим подвисания при работе некоторых плагинов — вот это действительно проблема. И как-то пока с асинхронностью туго в нем...
Вот де факто однопоточность Emacs'а и в связи с этим подвисания при работе некоторых плагинов — вот это действительно проблема. И как-то пока с асинхронностью туго в нем...
Ну тут автор ничего нового не предлагает, на сколько я понял.
Хоткейность UI у Emacs — это его основной плюс
Это если не быть знакомым с Vim. Нет, у меня не синдром утенка, и я понимаю что за пределами vim жизнь есть, но мне очень не нравится то, что переход на следущую строку это ctrl-n, а на предыдущую — ctrl-p. Запомнить лекго, но кнопки не рядом, а это для быстрого перемещения неприятно.
но мне очень не нравится то, что переход на следущую строку это ctrl-n, а на предыдущую — ctrl-p. Запомнить лекго, но кнопки не рядом, а это для быстрого перемещения неприятно.
'p' лежит аккурат под мизинце, 'n' под указательным пальцем. Если вместо обычной клавиатуры пользоваться эргономичной (типа тех, что выпускает Microsoft), то там правильное положение рук для работы в Emacs будет by design.
p.s. собственно модальность в Vim тоже на любителя)
Именно ей и пользуюсь, но например при моей руке, я не могу держать без напряга руку сразу на двух позициях, как это с jk в вим, ну или просто со стрелочками. Я уж не говорю, что горизонтальное перемещение будет вообще на другой руке по большей части.
p.s. собственно модальность в Vim тоже на любителя)
Да я и не спорю. С модальностью много проблем. Но все же там именно на эрогомику упор, а в емаксе — на запоминаемость. Если бы переходы были хотябы ctrl-n, ctrl-h, то было бы уже заметно лучше. (да-да можно заремапить, я в курсе)
Есть ErgoEmacs, который из коробки ремапит стандартные хоткеи Emacs на "общепринятые" стандартные кнопки. Ну а стрелочки из коробки работают в стандартном Emacs.
А в чем эргономика Vim — вопрос открытый, т.к. разница между Vim и Emacs по большому счету только в принципе: либо мы сочетание клавиш вводим в рантайме, либо мы переходим в режим команд и набираем это сочетание в нем. Первое удобно для тех, кто владеет слепым 10-пальцевым набором, второе для тех, кто такой способ ввода не осилил и набирает текст двумя пальцами. Остальное — детали и вопрос конфига.
Первое удобно для тех, кто владеет слепым 10-пальцевым набором, второе для тех, кто такой способ ввода не осилил и набирает текст двумя пальцами.
Эээ. Чего? В vim делать нечего без слепой печати
В каком месте?:-)
Переключился в режим набора и погнал двумя пальчиками стучать набирая текст, переключился в режим команд и давай также одним пальчиком набирать заклинания :q!.. у меня коллега так в нем работает и вроде бы всем доволен)
Ну тут автор ничего нового не предлагает, на сколько я понял.
Увы, но да. Хотя, язык Go вроде бы позиционируется как спроектированный для многопоточности.
Если более локально, то есть несколько вариантов.
Некоторые даже не требуют патчинга Emacs'а.
В любом случае, это очень крупный кусок, который, возможно, когда-нибудь будет затронут.
Не факт, что мной, как и не факт, что в рамках goism.
"Жаль только — жить в эту пору прекрасную
Уж не придется — ни мне, ни тебе" ©
Давно уже народ штурмует этот бастион, но как-то безрезультатно)
По сути единственная проблема этого редактора… вообще не круто, когда multiply cursors начинает дико виснуть, если в момент набора текста Emacs решает кодец поформатировать попутно....
Ну, в условном Eclipse ситуация не то чтобы радикально лучше. Да многопоточность есть, но потребление ресурсов такое бешенное, что это не очень то и заметно.
Я не вижу бенефитов от Go для Emacs'a ну вот вообще.
Go — достаточно популярный язык с С-подобным синтаксисом (т.е. это тебе не Scheme);
Как раз таки большинство пользователей сидят на Емаксе из-за лиспа в том числе. Заменой может быть Common Lisp, или там Clojure'оподоный но не на JVM, но никак не Go.
Есть проект remacs, где люди переписывают core на Rust.
Если вам уж так нравится Go, пишите на нем плагин/мод или я знаю что еще и общайтесь с ним через фронтенд емакса (аля lsp только для вашего плагина). Тем самым весь сок написан на Го, а «байдинги» на елиспе.
Таким образом плагин можно будет переиспользовать, для вима например (наверное), ну или там для других редакторов (профит)
В целом, проект уже не активен, но я всё же отвечу, так как вы довольно категорично стоите за свою позицию.
Это, наверное, русский менталитет: со стороны сказать, что "фигня и не нужно", хотя это мнение не является конструктивной критикой и не помогает ну никак. Тем более ваши альтернативы я описал в статье, я о них как минимум в курсе. Я пытался сделать то, что мне казалось интересной и полезной затеей как минимум для себя, некоторым людям тоже идея понравилась. Кому-то она не понравилась. Я больше получал негативной обратной связи, если честно, возможно это ещё одна причина, почему личная мотивация тоже снизилась в какой-то момент (я довольно сильно завишу от этой оценки извне).
Я не вижу бенефитов от Go для Emacs'a ну вот вообще.
А я вижу. :)
Мне приятнее писать на статически типизированных языках.
Не всегда нужны все фичи из Emacs Lisp, типа макросов.
Мы имеем право не сходиться в этом мнении.
Хотя лично я уже года 2 на Emacs Lisp ничего не пишу, поэтому "проблема" сама собой исчезла. :)
Как раз таки большинство пользователей сидят на Емаксе из-за лиспа в том числе.
У меня такой статистики нет, но все мои знакомые емаксеры либо очень плохо знают Elisp, либо вообще его только на уровне copy/paste использовали. Ваш опыт может здесь расходиться, но я описал картину, которую я наблюдаю.
Если вам уж так нравится Go, пишите на нем плагин/мод или я знаю что еще и общайтесь с ним через фронтенд емакса (аля lsp только для вашего плагина).
Я описывал альтернативы в статье, общение с Emacs через процессы или плагины там есть. Правда плагины мне казалось, что называются модулями.
Таким образом плагин можно будет переиспользовать, для вима например (наверное), ну или там для других редакторов (профит)
Вопрос, конечно, зачем. Я vim не использую, а делать обобщённое решение не будет проще, чем специализированное. Тем более я не тестировал бы эту поддержку. Не похоже на хороший путь для хобби-проекта.
Мне приятнее писать на статически типизированных языках.А Go тут при чем? Хотите хороший type checker, Хаскель или Окамл вам в помощь, а не пародие в лице Go.
Ну если вы думаете, что Лисп и типы несовместимы, то есть система типов для Ракета например (линк в студию)
Где поддерживаются реальные ∪-types, есть так же type inference и прочее. Я надеюсь я это увижу в Clojure
interface{}наше все
Мы имеем право не сходиться в этом мнении.безусловно. Тут нет правых и не правых, мы в разных лагерях и видим ситуацию по разному и это нормально и даже хорошо. Любое развитие Емакса только на пользу.
Правда плагины мне казалось, что называются модулями.От использование разных терминов, суть не меняется. Честно сказать я сам не знаю, как они правильно называются. Они вроде просто packages называются, но это не точно.
Не подумайте, что это хейт в вашу сторону, это вовсе не так. Я просто не особый фанат GoLang'a.
Мне приятнее писать на статически типизированных языках.А Go тут при чем?
При том, что мне нравится Go. :)
Не подумайте, что это хейт в вашу сторону, это вовсе не так. Я просто не особый фанат GoLang'a.Когда дело касается языков программирования, как-то всё резко скатывается в холивары. Мне Go нравится, вам — нет. Мне недостатки Go знакомы, но мне с ним вполне комфортно.
Кстати, я пытался сделать на основе самого Emacs Lisp свой диалект, но это тоже довольно быстро привело к тому, что нужно писать свой language mode, а это не так весело. Думаю каждый энтузиаст Emacs Lisp делал такое хотя бы раз в жизни. :)
Я знаю, что проект уже не активен и, что я уже немного опоздал, но ЗАЧЕМ?
Серьезно, документация Go, которая вам нравится, не будет иметь смысла для Emacs (но только документация описывающая синтаксис имеет, но он и так очень прост), статическая типизация Go (кстати проект Elsa - хороший статический анализатор для Elisp) работать не будет, autocomplete для Go тоже не сможет работать. Только рефакторинг - реальная причина для миграции.
И к тому же как без макросов? Да вы можете не писать макросов, но многие встроенные макросы реально удобные для Emacs, например save-excursion, как он будет выглядеть в Go синтаксе?
Сначала заранее прошу прощения за не очень доброжелательный тон моего сообщения. Буду честен, ваш комментарий мне настроения не поднял. Надеюсь, вы понимаете, что вы просто ткнули в меня палкой.
Мне не очень хотелось отвечать, потому что статья действительно старая это раз. А два - вы так говорите, как будто бы я перед тем, как что-то заявлять, не пробовал это. Я же жил какое-то время на emacs и кодил используя этот проект. Мне было интересно и удобно. Кому-то тоже понравилась идея. Разве этого не достаточно, чтобы ответить на ваше "зачем?"
autocomplete для Go тоже не сможет работать
Почему? Он вполне себе работал.
Там был способ описать что-то типа стабов, чтобы го видел эти функции как внешние, а компилятор goism для них создавал нужные обёртки с учётом типизации.
статическая типизация Go (кстати проект Elsa - хороший статический анализатор для Elisp) работать не будет
Опять не понимаю, почему такой вывод? Возможно, я просто чего-то не понял.
У нас код транслироваться не будет, если там есть ошибки. А то, что в рантайме там уже не те представления - это деталь реализации. У вас на уровне машинного кода тоже нет типизации, но высокоуровневые языки как-то работают. Статическая типизация на то и статическая, что она на этапе компиляции известна и там мы с ней работает. Как рантайм это потом исполняет - отдельный вопрос.
Статические анализаторы лиспа, конечно, работать не будут. Но зачем они нужны, если для Go у нас больше анализаторов и есть коммерческие в том числе?
Серьезно, документация Go, которая вам нравится, не будет иметь смысла для Emacs
Документация того, что написано на elisp доступна напрямую не будет, но я выше писал про стабы. Стабы причём я программно генерил, через сам elisp. Ведь документация и сигнатуры доступны через сам emacs. И вот уже у нас из Go есть go to definition с документацией.
На всю stdlib Go тоже документация работает. Вопрос только в правильной компиляции stdlib.
На все пакеты для emacs, написанные на Go, тоже документация работала бы.
Альтернатива Emacs Lisp'у