Vim / Emacs가 GUI 텍스트 편집기를 통해 제공하는 특정 생산성 향상은 무엇입니까?

Vim / Emacs가 GUI 텍스트 편집기를 통해 제공하는 특정 생산성 향상은 무엇입니까?

---

이것은 트롤이나 화염 미끼 또는 그와 비슷한 것을 의미하지 않습니다. 저는 지금 몇 달 동안 (제 터미널에서 설정 파일을 편집하기 위해) 선택한 콘솔 편집기로 Vim 을 사용해 왔지만 웹 애플리케이션을 작성하는 일상적인 일상 작업에는 견딜 수 없을 것 같습니다. , GUI 텍스트 편집기로 수행합니다 (중요하지 않음).

내 GUI 텍스트 편집기가 내 작업에 필요한 모든 것을 할 수 있다고 생각합니다. 둘 다에 대한 자동 완성 기록으로 괜찮은 검색 / 대체 기능이 있습니다. 구문 강조, 줄 번호, 탭 인터페이스, 손쉬운 복사 및 붙여 넣기 등이 있습니다. 현재 편집기에서 누락 된 유일한 것은 정규식 일치이지만 정규식 검색 / 교체를 수행 할 GUI 텍스트 편집기가 많이 있습니다.

내가 방금 말한 것을 감안할 때 Vim (또는 Emacs)이 모든 컴퓨터에 설치되어 있다는 사실을 제외하고 GUI 텍스트 편집기에 비해 어떤 생산성 이점이 있습니다. Vim / Emacs에서 더 좋고 / 빠르거나 기존 GUI 텍스트 편집기로는 불가능한 특정 작업을 원합니다.

---

Vim의 경우 :

• Vim은 대부분의 편집기보다 다른 도구 (셸 명령, 스크립트, 컴파일러, 버전 제어 시스템, ctag 등)와 더 잘 통합됩니다. :.!명령의 출력을 버퍼로 파이프하는 것과 같은 간단한 것조차도 대부분의 GUI 편집기에서 찾을 수없는 것입니다.

• 탭 인터페이스는 Vim / Emacs가 제공하는 "윈도우"인터페이스만큼 좋지 않습니다. 두 개 이상의 파일을 동시에 나란히 볼 수 있습니다. 화면에서 더 많이 볼수록 변수 이름과 함수 시그니처를 정신적으로 부기하는 대신 문제에 대해 더 많이 생각할 수 있습니다.

• Vim 정규 표현식의 힘을 과소 평가하지 마십시오. 특정 열, 마크, 커서 위치, 특정 문자 클래스 (키워드, 식별자) 등과 일치하는 Vim 관련 확장이 많이 있습니다.

• 통합 diff및 grep(플랫폼 독립적이므로 컴퓨터를 변경할 때마다 새로운 도구를 다운로드하고 배울 필요가 없습니다).

• 비주얼 블록 모드 (열 편집 용)는 많은 편집자들에게 부족하지만, 내가 없이는 살 수 없습니다. 나는 이것을 사용하는 직장에서 사람들을 놀라게했고, 몇 번의 키 누름으로 누군가가 수동으로 10 분을 보냈을 것 같은 편집을했습니다.

• 다중 복사 / 붙여 넣기 레지스터. 하나만 있으면 클립 보드가 막히는 것을 방지하기 위해 이상한 왜곡을 겪게됩니다. 그럴 필요가 없습니다.

• Vim의 실행 취소 / 다시 실행 시스템은 타의 추종을 불허합니다. 무언가를 입력하고, 실행 취소하고, 다른 것을 입력해도 Vim은 스택이 아닌 실행 취소 트리를 사용하기 때문에 입력 한 첫 번째 항목을 다시 가져올 수 있습니다. 거의 모든 다른 프로그램에서는이 상황에서 처음 입력 한 내용의 기록이 손실됩니다.

