Какую конкретную прирост производительности Vim/Emacs предоставляет над текстовыми редакторами графического интерфейса?

Ответ 1

Для Vim:

• Vim лучше интегрируется с другими инструментами (командами оболочки, скриптами, компиляторами, системами управления версиями, ctags и т.д.), чем большинство редакторов. Даже что-то простое, например :.!, чтобы передать вывод команды в буфер, вы не найдете в большинстве графических редакторов.

• Интерфейс с вкладками не так хорош, как "оконный" интерфейс, который дает вам Vim/Emacs. Одновременно вы можете видеть два или несколько файлов. Чем больше вы можете видеть на экране, тем больше вы освобождаете свой ум, чтобы думать о своей проблеме, а не делать умственную учету имен переменных и сигнатур функций.

• Не стоит недооценивать силу регулярных выражений Vim. Существует множество Vim-специфических расширений для соответствия определенному столбцу, знаку, позиции курсора, определенным классам символов (ключевые слова, идентификаторы) и т.д.

• Интегрированные diff и grep (независимые от платформы, поэтому вам не нужно скачивать и изучать новый инструмент каждый раз, когда вы меняете компьютеры).

• Режим визуальных блоков (для редактирования столбцов) - это то, чего не хватает многим редакторам, но я не могу жить без него. Я был шокирован и напугал людей на работе, используя только это, сделав некоторые изменения в нескольких нажатиях клавиш, которые кто-то мог бы потратить десять минут на выполнение вручную.

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

• Система Vim undo/redo является непревзойденной. Напечатайте что-нибудь, отмените, введите что-то еще, и вы можете вернуть первое, что вы набрали, потому что Vim использует дерево отмены, а не стек. Почти в каждой другой программе история первого, что вы набрали, теряется в этом случае.

• Перемещение, копирование, вставка и удаление текста в Vim безумно быстро. Команды простые, одиночные нажатия клавиш и составные. Добавьте все время, когда вы делаете тщательную, трудоемкую подсветку мыши и Ctrl-X, а затем замените их на da( (удалите набор совпадающих парсеров и все в них). Это экономит больше времени, чем вы думаете.

• Маленькие вещи, например * для поиска слова под курсором, или . для повторения команды, или % для отскока между открывающим и закрывающим парами. Путь слишком много из них для перечисления.

• Встроенный язык сценариев и мощное сопоставление клавиш и способность к макросъемке, поэтому редактор можно расширить любыми способами. Тонны скриптов уже написаны и загружаемы.

Если вы посмотрите достаточно внимательно, вы обнаружите, что даже функции, которые есть у других редакторов, Vim часто делает лучше. У всех редакторов есть подсветка синтаксиса, но у Vim есть файл синтаксиса почти для каждого формата файла под солнцем, часто с множеством опций конфигурации, и это грязно-просто, чтобы написать свой собственный. Многие редакторы обрабатывают разные кодировки файлов, но Vim дает вам очень конкретные и надежные способы настройки кодировок файлов и преобразования между ними. Самое первое, что произвело на меня впечатление о Vim, - это то, насколько отлично он обрабатывает варианты отступов и пробелов в Unix/DOS по сравнению с другими редакторами, с которыми у меня были проблемы в то время.

Многие из этих точек одинаково хорошо применимы к Emacs (в разных, но обычно одинаково мощных).

Ответ 2

(vim my poison, я уверен, что emacs предлагает аналогичные выгоды)

Самый большой выигрыш: не нужно прикасаться к мыши.

Для меня самая удобная вещь - прыгнуть вперед (или непосредственно перед ней) конкретную букву или комбинацию букв или отскочить назад с помощью нескольких нажатий клавиш. Прыжки вперед одним и тем же условием дважды или десять раз - это просто вопрос префикса его числом.

Если вам нужно повторить редактирование, вы переходите к этому месту (2-3 нажатия клавиш), а затем нажмите ".". чтобы повторить последнее редактирование. Прыгать вперед (или назад) проще - одно нажатие клавиши - если это одно и то же условие поиска.

В принципе, с небольшим временем выполнения вы можете узнать десять или двадцать сочетаний клавиш, которые означают, что вам не нужно перемещать руку, чтобы захватить мышь. Это дает вам в три или четыре раза больше редактируемых движений/команд, как вы делали бы, если бы вам приходилось хватать мышь.

Через несколько дней вы обнаружите, что каждый раз приходите к мыши (или нажмите <Down> 15 раз), когда вы находитесь в редакторе графического интерфейса.

Ответ 3

Я всегда задавался вопросом, почему мало кто из вас проголодался над Вимом. Смотрите видео пользователя Vim power в действии:

https://www.youtube.com/watch?v=FcpQ7koECgk

Если ваш текущий редактор может делать то, что он делает, нет необходимости переключаться!:)

