скорее всего, если нет особо экзотичиских применей tmux
если нравится редакторы типа vim - то попробовать в любом случае стоит, чтобы понимать какие есть возможности; ну и да, elisp хотя и коряв на порядок лучше vimscript-a
Это разные среды. Emacs — не редактор, а интерактивная среда разработки. Если в 2016 вам хочется упарываться редактированием текста, то Vim лучше. Но мне кажется, что ручную работу нужно автоматизировать, для чего Emacs и предназначен.
Почему он коряв? Основная фича Elisp — горячая перезагрузка кода. По определению считается, что среда разработки — сложное устройство наподобие черного ящика; исследуя его поведение (создавая и перезагружая функции) постепенно приходишь к результату, попутно проверяя, насколько хорошо он вписывается в workflow.
исследуя его поведение (создавая и перезагружая функции) постепенно приходишь к результату, попутно проверяя, насколько хорошо он вписывается в workflow.
Ничем не отличается от вима. Когда делаю плагин, редактор не перезагружаю, все на горячую.
Вим — безусловно. А tmux — это, насколько я понимаю, аналог ГНУ Скрина, то есть это такая штука для подключения к нескольким псевдо-tty на удаленной машине через единую сессию (SSH или иную). И тут у ГНУ Емакса принципиально обратный — более современный — подход — редактируете вы все локально, а к удаленной машине обращаетесь только за чтением и записью файла — и он умеет это делать прозрачно для вас (см. TRAMP).
Емаксовая модель буфера+окна гораздо разумнее (и удобнее) чем хрензнаетчто они там наворотили в тмуксе. Буфера существуют отдельно, лейаут окон существует отдельно, какой буфер в каком окне (или окнах) отображать ты задаешь отдельно. В тмуксе одно к другому прибито гвоздями почему-то.
Having said that, мне работа с окнами в емаксе тоже не очень нравится, получается оконный менеджер в оконом менеджере с другим поведением, другими биндингами и т.д. Я давно фантазирую на тему как бы отучить емакс от сознания окон в пользу создания фреймов и переложить управление этими фреймами на того, кто этим должен заниматься - на тайловый wm. Но дальше фантазий дело не зашло.
Только куда подевались идеалисты, что хотели Emacs на Guile перевести?
И аргумент подобного рода приводит человек, предположительно использующий gnu/linux, интересно.
И дa, до идеала это было бы далеко, вот какая-нибудь смесь «acme на yi» , и чтобы подсветку прокидывать в acme, и доступ к аst из yi (для paredit-подобного поведения), и чтобы ghc на порядок меньше памяти при рекомпиляции жрал и hint (подключаемный интерператор haskell) быстрее запускался — вот было бы норм.
А кто мешает уже сейчас это использовать через emacs-daemon + emacsclient? Первый будет буферами, второй будет фреймами, положением которых будет управлять твой любимый wm?
Я давно фантазирую на тему как бы отучить емакс от сознания окон в пользу создания фреймов и переложить управление этими фреймами на того, кто этим должен заниматься - на тайловый wm.
Если совсем агрессивно — все в новую рамку, то как-то так:
Ну так в том-то и оно, что рубануть по корень - дело нехитрое, а сделать так чтобы оно юзабельно было гораздо сложнее. Надо все продумать сначала, в том числе интеграцию с wm, на что у меня сил/времени/желания нет.
У меня как-то были такие мысли Но все дело в том, для чего тебе Vim Если ты просто редактируешь текст - Vim за глаза, а если тебе нужна именно среда разработки - то тут уже Emacs лучше Ну и для Emacs есть Vi-режим
А кто мешает уже сейчас это использовать через emacs-daemon + emacsclient? Первый будет буферами, второй будет фреймами, положением которых будет управлять твой любимый wm?
Хотя бы то, что отношения демон-клиент для этого совершенно не нужны.
Ну так в том-то и оно, что рубануть по корень - дело нехитрое, а сделать так чтобы оно юзабельно было гораздо сложнее. Надо все продумать сначала, в том числе интеграцию с wm, на что у меня сил/времени/желания нет.
Кстати есть же и обратное мнение, что лучший WM — это ГНУ Емакс, и надо не его дербанить на рамки, а наоборот — сделать каждое иксовое окно емаксовым буфером. Для этого есть такая забавная штука, как exwm.
Вим — безусловно. А tmux — это, насколько я понимаю, аналог ГНУ Скрина, то есть это такая штука для подключения к нескольким псевдо-tty на удаленной машине через единую сессию (SSH или иную).
Да, tmux очень удобен для быстрого разбиения окна терминала на окна и «табы».
GNU Screen не пробовал.
И тут у ГНУ Емакса принципиально обратный — более современный — подход — редактируете вы все локально, а к удаленной машине обращаетесь только за чтением и записью файла — и он умеет это делать прозрачно для вас (см. TRAMP).
Нет, tmux + vim / neovim, IMHO, нельзя сравнивать с term в neovim. Да и вообще последний не нужен (разраб-ки neovim своей задачей ставили выпилить всё лишнее, и то, что они это добавили, кажется странным).
Затем, что ТС говорил о выборе между vim+tmux и emacs. Ты же противопоставил тмуксу то, что есть емаксе, но при этом же есть и в виме. После этого привёл сообщение, где радостно утверждается, что емакс умеет во всё подряд (нужно ли оно?), а вим безаргументно называется гавном. Зачем тебе вообще что-то обсуждать? Живи в своём мире, где всё делится на гавно и бабочек, а аргументы к сказанному приводить не нужно.
Ну как собственно тайловый вм сам емакс сливает тому же i3 например (про exwm я знаю, но сам не пробовал; догадываюсь, что ситуация та же).
К тому же мне совершенно не нравится идея запихивание всего и вся в емакс - это не работа на интеграцию различных компонент друг с другом в единое (но модульное/конфигурябельное/етс) рабочее окружение, а такое же перетягивания одеяла на себя, которым занимаются всякие гномеры и кдебляди.
как средство для разработки - оба продукта имеют равные возможности, но разные подходы. какой ближе подход - тот и нужно юзать.
как средство обустраивания мира - вим сливает эмаксу. Но лично мое отношение в этом контексте к эмаксу крайне отрицательное. пример: поставил emms(mpd client). на моем плейлисте в 5к песен тупо на списке песен кушает 60% i5. о каком обустраивании мира может идти речь? эмакс тормозной однопоточный лисп интерпретатор. не надо об этом забывать