• Vim에서는 텍스트 이동, 복사, 붙여 넣기 및 삭제가 엄청나게 빠릅니다. 명령은 간단하고 단일 키 누르기이며 구성 가능합니다. 조심스럽고 힘든 마우스 강조 표시와 Ctrl-X를 수행하는 모든 시간을 더한 다음 모두를 a로 da(바꿉니다 (일치하는 괄호 세트와 그 안에있는 모든 항목 삭제). 생각보다 더 많은 시간을 절약합니다.

• *커서 아래에있는 단어를 검색하거나 ., 명령을 반복하거나 %, 여는 괄호와 닫는 괄호 사이를 튕기는 것과 같은 사소한 것 입니다. 나열하기에는 너무 많습니다.

• 기본 제공 스크립팅 언어와 강력한 키 매핑 및 매크로 기능을 통해 필요한 방식으로 편집기를 확장 할 수 있습니다. 이미 작성되고 다운로드 가능한 수많은 스크립트.

자세히 살펴보면 다른 편집자들도 가지고있는 기능조차 Vim이 더 잘하는 경우가 많다는 것을 알게 될 것입니다. 모든 편집기에는 구문 강조 기능이 있지만 Vim에는 거의 모든 파일 형식에 대한 구문 파일이 있으며 종종 많은 구성 옵션이 있으며 직접 작성하는 것이 간단합니다. 많은 편집기가 서로 다른 파일 인코딩을 처리하지만 Vim은 파일 인코딩을 설정하고 변환하는 매우 구체적이고 확실한 방법을 제공합니다. Vim에 대해 저에게 가장 깊은 인상을 준 것은 그 당시 문제가 있었던 다른 편집기에 비해 탭 / 스페이스 들여 쓰기 옵션과 Unix / DOS 줄 바꿈을 얼마나 완벽하게 처리하는지입니다.

이 포인트 중 많은 부분이 Emacs에 똑같이 잘 적용됩니다 (다르지만 일반적으로 똑같이 강력한 방식).

---

(vim은 나의 독이다. 나는 emacs가 비슷한 이득을 제공한다고 확신한다)

가장 큰 이점은 마우스를 만질 필요가 없다는 것입니다.

나에게 가장 편리한 것은 특정 문자 또는 문자 조합으로 앞으로 (또는 바로 앞) 이동하거나 몇 번의 키 입력으로 뒤로 이동하는 것입니다. 같은 조건으로 두 번 또는 열 번 앞으로 점프하는 것은 단순히 숫자를 접두사로 붙이는 문제입니다.

편집을 반복해야하는 경우 해당 위치로 이동 (2 ~ 3 번 키 입력) 한 다음 "."를 누릅니다. 마지막 편집을 반복합니다. 검색 조건이 같으면 앞으로 (또는 뒤로) 점프하는 것이 더 쉽습니다 (키 입력 한 번).

기본적으로 짧은 시간 내에 10 개 또는 20 개의 키보드 단축키를 배울 수 있습니다. 즉, 마우스를 잡기 위해 계속 손을 움직일 필요가 없습니다. 이렇게하면 마우스를 계속 잡아야하는 경우보다 3 ~ 4 배 많은 편집 동작 / 명령을 얻을 수 있습니다.

며칠이 지나면 <Down>GUI 편집기를 사용할 때 마우스에 손을 뻗어 야 할 때 (또는 15 번 누를 때마다) 심술 궂게 느껴질 것 입니다.

---

나는 항상 왜 Vim에 대한 가가가 거의 없는지 궁금했습니다. Vim 파워 유저의 실제 동영상보기 :

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

현재 편집자가 자신이하는 일을 할 수 있다면 전환 할 필요가 없습니다! :)

또한 http://www.viemu.com/a-why-vi-vim.html을 읽으십시오 .

비디오를보고 그 기사를 읽은 후 VIM을 배우기 시작할 수밖에 없었습니다. VIM으로 전환 한 지 거의 1 년이 지났는데 다른 것을 사용하는 것은 상상할 수 없습니다.

---

전용 텍스트 편집기의 진정한 힘 중 하나는 매크로 편집이라고 생각합니다. 반복은 많은 프로그래머에게 고통스럽고 적절한 매크로를 작성하는 것은 경계선이 재미있을 수 있습니다. 키보드를 통해 모든 작업을 수행하지 않는 경우 매크로를 만들려면 이미 사용중인 명령을 사용하는 대신 추가 명령 집합이 필요합니다.

---