Кроме того, прочитайте этот http://www.viemu.com/a-why-vi-vim.html

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

Ответ 4

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

Ответ 5

Я полу-компетентен с vi keybindings, но я предпочитаю Emacs в целом. Причина, по которой эти редакторы имеют такие горячие сторонники, состоит в том, что модель редактирования, которую они предоставляют, более мощна, чем более новые системы, поэтому предоставление "vi keybindings" или "emacs keybindings" недостаточно, даже если вы не используете какие-либо функции расширения или настройки для emacs или vi.

Я только расскажу о модели Emacs, потому что я ее лучше понимаю. Общая модель для редактирования текста сегодня включает в себя буфер текста, в который текст можно вставлять, удалять, выбирать и вырезать/копировать/вставлять в системный буфер обмена.

Буферы Emacs, конечно же, могут поддерживать эти операции. Наряду с отслеживанием позиции курсора для каждого окна они видны внутри, они также отслеживают "метки", сделанные в них. Текст между "точкой" (позиция курсора) и "отметкой" называется "областью" и примерно соответствует выбору в основных редакторах.

Разница заключается в том, что Emacs отслеживает последние несколько мест, на которых отмечена метка в кольце меток, и вы можете вернуться к ним нажатием клавиши (или двумя, в зависимости от вашей конфигурации). Я считаю это чрезвычайно полезным, особенно потому, что многие команды Emacs, которые меняют ваше местоположение в буфере, устанавливают метку в вашем прежнем местоположении. Например, когда я редактирую модуль Python и вам нужно добавить оператор импорта в начало файла. Нажатие клавиши для перехода в верхнюю часть буфера (Alt- <) устанавливает метку. Я добавляю оператор import. Я нажимаю Ctrl-u Ctrl-Space, и я возвращаюсь туда, где я начал. Я могу продолжать делать это, чтобы вернуться к предыдущим позициям. (Возможно, мне нужно было выбрать текст при добавлении этого оператора импорта.)

Другая (и более известная) разница Emacs - это кольцо убийства. Большинство нажатий клавиш для удаления текста из буфера сохраняют текст в кольце kill, который затем можно вызвать командой "yank" (Ctrl-y). Существенной особенностью является то, что последующие команды yank извлекают старый убитый текст. Таким образом, вы можете убить несколько разделов текста подряд, а затем восстановить их по порядку. Вы также можете циклически перемещать кольцо уничтожения с помощью Alt-y после yank, удаляя извлеченный текст и вставляя следующую запись в кольцо.

Emacs имел эти функции в 1978 году. Единственная другая важная система, в которой они были приняты, - NeXTStep (и теперь унаследована Cocoa). Другие инструменты предоставляют больше возможностей для конкретных задач, могут быть расширены на языках, проще в использовании, чем Emacs Lisp, и имеют более приятные визуальные интерфейсы... но Emacs остается лучше при редактировании текста. Вот почему, как только вы знаете, как его использовать, так сложно выйти.

Ответ 6

