Какие определенные повышения эффективности Vim/Emacs обеспечивают по текстовым редакторам GUI?

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

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

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

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

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

I use Vim quite often. It doesn't replace UltraEdit for me though. Since a lot of positives have been listed, I guess I'll go against the grain, and list some annoyances with Vim.

• Weak FTP handling. I "sort" a lot of sites, and not being able to easily browse and edit files on a remote FTP server is a big deficiency for me. NWRead is not good enough.
• Console weirdness inherited from the general terminal issues that seems to plague Linux. I usually use PuTTY to connect to my Linux box (running Ubuntu), and for some reason, the arrow-keys maps to A/B/C/D in insert mode (and the whole color support issues). In gVim, ctrl-tab can be mapped to "bn" easy, but not in console mode, such issues abound.
• The search/replace options are very weak, interface wise. Having to type the whole thing into a single line, is just not good enough. I feel the much more elaborate dialogue in say UltraEdit gives me much more power in the end, even if the actual regular expression support may be much weaker.
• Too strong a reliance on US keyboard layouts. A lot of keys that are used for primary functions, such as `, are non-printing on my Danish keyboard-layout (and located arkwardly, same with $, and many others). Makes it quite awkward to use some functions.

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

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

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

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

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

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

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

Также прочтите это http://www.viemu.com/a-why-vi-vim.html

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

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

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

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

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

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

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

One thing that I really like about vim is the "repeater" command. Basically, by pressing . in command mode, it repeats your last action. This is just one example of really cool features that "programmer text editors" have that often GUIs don't.

Для меня важнее всего производительность

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

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

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

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

I'd say one of the big advantages is the extensibility of the vim editor. If I want something to work with CVS I can take the CVSMenu plugin and add it to my editor to get that functionality.

Same with syntax highlighting, behaviour with specific files, etc. All sorts of things can be tailored in vim.

Not so sure if you can do that as easily in GUI type editors.

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

I think one of the real powers of a dedicated text editor is macro editing. Repetition is painful for a lot of programmers, and writing proper macros can be borderline entertaining. If you're not doing everything through the keyboard, creating macros will require an extra set of commands rather than making use of the ones you already are using.

This is not exactly a specific task, but for people who even might be suffering from RSI, the fact that your hands never leave the keyboard in vim is almost priceless. I actually ended up going lefty on my mouse at work because it let me move my hand less to reach for the mouse (my keyboard at home doesn't have a number pad, so I can keep it on the right).

One other small benefit was that, IIRC, the original vi was designed to speed up editing files over a terribly slow remote connection. Granted that doesn't happen nearly as much today, but if you do have a slow connection, good luck running a gui text editor and having it be responsive.

(vim's my poison; I'm sure emacs offers similar gains)

The biggest gain: not needing to touch the mouse.

For me, the handiest thing is to jump forward to (or just before) a specific letter or combination of letters, or jump back, with a couple of keystrokes. Jumping forward by the same condition twice, or ten times, is simply a matter of prefixing it with a number.

If you've to repeat an edit, you jump forward to that place (2-3 keystrokes), then hit "." to repeat the last edit. Jumping forward (or backward) is easier - one keystroke - if it's the same search condition.

Basically, with a small lead-time, you can learn ten or twenty keyboard shortcuts that mean you don't have to keep shifting your hand to grab the mouse. That gives you three or four times as many editing movements/commands as you'd do if you had to keep grabbing the mouse.

After a few days, you'll find yourself getting grumpy every time you have to reach for the mouse (or hit 15 times), when you're in a GUI editor.

The "productivity gain" I get for using a lightweight emacs clone for tiny programs is that it starts up like greased lightning. I can usually bang out a quick test program in C# before Visual Studio would have finished loading a "sandbox" solution.

Of course, I could just leave Visual Studio open (or another VS open if I'm working in it at the time) but then it would get swapped out if I left it idle for a while, etc.

For anything of any significant size - or if I don't know the API I'm using pretty well - an IDE is the way forward, IMO.