Что лучше emacs или vim
Vim vs Emacs. Что лучше?
Скорость запуска
Но здесь есть одно исключение, если вам нужно отредактировать файл на удаленной машине Emacs действительно будет запускаться намного медленнее того самого Vim. В некоторых ситуациях вы можете держать Emacs запущенным на удаленной машине, или редактировать удаленные файлы в локальном редакторе Emacs, но соединение будет разорвано, если порвется сессия ssh.
Раздутость
Когда-то Emacs потреблял восемь мегабайт оперативной памяти и постоянно лез в подкачку. Сейчас же популярный браузер Google Chrome потребляет столько памяти для одной вкладки, сколько Emacs необходимо для открытия сотни файлов. И даже не будем упоминать Firefox. Прожорливость Emacs в двадцать первом веке это тоже миф.
Производительность
Это очень трудная тема. Приверженцы Vim утверждают, что вы можете делать почти все что нужно не выходя из главного окна. И это делает работу более эффективной. Сторонники Emacs говорят, что у него есть много команд, которые нечасто используются, но очень удобны, когда они нужны.
В этом плане Emacs, скорее всего, выиграет, если у вас нет проблем с набором текста. В Emacs вы можете настроить последовательности нажатий клавиш, например Ctrl + буква. Зато в Vim есть переключение режимов работы. Но вряд ли есть то, что Vim может сделать эффективнее чем Emacs, но в то же время верно и обратное. В этом сравнении, можно сказать, что редакторы равноценны.
Доступность
Если вы системный администратор и работаете с системами Unix, или пользователь встраиваемых устройств, таких как маршрутизаторы, смартфоны и т д, вы, скорее всего, знаете Vi, так как он доступен для большинства систем, будь то встроенный компьютер, сервер или любое другое устройство. Но для обычного пользователя это не имеет большого значения. Emacs доступен для большинства операционных систем настольных компьютеров и серверов, а поскольку здесь поддерживается удаленное редактирование, достаточно просто иметь его на своем компьютере.
Сложность обучения
На самом деле, это зависит от человека. У Vim действительно крутая кривая обучения, но ее можно немного уменьшить с помощью Gvim. На самом деле Vim не такой уж трудный для использования, немного тренировок и вы привыкните и будете чувствовать себя естественно в этом редакторе.
Emacs же имеет огромное количество расширений и позволяет выполнять задачи, которые лишь отдаленно связаны с текстовыми редакторами. Это, например, просмотр файловой системы, контроль версий файлов, чтение RSS каналов и так далее.
В целом Emacs обучится легче чем Vim, но вы все равно со временем будете снова и снова находить новые возможности в обоих редакторах.
Настраиваемость
Оба редактора программируемые, и у обоих есть огромное число плагинов. Но у Vim есть макроязык. А Emacs написанный на Lisp с некоторыми узкоспециализированными дополнениями.
Emacs явно побеждает, если вы хотите сделать то, что авторы явно не придумали.
Больше чем редактор
Среда разработки IDE
И Emacs, и Vim поддерживают большое количество языков программирования и других текстовых форматов. Помимо основных функций, таких как подсветка синтаксиса, автоматических отступов, оба редактора поддерживают расширение функций до IDE. Подключение документации, поиска, рефакторинга, интегрированного управления версиями, возможность запуска компиляции и перехода к первой ошибке.
Другие особенности
Многобайтовые символы
Оба редактора Vim и Emacs поддерживают многобайтовые символы, хотя в течение долгого времени международные символы были доступны только с помощью плагинов Emacs.
Расширяемость
Графический интерфейс
У обоих редакторов, будь то Emacs или Vim есть графический интерфейс. Графический интерфейс обеспечивает меню для обоих приложений. Но практически все пункты меню это альтернативный способ использования команд или комбинаций клавиш. Там нет ничего, что не может быть сделано с помощью прямых команд.
Emacs использует XDisplay и GTK2 для реализации графического интерфейса. Vim может применять множество других графических библиотек, таких как GTK, GTK2, Gnome, Gnome2, motif, athena, neXtaw, photon, carbon.
Следует отметить, что Emacs может рисовать различную графику и шрифты, а шрифт для Vim может быть только один и только фиксированной ширины.
Буферные вкладки
Оба Emacs vs Vim поддерживают буфера вкладок как в CLI, так и в графическом интерфейсе. Кроме того, Vim в доступен на большинстве серверов, в отличие от Emacs.
Лицензия
GNU Emacs распространяется под лицензией GNU GPL, и гораздо чаще ассоциируется с операционной системой GNU LInux, учитывая тот факт, что он является частью проекта GNU. Vim распространяется под лицензией charityware, хотя сам автор утверждает, что она совместима с GPL. Vim был изначально основан на Vi, разработанным Билом Джойем. Он используется многими пользователями Linux, поэтому может считаться родным для BSD, и других *nix систем.
Обзор различий
Emacs
Emacs был написан на Lisp, а это лучший язык для создания редактора. Вы можете реализовать в нем все что захотите с помощью Elisp.
Плюсы: Расширяемый, более мощный, чем любой другой редактор, интегрируется с большинством инструментов для разработки открытого ПО
Минусы: Сомнительная эргономика, Elisp не так просто изучить
Плюсы: Удобные макросы, расширяемость, стандартный во многих дистрибутивах, лучшая эргономика
Минусы: интерфейс непривычный для пользователей Windows.
Vim или Emacs
Новым разработчикам не требуется много времени, чтобы оказаться втянутыми в дебаты о том, является ли Vim или Emacs лучшим текстовым редактором. Текстовый редактор может улучшить или ухудшить ваш опыт в разработке программного обеспечения. А споры между кодировщиками о плюсах и минусах этих двух редакторов были достаточно жаркими, чтобы их окрестить «войной редакторов». Важно ознакомиться с обеими сторонами спора о Vim и Emacs. Когда вы разбираетесь в обоих текстовых редакторах и в том, как они работают, вы можете выбрать идеальный для своего процесса.
Мы даём вам факты о Emacs и Vim и покажем вам сильные и слабые стороны обоих редакторов. Вы узнаете, как два редактора обрабатывают использование памяти, раскладку клавиатуры, пользовательскую среду и языковую поддержку. Оба редактора великолепны и помогут вам в работе.
Vim против использования памяти Emacs
Использование памяти — важный фактор, который следует учитывать, особенно во время запуска. Использование памяти Vim и Emacs варьируется, с преимуществами и недостатками для каждого подхода. Vim использует мало памяти во время запуска, поэтому запускается быстро, но с ограниченной адаптируемостью. Emacs, с другой стороны, предлагает настраиваемые параметры, но с более медленным запуском.
Эффективное использование памяти имеет решающее значение для вашего текстового редактора, так как любой сбой в управлении памятью замедлит работу редактора. Следовательно, Vim и Emacs предлагают преимущества одним людям и недостатки другим. Какая программа лучше всего подходит для вас, зависит от ваших приоритетов и от того, что вы больше всего цените в программе: адаптируемость или скорость запуска. Вы также должны учитывать, что важность использования памяти зависит от языка.
Функциональность клавиатуры Emacs и Vim
Как сравнить функциональность клавиатуры Vim и Emacs? Vim страдает неудобной раскладкой клавиатуры и не хватает некоторых упрощённых сочетаний клавиш. В качестве альтернативы Emacs использует мета-ключевые аккорды для активации дополнительных функций для создания настраиваемых и зависящих от режима операций. Когда дело доходит до функциональности клавиатуры, у Emacs есть преимущество.
Vim лишён этих функций, потому что он основан на более старом текстовом редакторе vi. Функциональность клавиатуры Vim, как и её предка, кажется немного устаревшей. Тем не менее, Vim по-прежнему позволяет вам настраивать привязки клавиш, чтобы сделать его более удобным, но может потребоваться некоторое время, чтобы настроить их так, как вам нравится. Функциональность клавиатуры — полезный инструмент независимо от того, какой язык программирования вы предпочитаете использовать. Они обладают простыми и понятными функциями клавиатуры. А ваши индивидуальные предпочтения являются наиболее важным определяющим фактором.
Пользовательская среда Vim и Emacs
Пользовательские среды Vim и Emacs хорошо разработаны и функциональны. Vim имеет больше функций, чем его предшественник, но сохраняет текстовую среду. Emacs начинался как текстовая программа, но новые версии включают современный графический интерфейс. Если вы предпочитаете классический макет, Vim идеально подходит. Однако графический интерфейс Emacs по-прежнему имеет свои преимущества.
Теперь давайте обсудим, почему кто-то выбрал бы простую текстовую программу или современный графический интерфейс. Опытные программисты извлекают выгоду из серьёзного подхода текстового редактора, такого как VIM. Он знаком и не имеет «отвлекающих» наворотов, хотя имеет больше функций, чем его предшественник. Пользователи Vim, которые предпочитают графический интерфейс, могут использовать gVim или другие производные. В качестве альтернативы подход графического пользовательского интерфейса Emacs предлагает привлекательный и простой в навигации интерфейс. Который во многих ситуациях является преимуществом. И новички, и профессионалы предпочитают графический интерфейс, особенно при работе со сложными проектами.
Как Vim и Emacs обрабатывают языки?
Vim и Emacs по-разному обрабатывают языки. Vim происходит из среды Unix старой школы, поэтому он хорошо работает с Linux, DOS, BSD, HP-UX, Mac и другими операционными системами. Emacs также работает с системами Unix, используя специальные основные режимы для Scheme, Lisp, Perl, Java, Ruby и других.
В целом, Vim имеет немного более высокую производительность. Но и Vim, и Emacs включают в себя хорошую поддержку системы и множество вариантов языковых пакетов, что позволяет при необходимости добавлять больше языков или операционных систем. Но из-за своего опыта Vim и Emacs лучше справляются с некоторыми настройками, чем с другими. Знание, какой редактор лучше всего подходит для вашего языка и выбранной платформы, может избавить вас от множества головных болей, поэтому важно изучить свои приоритеты кодирования, прежде чем делать выбор.
emacs или vim
Эти редакторы примерно одинаковы в плане работы с текстом. Разница в привычке — с каким работаешь, тот тебе и удобен. Не вижу практической пользы от переучивания.
Если тебя не напрягает смена поведения редактора в зависимости от состояния, то используется vim, иначе emacs.
сначала пользовался vim’ом, потом перешёл на emacs — доволен, обратно не хочу.
До IDE можно расширить оба. В емаксе больше скорее не-IDEшных штук типа плеера и почтового клиента.
4й попытки (после 3х лет использования vim), 4й год сижу и назад (и вообще, куда-либо ещё) не собираюсь.
Сначала думал поставить что-то вроде viper/vimpulse/evil, но потом втянулся в родные шорткаты (тем более в шелле/readline похожие) и остался на них.
Ключевые слова для быстрого заценивания:
M-x, M-x describe-function, M-x describe-variable, M-x describe-key (и прочие describe).
Из полезных расширений (искаропки): ido, tramp, org-mode Внешних великое множество, и ставить их достаточно удобно из встроенного пакетного менеджера (главное «репозитории» прописать)
Поставь emacs и в нем evil — переучиваться не придется. Я так сделал и доволен как слон =)
Ждём других прозелитов.
сначала пользовался vim’ом, потом перешёл на emacs — доволен, обратно не хочу.
4й попытки (после 3х лет использования vim), 4й год сижу и назад (и вообще, куда-либо ещё) не собираюсь.
Ждём прозелитов vim’а для комментариев.
Не мог бы ты вкратце описать свой опыт? Что понравилось, что более удобно реализовано в Емаксе и т.д.
И «сначала пользовался» это сколько, две недели или два года?
Спасибо.
Emacs: язык расширений интереснее и нет необходимости переключаться постоянно между режимами.
Сам первоначально пользовался vim: но потихоньку все ключи перемапивал на insert-mode. В итоге понял, что делаю из vim что-то другое, но уже не vim, а. emacs! И решил на него перейти. Остался доволен.
А ты контрол на капслок поставь и все ок будет.
«сначала пользовался» это сколько, две недели или два года?
какраз где-то года 2.
Не мог бы ты вкратце описать свой опыт?
сейчас уже точно вспомнить не могу, в общих смутных воспоминаниях осталось что-то про топорность каких-то плагинов, что-то про не очень удобное управление окнами(возможно, я просто чего-то тогда не знал), про не очень язык расширений, ну и в конце концов переключение режимов на мой взгляд не очень-то нужно.
если ты хочешь использовать как можно меньше программ, в которых надо работать с текстовой информарцией, то однозначно надо посмотреть на емакс.
ты можешь юзать либо отдельные разные IDEшки, которая каждая подходит лучше для определенного языка, либо юзать один емакс в обмен на падение функциональности (особенно рефакторинга)
теперь появились сомнения, а стоит лю использовать что-либо из этого вообще..
Как я полюбил vim, Emacs и клавиатуру
В какой-то степени эта статья ответ — или, скорее, дополнение — к публикации «Зачем vi-топор программисту 21-го века». Я увидел, что в комментариях люди по-прежнему удивлялись: какой смысл в этих редакторах, когда есть полноценные IDE; статья приводила немного реальных примеров и, понимая, что мне есть, что сказать, я решил поделиться собственным опытом. Написано в художественном стиле, так как думаю, если бы люди хотели сухую выжимку, они бы просто пошли читать мануалы. Так же предупрежу, что в мануалах по Емаксу клавиша «Alt» упоминается как «Meta». Я буду говорить «Alt», так как для многих это название привычней.
Забегая вперед, скажу, что в данный момент я использую для кодинга Емакс с плагином Evil (плагин, эмулирующий функционал VIM’а) и отключенными в этом плагине комбинациями для режима вставки (т.е. стоит мне нажать «Escape», и Emacs перевоплощается в vim, но в режиме вставки он все тот же обычный Emacs. Только представьте: ночью вы супер-герой Х, но никто не знает ваше истинное альтер-эго, ибо днем вы обычный супер-герой Y.).
«Какова ваша скорость набора текста?» — вопрос, заданный при устройстве на практику всего полгода назад, вызвал у меня смущенную улыбку, заставил потупить глаза и промямлить «Ну, точную скорость я не измерял, но полуслепой…» О, да, я нередко видел в комментариях на Хабре, посвященных тренажерам слепого набора, подобного рода гордые ответы в комментариях, «полуслепой…». К сожалению, если кто-то из читателей обладает «полуслепым набором» и вы хотите большего, то смиритесь: мое скромное мнение говорит, что вам противопоказано неиспользование Vim или Емакс. Потому что когда вы пишете код (aka много текста) в этих редакторах, не обладая подобного рода набором, у вас будет только два пути: забить и пользоваться обычным редактором или научиться печатать вслепую. Потому что когда вы вместо стрелок используете для перемещения по тексту «Ctrl+n/Ctrl+p» и «Ctrl/Alt+b/f», и пр., вы просто не можете каждую секунду опускать глаза, чтобы посмотреть, куда вы жмете. Поначалу я, правда, сильно недоумевал — «Почему кнопка «n» на месте кнопки «b»? И какого хрена я только что нажал на кнопку «р», а эффект, как будто я нажал на клавишу «[«?». Но поверьте, это пройдет.
Относительно недавно я был обычным студентом с богатой фантазией, кучей поверхностных знаний и без какого-либо серьезного опыта программирования — среднестатистический энтузиаст. Совершенно случайно этому студенту посчастливилось устроиться в отделение одной большой компании, которое пишет ПО для контролеров с запущенным на них GNU/Linux и, конечно же, под «самую популярную ОС». Изначально я попал туда в качестве практики от института, начал писать некое небольшое ПО в виде сервера под GNU/Linux и клиента под Windows, потом был принят в качестве программиста и дописывал его уже числясь в рабочем люде.
«Какое отношение это имеет к нашей статье?», спросите вы. О-о, самое прямое: как следствие принятого мной решения я был авто-лишен Visual Studio. Тогда я еще не знал про ее аналог для Линукса aka QtCreator, точнее знал, но думал, что его можно использовать только для разработки на Qt. Поэтому выбор пал на CodeBlocks. Отчасти, так же этот выбор был обусловлен тем, что эта IDE широко используется в нашей конторе для ПО под Linux.
CodeBlocks недолго просуществовал у меня в качестве редактора, я быстро скатился к редактированию кода в чем-то стороннем и запуске оной IDE исключительно для компиляции. У меня был небольшой опыт использования SublimeText — после него редактировать код в CodeBloсks’е казалось крайне неудобно. По прошествии времени я не могу припомнить ничего конкретного, что меня в CB не устраивало, кроме полного отсутствия семантики автоскобок, из-за чего их было проще отключить, лучшей цветовой схемы в ST и, конечно же, киллер-фиче последнего «mini-map».
К сожалению, момент, когда я перешел с SublimeText на Emacs, напрочь выпал из головы. Могу только гадать, как это произошло. Могу предположить, что хотелось чего-то нового. А может быть меня вдохновили многочисленные статьи о том, как это круто кодить на Емаксе, написанные независимыми людьми с довольно длительным стажем программирования. Я помню, как пытался пару раз перейти на Емакс, а потом жаловался приятелю с другого города, который, по его словам, активно использует. Я помню, как я называл этот редактор нехорошими словами, поливал грязью и всячески унижал в надежде, что кто-нибудь скажет «Парень, ты идиот, ты просто не понимаешь вот это, и вот это, и потому так говоришь; хватит нести чушь!», но приятель был единственным человеком, кто мог ответить что-то дельное, и он почему-то молчал. А потом, словно после аварии на большой скорости и негоночной трассе, я неожиданно очутился в кресле, рядом бежали циферки tcpdump’а в терминале и я что-то быстро набирал в редактор Емакс. «Очнулся — гипс».
У людей, впервые берущих Емакс в руки есть в корне неправильное ожидание от этого редактора, на чем я не раз оступался, и из-за чего далеко не сразу стал его использовать. Я вижу, как крутые дяди с опытом программирования 30+ лет, доктора наук, используют его вместо IDE и потом пишут об этом посты, как все круто в их мире. Но в моем мире, когда я попросил сварочный аппарат на пару десятков киловатт, мне дали в руки трут, много дров, огромный фолиант, и сказали, что завтра здесь будет жарко. И еще посоветовали не перепутать томик с древесиной.
Необходимо понимать, что прежде, чем он у вас заработает, вас придется потратить уйму времени на его настройку. И, даже не надейтесь, что вам удастся избежать изучения elisp (язык, используемый оным редактором для скриптов) — если, конечно, вы не хотите искать помощи только из-за того, что найденный кусок кода в какой-нибудь социалке на вроде Github’а с чьего-нибудь конфига работает не совсем так, как написано в комментарии.
Но это все лирика — я совсем не профи в лиспе, да и статья, как мы помним, отнюдь не о нюансах конфигурации Емакса, поэтому постараюсь оставить в стороне эту тему.
Итак, поскольку по временному отрезку мы еще не достигли Vim’а, у нас есть только знаменитые своим неудобством комбинации для передвижения через Alt/Ctrl плюс буква. Мини-памятка для тех, кто не в курсе, или не помнит:
Поверьте, их неудобство вызвано лишь непривычкой! Я знаю, есть люди, кто меняют местами Caps-Lock и Ctrl, я этого не стал делать, и привык передвигаться на упомянутые клавиши вместо стрелок всего за пол-недели. Насколько это удобно в сравнении со стрелками, спросите вы. О, это очень, очень удобно! Во-первых, вам не надо переносить руку к стрелкам. Это очень круто, потому что если ваш слепой набор базируется не на отличной ориентации в пространстве — когда вы можете держа пальцы, где угодно, попасть не глядя на любую клавишу — а на расположении указательных пальцев на засечках кнопок «f,j», то вам придется каждый раз для печати искать эти выемки; и неважно, наугад или взглядом. Во-вторых, стрелки могут на [нет/ноут]буках, и клавиатурах не очень адекватных производителей располагаться на довольно разных расстояниях, окруженные очень разными клавишами, и возможно даже без зазоров(как на моем ноуте) — т.е. если у вас нет идеального ощущения пространства и вы не пользуетесь этой клавой много лет вам придется каждый раз или подглядывать, куда вы перенесли пальцы, или часто ошибаться, нажав случайно не ту кнопку. Говоря честно, кнопка Ctrl на некоторых клавах тоже может находиться черт знает где, и тут придут на помощь комбинации vim’а, но об этом позже.
Другая незаменимая комбинация — «Ctrl+x b», она переносит курсор в поле для ввода имени буфера (aka открытого файла), в который вы хотите перейти. Автодополнение по табу. И, если у вас включен «ido-mode», как у меня, то в этом поле так же будет список поместившихся имен буферов, вам достаточно будет лишь набрать часть имени буфера и этот список отфильтруется соотв. Вы можете дописать имя или просто выбрать на «Ctrl+s», «Ctrl+r» подходящее имя. Насколько это удобно? Скажу так: я не так давно кодил в Visual Studio, и, чтобы перейти на вкладку, мне приходилось использовать комбинации VsVim типа «Пред. вкладка», «След. вкладка», «Вкладка №n». И это ok’ей, пока у вас не открыто 100500 вкладок, пара сплит скринов и как переключаться между этим всем богатством становится совершенно непонятно. Остается только брать в руки мышь. Часто брать в руки мышь. Наверное, для людей непосвященных это покажется странным доводом: ну и что с того, почему бы и не воспользоваться курсором? Скажем так — когда вы знаете, что есть способ сделать что-то намного быстрее, и практически рефлекторно другие пути, которые требуют переключения внимания, занимают больше времени, и не вводят никаких плюсов, начинают просто раздражать.
Чтобы вы прониклись с идеей про мышь, я приведу пример, очень близкий сердцам IDE’шников: представьте, что вам надо переименовать локальную переменную под курсором. Итак, вы можете α) Вывести контекстное меню, и ввести новое имя β) Написать простенькую регулярку вида «\bmy_var\b», и проследить, чтобы замены были только в пределах функции. Если вы не знаете про вариант α, вам будет совершенно комфортно со случаем β, т.к. это рядовая ситуация, и она явно лучше, чем переименование вручную. Но, когда вы вкусили острые крики переменной, растворяющейся в небытии лишь парой ваших кликов, вы будете стараться всеми силами избегать варианта β: он плохой, он злой, он враг, он раздражает, он заставляет вас делать слишком много движений, он заставляет вас переключаться, одно неверное движение — и вы порезались.
Еще в Емакс есть буфер «*scratch*». Это черновик, автоматически создается каждый раз, когда вы запускаете его. Там стоит предупреждение о его предназначении. Суть, что он по-умолчанию не сохраняется. Его можно применять для написания кратких мыслей, например, о том, как будет выглядеть ваша архитектура — просто, чтобы быть уверенным, что ничего не упущено. Или для тестирования регулярок, а может для краткой заметки, что доделать, как вы вернетесь с выходных (это, если вы, как я, не выключаете ПК — я его просто кидаю в гибернацию). Да куча применений, я уверен, что у вас есть что-то подобное. Пока я юзал SublimeText, у меня всегда был подобного рода файл открыт, правда проблема была в том, что этот файл всегда сохранялся, хотя мне это нужно не было. В какой IDE есть подобная штука? Да, хотя бы, в каком еще текстовом редакторе такая вещь есть?
Когда я начал использовать Visual Studio, я был просто поражен тем, насколько она зависима от intellisense. Стоит в коде появиться малейшей ошибке, и индентация перестает работать. Представьте, что у вас есть функция всего на около полусотни строк с кучей полей видимости, try-catch, и прочего хлама. И вас неожиданно озаряет, что, в-общем то вот тут исключения точно не будет, да, и, вон там можно все переделать. Вы начинаете удалять одни куски кода, переносить другие, и тут — achtung! — интеллисенс обнаруживает ошибки, и вы не можете больше нажать на кнопку, чтобы изменить индентацию по функции, она быстро погружается в хаос! Но такая ситуация может быть довольно редко, поэтому другой пример — до того, как я попробовал Visual Studio, у меня была частая привычка выписывать функцию псевдокодом, а потом писать поверх черновика настоящий код. Основано на печальном опыте, когда логика какой-то функции кажется очевидной, и ты пишешь сразу код, кучу проверок на ошибки, и пр., а потом обнаруживаешь, что не учел сущую мелочь, и теперь надо все перелопатить. Так вот, в Емаксе достаточно выделить кусок кода, и нажать на таб — и он выравняется независимо от того, какие ошибки в коде нашел «flycheck». То же относится и к vim(клавиша «=» для выравнивания).
Другая просто незаменимая клавиша «Super-i». Нет, не ищите, это кастомная комбинация, она запускает функцию «ido-menu», и я просто не представляю, как люди, пользующиеся IDE живут без нее. Она работает похожим образом, как выбор буфера, упомянутый мной ранее, только выводит список функций в текущем файле. Это невероятно удобно: вы нажали гор. клавишу, ввели часть функции, какая вам навскидку пришла в голову, и нажали ввод. Вернуться к предыдущему месту можно на «Ctrl-u Ctrl-space».
Но самая крутая штука в Емаксе — что вы можете найти/написать функцию, выполняющую какое угодно действие, и прибайндить к абсолютно любому событию в редакторе. Причем вам даже не надо рестартовать редактор, все происходит на лету. Например: никто не любит висящие пробелы в конце строк — зачем они? Не правда ли, был бы приятно, если бы перед сохранением они удалялись? Отлично, находим функцию «(delete-trailing-whitespace)», находим, что хук, выполняющийся перед сохранением файла, называется «before-save-hook», и добавляем функцию туда. А, может быть вам стукнуло в голову, как было бы круто, если бы в С++ перед сохранением файла все инклуды сортировались в алфавитном порядке? Великолепно! Пишем на тот же «before-save-hook» лямбду, которая проверяет, что текущий включенный режим С/С++, и ищет инклуды, затем их сортирует. Я таким образом случайно нашел в одном хедере два дублировавшихся инклуда.
Другая штука, которой не хватало позже в Visual Studio — «Alt+q», он выравнивает текущий параграф под заданное максимальное кол-во символов на строку. Т.е. если кол-во букв слишком большое, слова переносятся на следующую строку. Незаменимая вещь при редактировании комментариев к коду, и я не знаю, чтобы она была в, по-крайней мере, Visual Studio или CodeBlocks.
Если честно, я даже понятия не имею, что еще упомянуть, чтобы не сделать статью скучным перечислением фич Емакса. Функций в Emacs невероятно много на все случаи жизни, я уж не говорю, что не выходя из редактора, там есть поддержка терминала — серийного и обычного — дебаггера, контроль версий (правда в оном я не разобрался, но, просто, сильно не вникал), клавиатурные макросы, и еще черт знает что. Те, кто говорят, что полноценная IDE круче, просто не в курсе, что все их фичи в Емакс либо есть, либо могут быть доустановлены. Например для C# имеется т.н. omnisharp-server, который запускается отдельно, и потом к нему можно подключать Емакс для получения всех фич, вроде «go to definition», «переименование переменных и ссылок к ним», автодополнение, и пр. Проблемы обычно начинаются от незнания elisp, и нежелания при малейших вопросах просто посмотреть, как этот код работает. Я говорю потому, что сам был таким — не знал толком лиспа, и не мог настроить «omnisharp-mode». Туториалы мне казались недостаточно подробными. Вопросы отпали после того, как отчаявшись, но еще не желая задавать вопрос на форуме, я решил заглянуть в код плагина, и обнаружил, что на github даже пример конфигурации валяется.
К слову, первая ласточка интереса к Vim’у проснулась именно, пока я пользовался Емаксом. Абсолютно случайно я обнаружил, что там на кнопке «о» в «нормальном режиме» есть крутая функция, которая работает, как, если бы вы нажали в обычном редакторе «End» и «Enter» — она начинает новую строку без разрыва текущей. А большая «О» начинает новую строку над текущей строкой. Очень удобно, я забайндил подобную вещь на отдельную клавишу, но мне стало любопытно: а что еще есть в Vim, чего нет в Емакс?
Поэтому перейдем же, наконец, к VIM. Мое знакомство с этим редактором состоялось при печальных обстоятельствах: я начал работать в Visual Studio с кодом на С#, времени разбираться с работой Omnisharp server’a не было, т.к. я торчал на работе по 12+ часов по причинам проблем со сроками сдачи проекта и старался получить как можно больше опыта, на случай, если меня, как неопытного студента, просто уволят. Поэтому я решил просто настроить Visual Studio так, чтобы можно было комфортно передвигаться. И тут меня ждало ужасное разочарование: найденный плагин с Емаксовыми кейбайндингами напрочь отказывался работать; и даже когда я решил кое-как просто перенастроить, к примеру, «Ctrl-→» на «Alt-f», студия работала с комбинациями просто отвратительно. Во-первых, если нажать Alt и отпустить — бывает такое, что хотел прыгнуть на слово вперед, а потом передумал — при попытке продолжить писать код ты можешь закрыть файл, запустить дебаггер, вызвать из бездн ада яблочного монстра или случайно стать первым человеком, убитым самозародившейся сингулярностью. Потому что при отпускании альта без нажатия любой другой клавиши курсор перепрыгивает в меню студии (где File, Edit, и пр.), где каждой букве соответствует какое-нибудь подменю. Это очень большая проблема, и как это отключить, я так и не смог отыскать. Исходя из поиска в интернете, я сделал вывод, что это «фича» оконного менеджера под Windows и ее отключить невозможно.
А во-вторых, в Visual Studio (achtung!) нет команды «прыгнуть к концу слова»! Т.е. шорткат «Ctrl-→», работающий везде именно таким образом, в IDE вас отправлял к началу следующего слова! Это было просто ужасно, я промучался так пару недель и осознал, что в 80% случаев после того, как я допрыгал до начала следующего за интересующим меня слова, приходится еще раз жать клавишу, чтобы возвратиться на символ обратно.
Тогда-то я вспомнил, что читал про некий плагин под Visual Studio, эмулирующий функционал VIM. Называется он VsVim, и он великолепен. И да, таки в нем есть команда «перейти к концу слова»! Это был новый виток эволюции: зная, что что-то должно быть автоматизировано нажатием на одну клавишу, я просто вводил в гугл, как это сделано в VIM’е, и, практически всегда, это было реализовано и в VsVim, теми же клавишами, или командами. К передвижению на hjkl я привык в течении, может, половины недели, как максимум.
«Почему Vim?» Помните, я рассказывал, как круто использовать комбинации «Ctrl/Alt-key» вместо стрелок. Так вот: тут вам не надо было даже нажимать Ctrl. Поначалу кажется, что отстукивать каждый раз по Escape проигрывает, но поверьте мне, это тоже просто дело привычки. Кроме, может, крайних случаев, когда надо переместиться лишь на несколько букв вправо/влево.
Помимо лучшей навигации по коду это дало мне, наконец, полноценный слепой набор и научило навскидку оценивать кол-во тех или иных объектов. Причина последнего в том, что почти любая команда vim принимает цифру, которая означает, как правило, кол-во раз, которое команда должна быть выполнена. Разумеется, это было и в Emacs, но там необходимо было дополнительно с цифрой жать Alt или Ctrl, что, в отсутствие умения нажимать на цифру вслепую, энтузиазма не добавляло. И потому цифры там мной использовались только в крайних случаях, но никак не в повседневных операциях, вроде перехода на несколько слов вбок. Здесь же добавить к команде префикс было проще простого и потому я очень скоро запомнил, какие цифры (и символы, которые там тоже в активном использовании) находятся на цифровом ряду, и какими пальцами их лучше нажимать.
Ну и, под конец, коронная фича vim — текстовые объекты. Незаменимая штука во время кодинга. Дело в том, что многие команды (в частности, удаление, выравнивание, копирование) принимают постфиксы, причем довольно интуитивные. К примеру, надо нам выровнять код внутри квадратных скобок? Жмем «=i<» Хотим удалить все изнутри угловых скобок, включая их самих? Жмем «da