Это не совсем конкретная задача, но для людей, которые даже могут страдать от RSI, тот факт, что ваши руки никогда не покидают клавиатуру в vim, почти бесценен. Я на самом деле оказался левым на моей мыши на работе, потому что он позволил мне переместить мою руку меньше, чтобы дотянуться до мыши (у моей клавиатуры дома нет номера, поэтому я могу держать ее справа).

Еще одно небольшое преимущество заключалось в том, что IIRC, оригинальный vi был разработан для ускорения редактирования файлов по очень медленному удаленному соединению. Конечно, сегодня это происходит не так много, но если у вас медленное соединение, удачи в использовании текстового редактора gui и его отзывчивость.

Ответ 7

Для меня большая производительность -

• Я могу делать почти все с клавиатуры.
• Мощные макросы.
• В моем 20-летнем карьере, использующем 9 ОС, основные привязки клавиш не изменились. Я могу прыгать практически на любую систему и уже знаю свой путь вокруг редактора.
• Довольно часто добавлена ​​какая-либо функция, которую вы, возможно, захотите в текстовом редакторе.

Ответ 8

Одна вещь, которая мне очень нравится в vim, - это команда "повторитель". В основном, нажав . в командном режиме, он повторяет ваше последнее действие. Это всего лишь один пример действительно классных функций, которые "редакторы текстовых редакторов" часто имеют графические интерфейсы.

Ответ 9

"Повышение производительности", которое я получаю для использования легкого клона emacs для крошечных программ, заключается в том, что он запускается, как смазанная молния. Обычно я могу выпустить программу быстрого тестирования на С#, прежде чем Visual Studio завершит загрузку решения "песочницы".

Конечно, я мог бы просто оставить Visual Studio открытым (или другим VS открытым, если я работаю в нем в то время), но потом он поменялся бы, если бы я оставил его без дела некоторое время и т.д.

Для любого существенного размера - или если я не знаю API, который я использую довольно хорошо - IDE - это путь вперед, IMO.

Ответ 10

По моему опыту, основной прирост производительности, который vim и emacs (я сам человек vim, но emacs, безусловно, похожий):

• У вас могут быть те функции, которые предоставляют современные IDE (например, цикл однократного редактирования и сборки, встроенная документация и вкладка и многое другое), но вам это не нужно. Повышение производительности? Вы видите только столько, сколько хотите. По моему опыту, IDE не делали людей более продуктивными, также потому, что они отображали слишком много информации (все виды браузеров). Этот "лишний бит энергии, когда вам это нужно, но не раньше" - это довольно выигрыш в производительности IMHO.

• Редакторы очень популярны среди программистов, что означает наличие огромных хранилищ скриптов, книг и доступных групп.

• По моему опыту (я могу говорить только для vim здесь), средний пользователь vim - довольно хороший инженер-программист. Я не знаю, почему это (или, может быть, мне просто повезло), но, возможно, люди, которые преодолели барьер привыкания к "старому" инструменту, например emacs или vim, имели правильное посвящение (и общение с такими людьми). Возможно, это косвенное влияние этих редакторов, но общение с другими людьми vim (или emacs) напр. IRC оказался весьма интересным, так как те же люди также были очень заинтересованы во всех вопросах разработки программного обеспечения (или информатики). Кажется, что эти редакторы привлекают определенную личность.: -)

Ответ 11

Я использую gvim для окон, так что технически это текстовый редактор графического интерфейса, но это vim..

Для повышения производительности я нахожу:

• Мне никогда не придется использовать мышь, поэтому я быстрее.
• поиск, замена, копирование/вставка и т.д. все быстрее с помощью кнопок vim и движений мыши (как только кривая обучения была преодолена).
• Как упоминалось в предыдущих комментариях, RSI значительно сокращается. Мои запястья поблагодарили меня, так как я переехал в Вим.
• он легкий и быстрый

Ответ 12