저는 vi 키 바인딩에 대해 약간의 능력이 있지만 전반적으로 Emacs를 선호합니다. 이러한 편집기가 열렬한지지를받는 ​​이유는 제공하는 편집 모델이 최신 시스템보다 강력하기 때문입니다. 따라서 확장 기능을 사용하지 않더라도 "vi keybindings"또는 "emacs keybindings"를 제공하는 것만으로는 충분하지 않습니다. 또는 emacs 또는 vi에 대한 사용자 정의.

나는 내가 그것을 가장 잘 이해하기 때문에 Emacs의 모델에 대해서만 이야기 할 것입니다. 오늘날 텍스트 편집을위한 일반적인 모델은 텍스트를 삽입, 삭제, 선택하고 시스템 클립 보드에 잘라 내기 / 복사 / 붙여 넣기 할 수있는 텍스트 버퍼를 포함합니다.

물론 Emacs 버퍼는 이러한 작업을 지원할 수 있습니다. 표시되는 각 창에 대한 커서 위치 추적과 함께 창에 만들어진 "마크"도 추적합니다. "포인트"(커서 위치)와 "마크"사이의 텍스트를 "지역"이라고하며 주류 편집자의 선택과 대략 일치합니다.

차이점은 Emacs는 마크 링에서 마크가 설정된 마지막 여러 위치를 추적하고 키 입력 (구성에 따라 두 개)으로 해당 위치로 돌아갈 수 있다는 것입니다. 특히 버퍼에서 위치를 변경하는 많은 Emacs 명령이 이전 위치에 표시를 설정하기 때문에이 기능이 매우 유용합니다. 예를 들어 Python 모듈을 편집 할 때 파일 맨 위에 import 문을 추가해야합니다. 버퍼의 맨 위로 이동하기위한 키 입력 (Alt- <)은 표시를 설정합니다. import 문을 추가합니다. Ctrl-u Ctrl-Space를 누르면 내가 시작한 곳으로 돌아 왔습니다. 이 작업을 계속해서 이전 위치로 돌아갈 수도 있습니다. (해당 import 문을 추가하는 동안 텍스트를 선택해야 할 수도 있습니다.)

The other (and more well-known) Emacs difference is the kill ring. Most of the keystrokes for removing text from the buffer save text to the kill ring, which can then be recalled with the "yank" command (Ctrl-y). The essential feature is that subsequent yank commands retrieve older killed text. So you can kill several sections of text in a row, then retrieve them in order. You can also cycle through the kill ring with Alt-y after a yank, removing the retrieved text and inserting the next entry in the ring.

Emacs had these features in 1978. The only other major system to adopt them to any extent is NeXTStep (and now inherited by Cocoa). Other tools provide more features for specific tasks, can be extended in languages way easier to use than Emacs Lisp, and have nicer visual interfaces... but Emacs remains better at text editing. Which is why, once you know how to use it, it's so hard to quit.

---

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.

---

For me the big productivity things are

• I can do pretty much everything from the keyboard.
• Powerful macros.
• In my 20 year carreer using 9 OSes the basic keyboard bindings haven't changed. I can hop on pretty much any system and already know my way around the editor.
• Pretty much any feature you might ever want in a text editor has already been added.

---

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.

---

In my experience, the main productivity gains which vim and emacs (I'm a vim person myself, but emacs is surely similiar) provide are:

• You can have those features which modern IDEs provide (like one-keypress edit-build-run cycles and inline documentation and tab completion and whatnot) but you don't have to. The productivity gain? You see only as much as you want to see. In my experience, IDEs didn't make people more productive, also because they showed too much information (all kinds of browsers). This "extra bit of power, when you need it - but no sooner" is quite a productivity gain IMHO.

• The editors are very popular among programmers, which means that there are huge repositories of scripts, books and usergroups available.

• In my experience (I can only speak for vim here) the average vim user is a fairly good software engineer. I don't know why that is (or maybe I'm just lucky), but maybe people who took the barrier of getting accustomed to an 'old' tool like emacs or vim have the right dedication (and contact to other people like that). Maybe it's an indirect effect of these editors, but hanging out with other vim (or emacs) people on e.g. IRC turned out to be quite interesting, since the same people were also quite interested in all kinds of software engineering (or computer science) issues. These editors seem to attract a certain kind of personality. :-)

---

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.

---

I use gvim for windows, so technically it's a GUI text editor, but it is vim..

For productivity enhancements, I find:

1. I never have to use the mouse, therefore I'm faster.
2. search, replace, copy/paste etc are all faster with vim keybindings vs mouse movements (once the learning curve was surmounted)
3. As mentioned in the previous comments, RSI's are reduced significantly. My wrists have thanked me since I moved to vim.
4. it's lightweight and fast

---

You know, for vi I think it comes down to having an insert and command mode. While it may seem a throwback to a time when you could not depend on cursor or special keys what it really means is that many powerful motion and text maniuplation commands are a minimal number of keystrokes. Productive coding is not about bulk text entry (the default in "modern" editors) but a burst of bulk text followed by considerable small tweaks and even larger periods of browsing.

This came to the fore for me personally using vi over a high latency campus network. You could easily get 10 or 15 characters ahead of the response. With vi I could comfortably predict where those commands would leave me and be able to work at near normal speeds. This twisted expertise is a continued benefit under normal conditions -- less visual brainpower dedicated to constant graphical feed back.

The commonplace * and # word search accelerators are great for flipping through code. And % for matching parenthesis is extremely useful. Sure, hardly seems like much compared to ctl-] but half the keystrokes adds up.

Personally, I use winvi which adds a couple big things that I'm sure vim has as well. A quick jump into hex mode cracks a lot of "what the hell is going on" text problems. And the completely flexible handling of line endings is a godsend that has become an expected feature for a text editor. Finally, it can open any file no matter what the contents. This amounts to an elite hacking skill of the first order.

Under Unix you can quickly capture program output or even filter sections of your file through external commands. An extremely powerful yet I think underutilized function.

---

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.

---

Remote Desktop shows quickly only native Windows application. We've tried to use Eclipse to develop under unix. And you know what? It wasn't even possible.

Second reason is that we could extend our Vims and Emacs to do all the project specific tasks from DB browsing in a special way to highlight and auto complete our owns meta language.

---

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.

---

Record and Replay in VIM is unbeatably awesome, which you are very unlikely to find in GUI based tools.

Also auto increment/decrement gives it data generation capabilities without writing programs for it.

---

I'd been a desultory Emacs user for years. But never really got into it. Then I started learning Clojure (my first Lisp) and discovered ParEdit.

And that blew my mind.

