LINUX.ORG.RU

Есть ли альтернатива Emacs?

 , ,


2

5

JB требует VPN.
VS требует Windows.
VSCode сливает всё на сервер дополнениями.

Что выбрать, чтобы надолго и минимум зависимости проекта от компаний?

Vim с плагинами - инородная хрень. Голый Vim для front/back -> (‿|‿)



Последнее исправление: Dimez (всего исправлений: 3)

Мысль о том, что в юниксах есть всего два редактора - vim и emacs, всё так же верна.

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

Если vim не подходит, бери emacs.

ivlad ★★★★★
()
Ответ на: комментарий от ivlad

Мысль о том, что в юниксах есть всего два редактора - vim и emacs, всё так же верна.

Если честно, то немного грустно, что люди не переходят с vim на всякие kakoune и helix. Насколько я понимаю, в них сочетания клавиш более продуманные.

Artsi0m
()
Последнее исправление: Artsi0m (всего исправлений: 1)
Ответ на: комментарий от Artsi0m

Если честно, то немного грустно, что люди не переходят с vim на всякие kakoune и helix.

Я тыбе один умный вещь скажу, толко ти не обижайся. Можно взять, например, VSCode и там есть и kakoune и helix и vim и какие угодно еще способы ввода. При этом, о чудо! это не текстовая убогая хренопердь конфигурируемая через очко, а продвинутая ИДЕ с миллионом функций

FishHook
()
Ответ на: комментарий от FishHook

Можно взять, например, VSCode и там есть и kakoune и helix и vim и какие угодно еще способы ввода.

Нет, как раз таки в VSCode этого нет. Общался с одним бывшим вимером, он сказал, что искал где лучше всего эмуляция вима и пришел к выводу, что в емаксе c evil.

Потом перешел просто на емакс.

Ну может есть, но z очень сомневаюсь.

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

Ну, не через очко. M-x customize-group это очень просто, там даже текст никак редактировать не надо, только в менюшках что-то попереключать.

Artsi0m
()
Ответ на: комментарий от habamax

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

От перехода на colemak плюс для меня был в мультиязычности, а не в эффективности раскладки.

https://colemak.com/Multilingual

Artsi0m
()
Ответ на: комментарий от Ygor

продукт компаний это прежде всего труд сотен тысяч программистов - людей глубоко разбирающихся в теме - отдавших свой труд на благо общества

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

watchcat382
()
Ответ на: комментарий от anonymous

Про какие окна речь? Это ты про EXWM?

Нет не про EXWM. Те окна которые у тебя в оконном менеджере, в любом, в емаксе называются фреймами (frame). А окна в самом емаксе собственно окнами.

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

В прочем если не хочется чтобы в емаксе были управляемые емаксом окна и хочется всё перевесить на оконный менеджер, то и такое решение есть:

https://karthinks.com/software/emacs-window-management-almanac/#frames-only-mode

Artsi0m
()
Ответ на: комментарий от Artsi0m

kakoune

Оно же мертво, нет?

helix

Полгода назад пытался перейти на связку hx + zellij, когда обмазывался растом.
Пожалуй начну с zellij, для терминального мультиплексора это поделие потребляет слишком много памяти(раз в 7-10 больше того же tmux-а), а при активной работе отжирает ОЗУ не меньше емакса(зачем оно тогда вообще нужно?) и это я уже не говорю о вечных утечках памяти, которые с легкостью могли занять 4-8 Гб.
Helix понравился больше, но опять же не без минусов. По ОЗУ хеликс потребляет немногим больше, чем neovim, но вот места на диске занимает несравнимо больше, особенно его treesitter библиотеки. Так же мне не понравилась недостаточная минималистичность helix, если neovim в базовой поставке имеет только сам редактор и интерпретатор lua, то helix из коробки включает в себя как минимум lsp. Ну и написано на расте…

eyrell
()
Ответ на: комментарий от Bfgeshka

Согласен, вопросы автора темы был задан слишком общий. Одни пишут огромные проекты и им не критичны расходы времени и усилий на разбирательство с монстрообразными комбайнами - это потом окупается (видимо) большей эффективностью кодописательства. А кто-то (как я последние годы) если что-то и пишет то под микроконтроллеры. И там монстроидальные IDE не нужны - не те объемы кода чтобы ради них в этих монстрах разбираться и их настраивать под свои потребности. Я вот даже вообще не уверен что хоть какое-то из этих монстрообразных IDE можно удобно состыковать с avr-gcc. Так что обычно - простой текстовый редактор + мэйкфайл для сборки.