Знаете, для vi я думаю, что это сводится к тому, чтобы иметь режим вставки и команды. Хотя это может показаться возвратом к тому времени, когда вы не могли зависеть от курсора или специальных клавиш, что это действительно означает, что многие мощные команды манипуляции и текстового maniuplation - это минимальное количество нажатий клавиш. Продуктивное кодирование не связано с массовым текстовым вводом (по умолчанию в "современных" редакторах), но всплеск объемного текста, сопровождаемый значительными небольшими изменениями и даже большими периодами просмотра.

Это стало для меня лично для использования vi в сети с большим латентным кампусом. Вы можете легко получить 10 или 15 символов перед ответом. С vi я мог бы с уверенностью предсказать, где эти команды оставят меня и смогут работать на почти нормальной скорости. Этот скрученный опыт - это постоянная выгода при нормальных условиях - менее визуальная умственная сила, предназначенная для постоянной графической обратной связи.

Обычные и # словарные ускорители поиска отлично подходят для перелистания кода. И% для соответствующих скобок чрезвычайно полезно. Несомненно, вряд ли кажется, что это намного больше, чем ctl-], но добавляется половина нажатий клавиш.

Лично я использую winvi, который добавляет пару больших вещей, которые, я уверен, vim тоже. Быстрый переход в шестнадцатеричный режим искажает много проблем "что, черт возьми, происходит". И полностью гибкая обработка концов строк - это находка, которая стала ожидаемой функцией для текстового редактора. Наконец, он может открыть любой файл независимо от содержимого. Это составляет навык элитного взлома первого порядка.

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

Ответ 13

Я использую Vim довольно часто. Однако он меняет UltraEdit. Поскольку в списке было много положительных результатов, я думаю, что я пойду против зерна и перечислил некоторые неприятности с Vim.