(See here for some examples : https://www.youtube.com/watch?v=D6h5dFyyUX0 )

Lisp + ParEdit is the most amazing editing experience I've ever had. Nothing else comes close. Lisp is no longer an awkward language to write, forcing me to worry about balancing lots of irritating silly parentheses. With ParEdit, the consistent Lisp structure becomes a huge bonus to work with, as the same tree-transformations - slurping, barfing, splitting and joining - work everywhere, in control structures and data-structures alike. And ParEdit prevents me from making stupid mistakes. It becomes almost impossible to make syntax errors.

And unlike Eclipse, this isn't some laborious real-time checking that's always running in the background, burning up my processor. It costs nothing ... ParEdit simply does the correct structural change when I ask for it.

(In general Emacs is as fast as it needs to be. Unlike Eclipse which is like typing in glue.)

The next thing I discovered was Yasnippet ( http://emacswiki.org/emacs/Yasnippet ). Once again, I'd not used anything like this before. Not simply a macro to add boilerplate, but a dynamic, navigable form.

The final pleasure is the realization that if I want to extend this thing myself, to have more of these high-level productivity tools, I have the power of Lisp itself to work with.

---

(My background is a few years with Visual Studio and other IDEs, then 15 years of Vim, and the most recent 6 months with Emacs.)

Longevity — Vim/Emacs are FOSS, and have have been around for decades. Their usage is not going to decline, nor are their features going to break/disappear/change a lot, so you can rely on building your whole career toolbox core around mastery of just one editor.

Remote/ubiquitous access in terminals — Although both have fine systems for editing remote files, you can also have them installed on any system you ever log into.

REPL-driven development — Both have "SLIME" modes in various forms that integrate whatever type of REPL you're working with. E.g., I've never encountered iterative development as powerful as that provided by CIDER.

Linting — Whatever language you're using probably has some linting tools, whether built into the compiler or an external tool. These integrate seamlessly with Emacs/Vim, showing your coding slip-ups in near real-time.

Grammar of mnemonic commands — Although both take some time to learn, these editors feature famously clever systems for accessing — and even remembering — thousands of commands with a few keystrokes and key combos. These can fully eliminate any need for using a mouse if you're so inclined.

Built-in help systems — The offline documentation of many languages and their APIs is common to find built into these editors, and is accessible in similarly simple ways to the vast and comprehensive help systems they feature. Auto-completion has been added for most common languages. Additionally, there is a wealth of discussion help on virtually any help topic.

Navigation — tags, paredit-likes, marks, windowing, tabs, vim-rails' jumping, and many more built-ins.

Package managers/repositories — Emacs has a few (elpa, melpa, marmalade) and Vim's are good, too (vundle, pathogen, etc). I don't know of any communities around IDEs that offer anything comparable to these. I see more than 5,000 packages with package-list-packages.

Beyond just editing — Emacs goes farthest here with the ability to read news, browse the web, manage email, edit spreadsheets, create presentations, and organize anything.

Integrated everything else — debuggers, browser syncing, compiling, shells, test running.

Infinitely customizable — Elisp is a very powerful language for extending/modifying Emacs. VimL is Vim's equivalent. There are books written on both. Tweak color themes and behaviors to your delight!

---

One advantage that all console-based editor has over GUI editors is that they can be run in a terminal multiplexor such as screen or tmux. Why is this good?

• It is faster to switch from one terminal multiplexor console to another than it is to switch from one GUI console to another using the mouse, or even using alt-tab. This is because consoles can be named, and switched to by typing a few characters of the name.
• If your editor sessions are in a terminal multiplexor's consoles, you can access them from any machine. If I need to do some work from home, I can ssh into my box, attach the already running terminal multiplexor to my ssh session, and be right where I left off when I left work.

---

As vim/emacs are often used by programmers and as C# user since 2003, from this bias pov it's fair to do this otherwise unfair comparison (Another could be VS C++ with Visual Assist X vs C++ in vim/emacs):

For C# and Visual Studio:

1. I just counted the amount of keystrokes for this line:

       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's 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
   

2. I read about emacs feature for jumping in the code. I don't think it has feature exactly like that. It has a similar feature though. Here's the downside of VS. There's lot of little features but over time they stop working. Last I checked the jump feature didn't work but that was couple years ago. VS introduced a new graphical jump feature that I've been using instead. It requires mouse or touch.

3. Here's where emacs/vi win. If you have to jump around a lot in the code, VS features for this either don't exist or haven't been tested enough.

The problem with mouse based GUI navigation is that

a) just like sitting in very static position maybe bad, if so, mouses tend to make your fingers be in static position also. My wrist pain went away with change to trackball. I first tried vertical mouse but it didn't do anything for the problem.

b) My ideal keyboard would have 2 rows of function keys, no numpad, so I could place trackball closer, makes the jump distance more bearable.

Ultimately however, if you want to jump between few specific places, it's clear the "mark ring" is more effective. VS has something along those lines ... last I used it, it just didn't work reliably...

c) and there's likely a ton of small features that break with each release so this is the downside of VS.

Solution to this "closed source" problem: Write the entire VS in C# and then allow modding/editing the compiled code (at runtime, saving changes as patch that gets optionally loaded on next start) without releasing the source. This can be done by having the decompiler output the code as it was when going in. 180 degrees from how native compilers work. The binary then becomes the source code and the executable instead this mess of .cs files and .exe files etc. There exists 3rd party tools that can almost do this already, so "modding" C# exe's is rather trivial but I propose taking this to the logical conclusion: include even comments in the .exe and .dll. The files are still going to be tiny compared to compiled C/C++ apps. Optimization? You could also include pre-optimized code. When the modder mods the exe while the app is running, the non-modded "AST" and the accompanying optimized binary is plugged back in. Same idea as in the C# compiler but taken further. Next step: Write entire OS in this language, so that even when Windows is closed source, it can be trivially modded as the source code comes with every binary. No setting up environments, compiling, linking. Just modify the OS while it is running. Close analogy: If you wrote web browser in Common Lisp, you could edit the web browser without stopping it and build web pages in the same language as the browser.

참고URL : https://stackoverflow.com/questions/1088387/what-specific-productivity-gains-do-vim-emacs-provide-over-gui-text-editors