Стоит ли тратить время на изучение Emacs?
Сразу: я не хочу начинать религиозную войну.
Я использовал vi столько, сколько себя помню, и несколько раз, когда я пытался подобрать Emacs, я был настолько потерян, что быстро сдался. Однако многие находят Emacs очень мощным. Его программируемость несколько легендарна. Я в основном занимаюсь разработкой Solaris+Java, и я хотел бы задать простой вопрос: увеличится ли моя производительность, если я потрачу время на изучение Emacs? Будет ли функциональность, которую он предлагает по сравнению с Vim, окупить за счет увеличения производительности в разумные сроки?
Повторяю: я не хочу, чтобы ответ "мой редактор лучше, чем ваш". Я просто хочу ответить "да" или "нет" относительно того, стоит ли тратить время или нет. Моя производительность действительно увеличится?
29 ответов
Я предпочитаю emacs vi, но мне комфортно в обоих.
В emacs есть некоторые вещи, которые делают его более мощным, чем vi, но не все они даже связаны с программированием. (Можете ли вы отправить электронное письмо или прочитать новости из vi? Нет, но кого это волнует?) Если вы знакомы с lisp (а я нет), вы можете написать дополнения, режимы и прочее, чтобы сделать вашу жизнь проще, но это, скорее всего, будет синтаксическая раскраска и сопоставление скобок и тому подобное.
Я перестану бродить сейчас. Увеличится ли ваша производительность при использовании emacs? Нет.
Обновление: см. Мой комментарий ниже. С тех пор как я опубликовал это, я столкнулся с тем, что использование emacs сделало меня более продуктивным, чем использование vi.
[Отказ от ответственности: лично я предпочитаю Vim. Отказ от ответственности Отказ от ответственности: читать дальше.]
Vim выделяется небольшим: создавая отдельные понятия "движение" и "действие" и предоставляя возможности для сложных повторов, вы можете выполнять невероятно мощные операции редактирования всего за короткую последовательность нажатий клавиш. Вы можете легко делать вещи в Vim в обычном режиме редактирования, который потребует от вас перехода к сценариям в Emacs. Кроме того, большая часть используемой вами энергии выходит из коробки, так что даже если у вас есть обширный .vimrc настройки, скорее всего, вы сможете продуктивно работать с любой установкой Vim.
Emacs выделяется в целом: сопоставляя все свои концепции пользовательского интерфейса непосредственно с базовыми конструкциями и концепциями в Elisp, становится очень легко глобально вводить функции для определенных типов файлов или обстоятельств, делая Emacs чем-то вроде текстового и гораздо более структурированного программируемая форма Excel. Это предполагает, что вы собираетесь потратить много времени на настройку среды для личных нужд и предпочтений. Конечно, Emacs делает все возможное, чтобы вам было легко оставаться внутри этой единой среды для всего и всего, что вы захотите сделать.
В конечном счете, ни один из них не превосходит. Они предлагают разные стили, и в зависимости от ваших склонностей, один или другой подойдет для ваших личных потребностей и мышления лучше. Конечно, всегда полезно знать и то, и другое (и больше редакторов). Но вы не собираетесь быть значительно более продуктивным, так или иначе.
Ви кухонный нож.
vim - действительно хороший, острый, сбалансированный нож шеф-повара.
Emacs - это легкая сабля.
Большую часть времени моя работа требует от меня нарезать овощи. Иногда мне приходится сражаться с целой армией роботов.
Я использую Emacs в течение 20 лет. Я сейчас набираю в Emacs виджет под названием "Это весь текст", который позволяет мне вставлять и выводить текст из текстовых полей в Firefox. Я могу идти очень быстро в Emacs. Я значительно менее продуктивен без этого.
Это очень спорно, но я также думаю, что изучение Emacs может научить вас удивительное количество о программировании.
В зависимости от того, как вы кодируете, вы можете увидеть увеличение производительности. Что касается фона, я также давний пользователь vim, но я изучал emacs около 2 лет назад, и теперь использую их как взаимозаменяемые.
Что привело меня к сути изучения emacs, так это его полезная способность открывать большое количество файлов одновременно и легко переключаться между ними. Я был в середине представления функции, которая добавила и коснулась большого количества классов. (Это был C++, поэтому, как правило, в каждом классе было по два файла.) Поскольку я все еще улучшал интерфейс, я обычно занимался обновлением одного файла, когда осознавал, что мне нужно изменить другой.
С gvim было проще всего открыть новое окно для каждого файла, которое начинало становиться громоздким. Однако в Emacs было просто открыть новый файл в том же окне (Ctrl-x, Ctrl-f). Когда в Emacs открыт файл, очень легко переключаться между открытыми буферами (Ctrl-x, Ctrl-b).
Если сделать еще один шаг вперед, то в одном сеансе emacs может открыться много окон, поэтому, помимо разбиения окна по вертикали, я мог бы решить, не прерывая работу над файлом, открыть еще один рядом с ним, что позволило бы мне эффективно работать параллельно. сторона, сохраняя при этом каждое окно с шириной по умолчанию 80 символов.
В vim мне все еще есть некоторые вещи (например, режим выбора блоков, простая запись макросов, режим diff), и вещи, которые проще в Emacs (выравнивание строк, управление файлами / буфером, управление окнами / экранами). Поэтому, я чередуюсь между ними (и иногда использую оба одновременно), в зависимости от задачи редактирования, которую я ожидаю.
Если вы все еще не уверены, я бы посоветовал попробовать. Просмотрите учебник по Emacs, а затем используйте его для написания кода на утро или день, сильно опираясь на помощь. Если вам все еще не нравится то, что вы видите, оставайтесь с vim. Независимо от того, что редактор приносит на стол, ваше знакомство и знание этого инструмента, безусловно, будет самым важным фактором вашей производительности.
Я не хочу священной войны, но, пожалуйста, ответьте на очень субъективный вопрос с ответом да / нет.
Да, вы можете увидеть увеличение производительности из-за мощной функциональности.
Нет, вы не увидите увеличения производительности, потому что шаблоны и метафоры, используемые в Emacs, могут не соответствовать вашему мозгу.
Краткий ответ на ваш вопрос: "ДА". Более подробно ниже.
Я использовал vi почти исключительно с 1980 по 1991 год. Единственный раз, когда я не использовал vi, это когда я имел дело с минимальной установкой Unix, которая была слишком мала, чтобы включать vi, поэтому мне пришлось вернуться к ed, который является минимальное подмножество функций редактирования, над которыми был построен оригинальный vi.
Примерно с 1985 года другие программисты, где я работал, постоянно пели хвалу emacs. Но каждый раз, когда я пытался научиться этому, я не очень далеко ушел. Я бы потратил целый час на просмотр emacs turorial (Ch t), и к концу всего этого я знал бы, как вставлять и изменять текст и перемещаться по экрану. Я мог сделать намного больше с vi, чем то, чему я научился за тот час с emacs, что я не смог сделать это. Три месяца спустя я нашел время, чтобы провести еще час, и в итоге я просмотрел тот же материал. Emacs имеет кривую обучения с большой буквы "L". Только когда я подписал контракт, в котором все остальные использовали emacs, я решил, что мне нужно посвятить больше часа изучению этого. Потратив чуть больше дня, ничего не делая, кроме проработки учебника и прилагаемой документации, я, наконец, пришел к тому, что я могу делать вещи с помощью emacs, чего не могу с vi. С тех пор я никогда не хотел возвращаться. Я все еще могу набирать команды vi во сне, но я могу сделать гораздо больше с emacs.
Поймите, что я сравниваю emacs и vi, а не vim. Я никогда не изучал расширения, которые vim добавил в vi, и, вероятно, многие из них являются функциями, скопированными из emacs. Если это так, и если вы уже хорошо владеете vim, emacs может не дать вам столько преимуществ.
Среди вещей, от которых я зависел все время в emacs:
Когда вы используете emacs, все воспринимается как текст. Это означает, что вы можете манипулировать любыми данными в любом буфере практически одинаковыми командами. А в тех случаях, когда буфер в режиме, когда некоторые стандартные команды недоступны, вы можете скопировать текст в другой буфер, работающий в основном режиме, и использовать стандартные команды там.
Emacs предоставляет многооконный интерфейс, отображаемый в терминале символьной ячейки. За несколько дней до появления растровой графики и реальных окон emacs был написан для имитации поведения, подобного окнам, используя только символы ascii и позиционирование курсора. Вы, вероятно, думаете: "Это древняя история. Зачем сегодня кому-то это нужно?" Я все еще использую эту возможность каждый день. Я использую компанию веб-хостинга, которая позволяет мне доступ по SSH. Таким образом, я могу войти на хост Linux через Интернет и запускать команды оболочки. Хотя это довольно мощно, гораздо мощнее иметь возможность разделять мой эмулятор терминала на "окна" с помощью emacs, запускать оболочки в некоторых из этих "окон", редактировать файлы в других окнах, а также просматривать и редактировать каталоги в других ". окна".
На самом деле, когда я сказал "окно" в предыдущем абзаце, я действительно имел в виду "буфер". Эмуляция Windows в Emacs - это способ разделить экранную область. Буфер emacs связан с контентом (файлом, оболочкой bash, каталогом, произвольным текстом, не связанным с файлом и т. Д.), Который может отображаться или не отображаться в данный момент. Чтобы посмотреть, что находится в буфере, вы выбираете окно и сообщаете ему, какой буфер вы хотите увидеть. Таким образом, вы можете работать над большим количеством вещей, чем у вас есть место на экране для отображения. Это примерно аналогично тому, что вы делаете в современном графическом интерфейсе с растровой графикой, когда вы делаете иконизацию / де-иконизацию окна.
Я уже упоминал о том, что вы можете запустить оболочку внутри буфера emacs. Вы можете иметь столько буферов для запуска оболочек, сколько захотите. Вы можете копировать и вставлять текст туда и обратно между буфером оболочки и текстовым файлом или сравнивать часть текста между буфером оболочки и текстовым файлом, используя точно такие же последовательности нажатий клавиш, которые вы использовали бы для копирования текста или сравнения текста между двумя разными текстовые файлы. На самом деле, это верно для большинства типов буферов, а не только для буферов оболочки и буферов, связанных с файлами.
Когда вы используете команду emacs для открытия файла, но на самом деле вы выбрали каталог, буфер работает в режиме dired (редактор каталога). В этом режиме одно нажатие клавиши открывает все, на что в данный момент указывает курсор, будь то файл или подкаталог. Буфер в режиме Dired - это файловый менеджер - ориентированный на символьно-терминальный аналог аналог Finder на Mac или Windows Explorer.
Одна из функций emacs, которую я использую почти постоянно, это "сравнивать окна". Я очень предпочитаю это инструментам сравнения diff и GUI, например, встроенным в Eclipse. Diff или Eclipse сравнивают целые файлы и показывают, какие строки различаются. Но что происходит, когда у вас есть две разные линии, которые очень похожи? Учтите следующее:
В чем разница между этой линией и другой?
В чем разница между этой линией и другой?
Сколько времени это займет у вас, чтобы заметить разницу? (Подсказка: ASCII и Unicode апострофы очень похожи.)
В отличие от diff и Eclipse, которые просто показывают линии, которые отличаются, функция emacs "сравнить окна" является интерактивной. Вы размещаете курсор в каждом из двух параллельных окон в точке, где содержимое окна одинаково. Запустите "сравнивать окна", и курсор в каждом окне переместится на первый отличающийся символ. Поместите курсор в одном из окон в точку, где он совпадает с другим окном, и перезапустите "сравнивать окна", чтобы найти следующее отличие. Это позволяет легко сравнивать части файлов.
Еще одна вещь, для которой я регулярно использую "сравнивать окна" - это сравнение контрольных сумм. Многие программные проекты распространяют тарболл приложения на странице, которая также включает в себя хэш MD5 тарбола. Итак, как сравнить хеш MD5 на странице распространения с хешем MD5, вычисленным из загруженного файла? Emacs делает это тривиальным.
Сначала скопируйте хеш MD5 с веб-страницы в новый буфер emacs. Затем, после загрузки файла.tar.gz, запустите:
md5sum downloadfile.tar.gz
в буфере оболочки. Когда эти два буфера будут отображаться в параллельных окнах emacs, поместите курсор в каждом окне в начале контрольной суммы и запустите "сравнивать окна". Если они одинаковые, курсор в каждом окне будет располагаться в конце каждой контрольной суммы.
В предыдущем пункте я привел пример запуска "сравнивать окна" в строках:
В чем разница между этой линией и другой?
В чем разница между этой линией и другой?
"Сравнить окна" оставит курсор в апострофе в каждой строке. Итак, теперь вы знаете, какие символы отличаются. Но что это за персонажи? Введите две комбинации клавиш CTRL-x =, и emacs отобразит символ, его значение ascii в восьмеричном, десятичном и шестнадцатеричном виде, смещение символа от начала файла и смещение символа от начала строки. Поскольку ASCII является 7-битной кодировкой, для всех символов ASCII их старший бит отключен. Как только вы увидите, что значение первого апострофа равно 0x27, а второго - 0x92, становится очевидным, что первый находится в наборе символов ASCII, а второй - нет.
Emacs был одним из первых IDE, возможно, самым первым. У него есть режимы для определенных языков. Я считаю их удобными для наложения последовательного отступа на мой код, чтобы сделать его более читабельным. Также есть встроенная функциональность для компиляции и отладки кода. Я не очень часто использую функции компиляции, потому что когда я писал для скомпилированного языка, такого как C, я привык делать это по приглашению оболочки. Функциональность отладки была очень хороша для C и C++. Он интегрировал gdb с редактором таким образом, что вы получили почти те же функциональные возможности, что и возможности отладки, которые есть в Eclipse, но не тратите впустую экранную среду, как это делают современные IDE на основе графического интерфейса. Теоретически интеграция отладчика должна быть простой, чтобы его можно было применять практически к любому другому языку, но я не проверял, с какими другими языками он работает в настоящее время.
Emacs позволяет вам создавать макросы, сообщая, когда начинать запоминать то, что вы печатаете, а когда останавливать. Это чрезвычайно эффективно для задач, которые вы часто делаете.
Emacs бесконечно расширяем, если вы знаете Lisp. Но даже несмотря на то, что я никогда не изучал Emacs Lisp, я все же нахожу Emacs одним из самых мощных инструментов, которые я когда-либо использовал.
Связки клавиш Emacs. Я буду первым, кто признает, что привязки клавиш в Emacs - отстой. Но он настолько мощнее, чем все остальное, что я использовал, что я готов мириться с привязками клавиш.
В юмористическом ключе, несколько лет назад автор Emacs Ричард Столлман (также создатель GPL, основатель проекта GNU и основатель FSF) прославляет тех, кто рассматривает vi против emacs как священную войну. Он изобрел символ "Святой Игнусиций" церкви Emacs. В этом облике Столлман прокомментировал: "Иногда люди спрашивают меня, является ли грехом в Церкви Emacs использование другого текстового редактора vi. Что ж, это правда, что vi vi vi является редактором зверя, но использует бесплатную версию Ви не грех, это покаяние ". (См. http://stallman.org/saint.html. Там также есть его симпатичная фотография, но, поскольку я новичок в Stackru, он не позволит мне публиковать более одного URL. Так что перейдите на тот же домен, но получить файл saintignucius.jpg)
Я использовал Vim в течение 10 лет, в результате чего 2 года назад углубился в Emacs. У меня есть достаточно свежее воспоминание о том, как менялась моя кривая производительности с течением времени.
Мои очки все условны, YMMV в зависимости от ваших сил и опыта.
Если вы использовали Unix и командную строку достаточно долго, чтобы вы были знакомы с Ca, Ce, Cn, Cp, Ck, Cy и т. Д., Поскольку они функционируют в оболочке, то переход к использованию тех же привязок не займет много времени (по умолчанию) в Emacs. Недавно я обнаружил, что XCode также использует эти привязки.
Если вы чувствуете себя комфортно с постоянно работающим редактором, работающим с буферами (как с вкладками браузера) и тем самым живущим в приложении (как если бы вы работали с приложениями Web2.0 в браузере), Emacs, вероятно, покажет немедленные улучшения производительности.
Если вы обычно работаете в проектах со многими связанными файлами, это постоянство дает дополнительные преимущества в поддержании контекста для этого буфера. Каждый буфер находится в своем открытом файле, что позволяет удобно использовать различные инструменты повышения производительности для вашего проекта (такие как grep-find, eshell, run-python и slime). Это в сочетании с завершением текста, яснипетами и т. Д. Начинает выглядеть крошечной частичкой, как в IDE, хотя и индивидуально и сильно индивидуализировано вашей конфигурацией. Это помимо более цивилизованных сервисов, подобных Emacs IDE, таких как ECB.
Первоначально моя производительность сильно пострадала, поскольку я постоянно набирал "jjjkkk" Esc-Esc-Esc-Esc в течение первой недели или около того. На следующей неделе я осторожно начал использовать правильные клавиши навигации. Затем я обнаружил файл конфигурации... Честно говоря, если бы у меня был Emacs Starter Kit с самого начала, я бы сказал, что моя производительность постепенно снижалась до паритета за 3-4 недели, но я все-таки пробежал по кроличьей норе в файле конфигурации. Мой коллега, однако, только что перешел от vim к emacs, и он только что взял Starter Kit, и он уже в пути. Первая неделя, и он, кажется, чувствует себя комфортно и наслаждается всеми неожиданными преимуществами (это ощущение, вероятно, продлится десятилетие).
Наконец, если вы сделаете ошибки, вы сразу же получите производительность (и уверенность) от кругового кольца убийства / отрыва и отмены. Я также лично являюсь поклонником откатов по конкретным регионам.
Мой короткий ответ: да, стоит потратить 3-4 недели на снижение производительности для изучения Emacs. Даже если вы решите, что для разработки вы предпочитаете упорядоченную комбинацию утилит для Unix, а не Emacs, вы получите образование, широко применимое помимо редактора.
Документация Emacs - это лес. Я перешел из Emacs в Vim, когда понял, насколько организована документация Vim, и насколько много функций у них есть. Я не знаю, что стоит на пути эксперта по Emacs, но я предупрежу вас, что научиться делать что-то полезное в этом занимает много времени, и вы не станете лучше в Nethack. Придерживайтесь Vim.
TextMate лучше Emacs для Mac, но это не поможет вам с Solaris. Eclipse - это круто, и в нем много плагинов.
Emacs обеспечит повышение производительности, если вы захотите изучить и настроить его под свои нужды. Большинство людей нет. Чтобы повысить производительность, вы должны использовать инструмент для более простого редактирования - большинство людей никогда не переходят дальше простого редактирования.
Вот быстрый тест: настроили ли вы свой оконный менеджер, чтобы сделать вашу среду более эффективной (с учетом ваших потребностей)? Если "нет", то, вероятно, вы не получите ROI, изучая Emacs.
При этом, если вы разрабатываете Java, Eclipse является стандартным ответом, поэтому ваш вопрос довольно спорный.
Я был очень доволен своим Vim, но как только я услышал об орг-режиме, я начал изучать Emacs. org-mode может быть одной из серьезных причин для изучения Emacs.
Я люблю emacs и использую его каждый день.
Тем не менее, я не думаю, что стоимость обучения будет компенсирована ростом производительности в будущем.
Если вы программируете Java, вам нужна хорошая IDE. Emacs идет полным путем, чтобы быть единым целым, но давайте посмотрим правде в глаза, IDEA и др. Победили его. (Emacs, вероятно, вдохновил многих из этих IDE, но это другая история).
Дважды я пытался выучить Emacs. Это просто не соответствует тому, как работает мой мозг, и поэтому я им не пользуюсь.
Emacs (или vim) не намного лучше, чем vim (или Emacs). У обоих есть много опций, которые позволяют им делать удивительные вещи. Я не сомневаюсь, что все, что вы можете сделать в Emacs, вы также можете сделать в Vim, просто не стандартно.
Попробуйте Emacs. Посмотрите, подходит ли оно лучше. Это беспроигрышная ситуация.
vim и emacs, они являются наиболее способными редакторами и были в течение достаточно долгого времени. Если вы действительно хорошо это знаете, я сомневаюсь, что вы получите так много в этом процессе...
Однако всегда полезно посмотреть, какие плагины доступны, поскольку пара новых плагинов может творить чудеса с точки зрения производительности.
/ Johan
Я хочу изучить emacs дальше, но просто не могу использовать его долгое время; это больно мои руки. Я делаю что-то ужасно неправильно?
В том же духе: не искать религиозную войну (но продолжайте и опускайте меня, если считаете, что должны), почему вы чувствуете, что единственным вариантом для vi является emacs? Это ОС, на которой вы разрабатываете, или только варианты, которые вы исследовали?
В настоящее время в среде разработки Java используются одни из лучших IDE (как бесплатных, так и платных), если не лучшая, когда дело доходит до поддержки редактирования кода и рефакторинга. В IntelliJ IDEA даже есть плагин vi, который поможет вам чувствовать себя как дома, например (не уверен, что что-то подобное доступно для Eclipse). Хотя изменение инструментов подразумевает кривую обучения, время, потраченное на это, может стоить того, если скачок достаточно велик.
Как правило, emacs более мощный, чем vi. Вы могли бы сделать намного больше вещей в Emacs.
Как быстро вы печатаете? Если вы охотитесь и клюете, то Emacs не для вас. Если вы быстро, это может помочь не хватать мышь все время.
Моя производительность действительно увеличится?
В первые дни / недели абсолютно нет.
После того, как вы перестанете читать учебник каждый раз, когда хотите что-то отредактировать - обязательно..
Emacs является более "мощным", чем vim, его механизм сценариев гораздо более гибок, и существует гораздо больше сценариев, режимов и подобных им созданных вокруг Emacs.
Тем не менее, верно обратное. Если бы вы потратили столько же времени на улучшение своих знаний о vim, вы могли бы быть столь же продуктивными..
Может быть, не так продуктивно - я бы сказал, что vim быстрее редактирует файлы, emacs лучше делает все остальное (опять же, я бы лично сказал что-то вроде flymake-mode, Привязки VCS таковы, что их быстрее использовать, чем эквивалентные vim)
Хорошая причина для изучения Emacs заключается в том, что другие программы тоже используют сочетания клавиш Emacs. Вы можете использовать сочетания клавиш Emacs, например, в командной строке bash или что-то еще, используя GNU readline. Хорошо изучить основные движения и удаление слов / строк и отменить / повторить аккорды в Emacs, чтобы их можно было использовать в других программах. Ваша производительность увеличится в этих других инструментах, даже если вы никогда не будете использовать Emacs снова.
Я знаю Vim и Emacs, и Vim лучше подходит моему мозгу и моим привычкам. Но другие люди утверждают то же самое об Emacs. Вы никогда не узнаете сами, если не попробуете. Это не займет много времени, чтобы изучить Emacs достаточно хорошо, чтобы увидеть, понравится ли вам это.
Ваша производительность увеличится, если вы решите потратить время на программирование вашего текстового редактора. Из двух редакторов, Emacs представляет лучшую структуру или постоянную настройку. Если вы не программируете свой текстовый редактор, просто оставайтесь с тем, что вам удобно.
Если вы беспокоитесь о здоровье своих рук, выберите Vim.
Я страдал от приступа RSI в прошлом, и я обнаружил, что одним из главных виновников была "чириканье", т.е. одновременное нажатие множества клавиш. Emacs широко использует запись, в то время как VIM использует однобуквенные команды, соединенные в цепочку в быстрой последовательности. Это значительно снижает нагрузку на руки, так как мышцы не должны изгибаться и искажаться для выполнения команд в редакторе. Травма из-за RSI может разрушить вашу производительность, поэтому в ваших расчетах обязательно учитывайте это.
Я согласен с Аланом Штормом: "потому что шаблоны и метафоры, используемые в Emacs, могут не соответствовать вашему мозгу"
Это очень важный фактор. Разные мозги по-разному адаптируются к разным интерфейсам.
Некоторые из основных - и легко доступных - функций, за которые я действительно люблю Emacs, и которые я считаю повышением производительности:
1. Средство "yank-pop" - каждый вырез / копия сохраняется в стеке, так что вы можете позже выбрать, какой вставить (не знаю, есть ли в vi / Vim такая возможность, но большинство Java IDE этого не делают)
2. отображение навигации по клавише Ctrl- это позволяет перемещаться по файлу, не отрывая рук от использования клавиш со стрелками. (связка клавиш в других редакторах помогает, конечно)
3. Доступно практически на любой платформе (конечно, верно и для vi / Vim) - будь то графический или текстовый интерфейс (Java IDE также доступны на большинстве платформ, но только в режиме графического интерфейса, они значительно больше и требуют отдельной установки тогда как Emacs, как правило, более широко доступен - системы BSD / *nix / Linux / Mac
4. Я предпочитаю, чтобы мой редактор оставался в стороне до тех пор, пока мне это не нужно - спартанский дисплей Emacs заставляет меня задуматься, прежде чем печатать.
5. Базовые навигационные клавиши в Emacs доступны повсеместно - в моей Mac OS я могу использовать эти клавиши в терминале, почте Mac и т. Д.
В конечном итоге, если философия Emacs понравится вам, вы приложите дополнительные усилия для ее изучения. И это вознаградит вас.
Мне нравится Emacs, вы можете расширить его своими потребностями - на мой взгляд, любая система, которую вы можете расширить самостоятельно, заслуживает награды.
Поскольку vi/Vim и Emacs довольно близки с точки зрения того, что они могут или не могут делать, производительность этих двух редакторов зависит от опыта их использования.
По моему мнению, будучи программистом, вам не понадобится много времени, чтобы получить общее представление о Emacs, как только вы начнете его использовать. Другие могут только сказать так много, вы должны попробовать это сами, чтобы узнать это.
Что касается меня, я использую оба. Это все равно что брать на войну более одного оружия, использовать правильное оружие в правильных обстоятельствах.;)
Отказ от ответственности: я не знаю. Я был пользователем emacs около 4 лет, а vim - около 6 месяцев, может быть, больше, чем 15, если вы посчитаете, сколько раз я пытался его изучить и ненавидел. (Письмо против различия в режиме движения убивает меня. Каждый раз. Так что, если это не убьет вас, мое мнение может оказаться совершенно бесполезным.) Тем не менее, я думаю, что мое мнение на самом деле интересно отличается от 26 других, которые я видел здесь, так что я собираюсь озвучить это.: Юридическая информация
Мое мнение:
- Emacs лучше подходит для набора текста, особенно для крупномасштабных "Я пишу новую функцию, и пройдет некоторое время, прежде чем я даже попытаюсь увидеть, работает ли она".
- Vim лучше подходит для редактирования, особенно для быстрого редактирования.
Когда мне нужно понять и взломать 8 файлов одновременно, свойства Emacs в качестве оконного менеджера листов с несколькими буферами (буферы имеют соответствие файлов 1,2:1, часто это одно и то же, но не обязательно) regexp-поиск (и замена) невероятны.
Если мне не нравится какая-то маленькая вещь из-за git diff в оболочке (я не очень часто использую функции VC в emacs, хотя когда я это делаю, я люблю их), я открываю его с помощью vim и выхожу к черту быстрее, чем могу Alt-TAB,
Тот факт, что команды редактирования Emacs более доступны при вводе, делает набор текста намного быстрее, чем в Vim. Ctrl+a намного быстрее чем ESC ^ iи у вас нет когнитивной нагрузки "хочу ли я a или же i или же o или же O..."О, Боже, я ненавижу думать. И то же самое для всех других команд команд движения.
Я пишу быстрее, намного быстрее, в Emacs. Это означает, что такие вещи, как режим Org (который я использую для всего: списки TODO, отслеживание ошибок, заметки, длинные электронные письма, документация...) имеют больше смысла (для меня) в Emacs, чем в Vim.
И Элисп невероятен, хотя и отстой. Это полностью компенсирует испорченные регулярные выражения Emacs: вы можете использовать всю мощь emacs везде, в том числе в многофайловой замене регулярных выражений. И в текстовых отрывках.
Нет
Я использую emacs в течение многих лет, я - конверт из VIM, и мне это нравится.
Но любой выигрыш в производительности благодаря наличию лучшего программируемого редактора будет полностью уничтожен огромным количеством головокружительных усилий, необходимых для освоения emacs. Он был разработан как редактор консоли, и его идея интерфейса не ваша.
И даже когда вы получите его полностью, ваша дополнительная производительность будет в основном выражаться в дополнительном lisp-файле emacs, который вы можете написать.
Какая разница? Это очень весело, а собачки! Если вы хотите "добиться цели", тогда забудьте о программировании. Вы всегда можете нанять программистов, чтобы "делать" "дела".
Единственное обстоятельство, при котором я бы порекомендовал изучать emacs из соображений производительности, это если вы программист lisp / схема / clojure. Это создает такую хорошую среду для шуток, что затем несколько секунд, которые вы будете экономить каждый раз, когда вы хотите что-то сделать, быстро приведут к реальной выгоде. И elisp (который относится к lisp, как макросы Excel к ALGOL) будет казаться гораздо менее чуждым, если вы уже используете настоящий lisp.
Если вы попробуете это сделать, используйте его на виртуальной консоли, где это больше похоже на разумный способ размещения редактора. Только когда это имеет смысл, попытайтесь использовать его под оконной системой, которая будет бороться с этим.
В предыдущем ответе Аристотель Пагальцис писал: "Vim выделяется в малом... Вы можете легко делать вещи в Vim в обычном режиме редактирования, который потребует от вас перехода к сценариям в Emacs".
Я перешел на Emacs после более чем десятилетнего использования исключительно vi, и вначале я согласился бы с утверждением: "Вы можете легко делать вещи в Vim в обычном режиме редактирования, который потребует от вас перехода к сценариям в Emacs". Но затем я обнаружил, что, используя возможности макросов Emacs и большое количество повторений, я мог легко заставить Emacs делать практически все, что упрощало vi, и намного больше.
Функциональность макроса Emacs включает три команды:
C-x ( start remembering keystrokes
C-x ) stop remembering keystrokes
C-x e replay the remembered keystrokes
Например, в vi, если бы я хотел найти все <a> теги в файле HTML и добавить target атрибут, я мог бы сделать что-то вроде следующего:
:g/^<a/s/>/ target="_blank">/
Этот пример не идеален, поскольку предполагает, что все <a> теги находятся на одной линии. Но этого достаточно для иллюстрации того, как выполнить эквивалентную задачу в двух разных редакторах.
Чтобы легко добиться того же эффекта в emacs, вот что я делаю:
1. C-x (
2. M-C-s <a\>
3. C-b
4. C-s >
5. C-b
6. target="_blank"
7. C-x )
8. C-u 10000 C-x e
Вот описание того, что делает каждое нажатие клавиши выше:
1. start remembering keystrokes
2. regex search for <a. Note that the "\>" after the "a" is not HTML. It's emacs regex notation for end-of-word.
3. back up one character - as a side-effect this gets you out of search mode
4. search for the next ">"
5. back up over the ">"
6. enter space as an attribute-delimiter followed by the target="_blank" attribute
7. stop remembering keystrokes
8. replay the remembered keystrokes 10,000 times or until the search fails
Это выглядит сложно, но на самом деле это очень легко набрать. И вы можете использовать этот подход, чтобы делать много вещей, которые vi не может сделать, даже не спускаясь до кода на Лиспе.
Я действительно не вижу причин для переключения. Я давно пользуюсь vi, и мне вполне комфортно с ним; Примерно каждые шесть месяцев я устанавливал emacs, чтобы потом попробовать, а затем быстро переключался обратно. Да, были некоторые вещи, которые я очень предпочитал в vi, но главная причина, по которой я никогда не придерживался этого, заключается в том, что время, потраченное на полное изучение другого редактора, когда я уже знаю чрезвычайно способного, не стоит.
Мне напомнили об этом довольно устаревшем исследовании.
На мой взгляд, SLIME - единственная причина, чтобы перейти на emacs, если вы уже хорошо владеете vi.