• Слабая обработка FTP. Я "сортирую" множество сайтов и не могу легко просматривать и редактировать файлы на удаленном FTP-сервере, это большой недостаток для меня. NWRead недостаточно хорош.
• Странность консоли, унаследованная от общих проблем терминала, которые, похоже, угрожают Linux. Я обычно использую PuTTY для подключения к моей Linux-панели (работает Ubuntu), и по какой-то причине клавиши со стрелками сопоставляются с A/B/C/D в режиме вставки (и все проблемы с поддержкой цвета). В gVim ctrl-tab можно легко сопоставить с "bn", но не в консольном режиме, таких проблем много.
• Параметры поиска/замены очень слабы, интерфейс мудрый. Чтобы набрать все это в одну строку, просто недостаточно. Я чувствую гораздо более сложный диалог, так как UltraEdit дает мне гораздо больше энергии, даже если поддержка регулярных выражений может быть намного слабее.
• Слишком сильная зависимость от раскладок клавиатуры в США. Множество ключей, которые используются для первичных функций, таких как `, не печатаются на моей датской раскладке клавиатуры (и расположены arkwardly, то же самое с $и многими другими). Делает некоторые неудобные функции.

Ответ 14

Я бы сказал, что одним из больших преимуществ является расширяемость редактора vim. Если я хочу что-то работать с CVS, я могу использовать плагин CVSMenu и добавить его в свой редактор, чтобы получить эту функциональность.

То же самое с подсветкой синтаксиса, поведением с определенными файлами и т.д. Всевозможные вещи можно настроить в vim.

Не уверен, что вы можете легко это сделать в редакторах типов графического интерфейса.

Ответ 15

Удаленный рабочий стол быстро показывает только собственное приложение Windows. Мы пытались использовать Eclipse для разработки под Unix. И знаешь, что? Это было даже невозможно.

Вторая причина заключается в том, что мы могли бы расширить наши Vims и Emacs, чтобы сделать все специфические для проекта задачи из просмотра БД особым образом, чтобы выделить и автоматически завершить наш собственный метаязык.

Ответ 16

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

Также auto increment/decment дает ему возможности генерации данных без написания программ для него.

Ответ 17

Я был неуправляемым пользователем Emacs годами. Но никогда в нее не попало. Затем я начал изучать Clojure (мой первый Lisp) и обнаружил ParEdit.

И это взорвало мой разум.

(см. здесь несколько примеров: https://www.youtube.com/watch?v=D6h5dFyyUX0)

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

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

(В общем Emacs так же быстро, как и должно быть. В отличие от Eclipse, который похож на ввод в клей.)

Следующее, что я обнаружил, это Yasnippet (http://emacswiki.org/emacs/Yasnippet). Еще раз, я раньше не использовал ничего подобного. Не просто макрос для добавления шаблона, а динамическая, судоходная форма.

Конечным удовольствием является осознание того, что, если я хочу расширить эту штуку самостоятельно, чтобы иметь больше этих высокоуровневых инструментов для повышения производительности, у меня есть сила Lisp для работы.

Ответ 18

(Мой фон несколько лет с Visual Studio и другими IDE, затем 15 лет Vim, а последние 6 месяцев - с Emacs.)

Долговечность - Vim/Emacs являются FOSS, и были на протяжении десятилетий. Их использование не собирается снижение, а также их особенности, которые могут сломаться/исчезнуть/сильно измениться, так что вы можете рассчитывать на создание всей своей основной панели инструментов для карьеры мастерство только одного редактора.

Удаленный/вездесущий доступ в терминалах. Хотя оба имеют прекрасный системы для редактирования удаленных файлов, вы также можете установить их на любая система, в которую вы вошли.

Разработка, основанная на REPL. Оба имеют режимы "SLIME" в различных формах которые интегрируют любой тип REPL, с которым вы работаете. Например, я никогда не сталкивались с итеративным развитием, столь же мощным, как это предусмотрено CIDER.

Linting. Какой бы язык у вас ни был, вероятно, есть linting инструменты, встроенные в компилятор или внешний инструмент. Они легко интегрируются с Emacs/Vim, показывая ваши слайды для кодирования в режиме реального времени.

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

Встроенные справочные системы - автономная документация многих языки и их API являются общими для поиска встроенных в эти редакторы, и доступно аналогичным образом для обширного и комплексные справочные системы, которые они используют. Автозаполнение было добавлено для большинства распространенных языков. Кроме того, существует множество помощь при обсуждении практически любой темы справки.

Навигация - теги, paredit-likes, mark, windowing, tabs, vim-rails ' прыжки, и еще много встроенных модулей.

Менеджеры пакетов/репозитории - у Emacs есть несколько (elpa, melpa, мармелад) и Vim тоже хороши (пучок, патоген, и т.д.). Я не знаю каких-либо сообществ вокруг IDE, которые предлагают что-либо сопоставимых с ними. Я вижу более 5000 пакетов с package-list-packages.

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

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

Бесконечно настраиваемый - Elisp - очень мощный язык для расширение/изменение Emacs. VimL эквивалентен Vim. Есть книги написанных на обоих. Подчеркните цветные темы и поведение в восторге!

Ответ 19

Одно из преимуществ, что все консольные редакторы имеют над редакторами графического интерфейса, заключается в том, что их можно запускать в терминальном мультиплексоре, таком как screen или tmux. Почему это хорошо?

• Быстрее переключаться с одной консоли терминального мультиплексора на другой, чем переключаться с одной консоли GUI на другую с помощью мыши или даже с помощью alt-tab. Это связано с тем, что консоль можно назвать и переключиться, набрав несколько символов имени.
• Если ваши сеансы редактора находятся в терминальных мультиплексорных консолях, вы можете получить к ним доступ с любого компьютера. Если мне нужно сделать какую-то работу из дома, я могу сделать ssh в своем ящике, подключить уже запущенный терминальный мультиплексор к моей сессии ssh и быть там, где я остановился, когда я оставил работу.

Ответ 20

Поскольку vim/emacs часто используются программистами и как пользователь С# с 2003 года, из этого смещения справедливо делать это иначе несправедливое сравнение (другим может быть VS С++ с Visual Assist X vs С++ в vim/emacs):

Для С# и Visual Studio:

• Я просто подсчитал количество нажатий клавиш для этой строки:

      public List<string> Names = new List<string>();
  //  3      3    3      1111111111111            211   =3+3+3+8+5+2+1+1 = 26 keys strokes + 3 uses of Shift while typing the line above in VS C# 2013 vs 47 key strokes for non-IntelliSense IDE's
  //                              (IntelliSense offers the List<string> because that what you're likely after here but you can type something else if you want)
  // https://channel9.msdn.com/Blogs/Seth-Juarez/Anders-Hejlsberg-on-Modern-Compiler-Construction explains on how this is impl. for C#. In C++ I've heard of 3rd party VS plugin that improves or replaces the VS C++ auto-complete
  

• Я прочитал о функции emacs для прыжка в коде. Я не думаю, что у него есть такая особенность. У этого есть подобная особенность хотя. Здесь недостаток VS. Там много мелких функций, но со временем они перестают работать. Последнее, что я проверил, функция прыжка не сработала, но это было пару лет назад. VS представил новую функцию графического перехода, которую я использовал вместо этого. Это требует мыши или прикосновения.

• Здесь, где emacs/vi побеждает. Если вам нужно много прыгать в коде, функции VS для этого либо не существуют, либо недостаточно проверены.

Проблема с навигацией по GUI на основе мыши заключается в том, что

a) так же, как сидеть в очень статическом положении, может быть, плохо, если так, мышки склонны заставлять ваши пальцы находиться в статическом положении. Моя боль в запястье ушла с переходом на трекбол. Я сначала попробовал вертикальную мышь, но ничего не сделал для этой проблемы.

b) Моя идеальная клавиатура имела бы 2 ряда функциональных клавиш, no numpad, поэтому я мог бы разместить трекбол ближе, делая прыжок более терпимым.

В конечном счете, однако, если вы хотите прыгать между несколькими конкретными местами, он очищает "кольцо метки" более эффективно. У VS есть что-то в этом роде... последнее, что я использовал, он просто не работал надежно...

c) и, вероятно, тонна небольших функций, которые ломаются с каждым выпуском, поэтому это минус VS.

Решение этой проблемы с "закрытым источником": напишите весь VS на С#, а затем разрешите модификацию/редактирование скомпилированного кода (во время выполнения, сохранение изменений в качестве патча, которое будет необязательно загружено при следующем запуске) без освобождения источника. Это можно сделать, если декомпилятор выводит код так же, как и при входе. 180 градусов от того, как работают собственные компиляторы. Затем двоичный код становится исходным кодом и исполняемым файлом вместо этого беспорядка файлов .cs и .exe и т.д. Существуют сторонние инструменты, которые могут почти сделать это уже, поэтому "modding" С# exe довольно тривиален, но я предлагаю принять это логический вывод: включить даже комментарии в .exe и .dll. Файлы по-прежнему будут крошечными по сравнению с скомпилированными приложениями C/С++. Оптимизация? Вы также можете включить предварительно оптимизированный код. Когда модем модерирует exe во время работы приложения, немодулированный "AST" и сопутствующий оптимизированный двоичный файл снова подключаются. Такая же идея, как и в компиляторе С#, но принимается дальше. Следующий шаг: напишите всю ОС на этом языке, так что даже когда Windows будет закрыт исходным кодом, его можно будет тривиально модифицировать, поскольку исходный код поставляется с каждым двоичным кодом. Нет настройки среды, компиляции, связывания. Просто измените ОС во время работы. Близкая аналогия: если вы написали веб-браузер в Common Lisp, вы можете отредактировать веб-браузер, не останавливая его и создавая веб-страницы на том же языке, что и браузер.