Сам я пользуюсь редактором eFTE (https://github.com/lanurmi/efte) с сильно переписанными под свои предпочтения конфигами(довольно точная имитация поведения MultiEdit 6.01p for DOS) и собранным с поддержкой иксов. Знаю людей которые вообще обходятся mcedit для всего и даже пишут в нем исходники размером до сотен килобайтов. Но там тоже специфические околосистемные штуки на Си для одноплатных компов.

watchcat382
()
Ответ на: комментарий от Artsi0m

Ну может есть, но z очень сомневаюсь.

чем сомневаться, взял бы да и попробовал, все бесплатно

Нет, как раз таки в VSCode этого нет. Общался с одним бывшим вимером

я сам вимер, что мне выводы твоего знакомоко

FishHook
()
Ответ на: комментарий от FishHook

При этом, о чудо! это не текстовая убогая хренопердь конфигурируемая через очко, а продвинутая убогая хренопердь конфигурируемая через очко

Починил. Ей богу, необходимость лазать и править JSON руками в VSCode, потому что гуй периодически не может – это полный трешак. В сравнение с ручной правкой JSON, даже емаксовый elisp кажется чем-то прекрасным. Хорошо хоть педики из мелкософта догадались XML не использовать.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

ручной правкой JSON, емаксовый elisp кажется чем-то прекрасным

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

FishHook
()
Ответ на: комментарий от FishHook

взял бы да и попробовал, все бесплатно

Я так-то уже пытался пробовать, когда писал свою команду для AutoCAD на AutoLISP. Мне не зашло.

Емакс с дефолтными биндами мне ближе.

Artsi0m
()
Ответ на: комментарий от FishHook

ручной правкой JSON, емаксовый elisp кажется чем-то прекрасным

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

Конечно. JSON в качестве конфигов – полное говно, тут даже сравнивать нечего. А после столкновения с убогоньким недоязычком под названием JavaScript этот ваш лишп кажется просто маной небесной.

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

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от FishHook

это надо из дурдома не вылезать

Да ну. Норм в принципе в дурдоме, если не в наблюдательной палате лежишь и не из-за психоза госпитализирован.

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

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

Artsi0m
()
Ответ на: комментарий от FishHook

когда это лисп умудрился стать декларативным языком?

Справедливости ради, лисп конечно не декларативный, но иметь конфиг на его подмножестве, которое выглядит декларативным возможно.

А cекция custom-set-variables не только выглядит декларативно, но и является по сути. Ведь это просто набор переменных в формате ключ значение.

Artsi0m
()
Последнее исправление: Artsi0m (всего исправлений: 1)
Ответ на: комментарий от Aceler

Только не на благо общества, а на благо компании. Эти блага иногда пересекаются, а инога и нет.

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

Ygor ★★★★★
()
Ответ на: комментарий от FishHook

когда это лисп умудрился стать декларативным языком?

Ну и опять-таки. Лисп-то может и не декларативный, а вот сам формат s-выражений вполне может быть.

Взять например kicad eeschema. В нём документы, в которых хранится принципиальная схема того или иного радиоэлектронного средства описываются ничем иным как s-выражения.

Которые, что примечательно, можно просмотреть в емаксе с режимом lisp-data-mode.

Artsi0m
()
Ответ на: комментарий от Artsi0m

Посмотрел на helix. Наверное, маленький vi на rust, без vimscript и прочего добра - это любопытно, но не настолько любопытно, чтобы я стал им пользоваться.

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

ivlad ★★★★★
()
Ответ на: комментарий от FishHook

сравнивать декларативный текстовый конфиг и конфиг на лиспе

Что JSON, что кот на лиспе — всего лишь структуры данных, объекты-массивы-примитивы. В чём принципиальная разница?

Nervous ★★★★★
()
Ответ на: комментарий от anonymous

gnome-builder

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

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

Dr64h ★★★
()
Последнее исправление: Dr64h (всего исправлений: 2)
Ответ на: комментарий от Nervous

кот на лиспе

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

anonymous
()
Ответ на: комментарий от ivlad

Хотя сама идея «современного» (если это вообще применимо) vi с здравыми настройками по умолчанию мне симпатична.

Таких vi более 9000. Потому что «здравые настройки по умолчанию» очень субьективный критерий.

anonymous
()
Ответ на: комментарий от anonymous

«здравые настройки по умолчанию» очень субьективный критерий.

Справедливо.

Наверное, поэтому я сложил свой vimrc, пару плагинов и схему оформления в git репу и таскаю между системами уже много лет. Иногда полирую мелочи, но фундамент настроек давно устоялся.

ivlad ★★★★★
()
Ответ на: комментарий от Aceler

Я тоже удивлен отсутствием упоминаний Eclipse.

Использую его для C++ проекта. Нормально работает с большим проектом, с файлами до 20 000 строк. Есть проблемы с парсеньем современных C++ конструкций. Нормальный дебаггер. Нормальная скорость. Маловато возможностей рефакторинга. Но в целом очень даже достойная IDE для больших проектов. Для малых есть вещи поприятнее типа QtCreator.

blex ★★★
()

постоянно возникающая бессмысленная тема. Что нравится, то и альтернатива. Казалось бы, очевидно. Ответы тоже частью бессмыcленные, особенно напоминание о Vim. Любители Emacs и Vim много спорили… лет 30 назад. Неужели не надоело. Мне Emacs и Vim ни разу не понадобились. При выборе редактора для программирования ключевыми пунктами являются наличие отладчика, проверки синтаксиса и контроля версий. Это важнее, чем разница между Emacs и Vim.

Partisan ★★★★★
()