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 문을 추가하는 동안 일부 텍스트를 선택해야 할 수도 있습니다.)

다른 (그리고 더 잘 알려진) Emacs의 차이점은 킬 링입니다. 버퍼에서 텍스트를 제거하기위한 대부분의 키 입력은 텍스트를 킬 링에 저장합니다. 그러면 "yank"명령 (Ctrl-y)으로 다시 불러올 수 있습니다. 필수 기능은 후속 yank 명령이 이전에 죽인 텍스트를 검색한다는 것입니다. 따라서 연속 된 텍스트의 여러 섹션을 죽인 다음 순서대로 검색 할 수 있습니다. 또한 yank 후 Alt-y로 킬 링을 순환하여 검색된 텍스트를 제거하고 링에 다음 항목을 삽입 할 수 있습니다.

Emacs는 1978 년에 이러한 기능을 가지고있었습니다. 어느 정도까지 적용 할 수있는 유일한 다른 주요 시스템은 NeXTStep입니다 (현재 Cocoa에 상 속됨). 다른 도구는 특정 작업에 대해 더 많은 기능을 제공하고 Emacs Lisp보다 사용하기 쉬운 언어로 확장 할 수 있으며 더 멋진 시각적 인터페이스를 제공합니다. 그렇기 때문에 일단 사용 방법을 알고 나면 종료하기가 너무 어렵습니다.

이 정확히 특정 작업이 아니라 사람들을 위해, 심지어 사람 수 있습니다 RSI 고통, 당신의 손은 정력에 키보드를 떠나지 않을는 사실은 거의 한심하다. 실제로 직장에서 마우스를 왼손잡이로 만들었습니다. 마우스를 잡기 위해 손을 덜 움직일 수 있기 때문입니다 (집에있는 키보드에는 숫자 패드가 없어서 오른쪽에 둘 수 있습니다).

또 하나의 작은 이점은 IIRC, 원래 vi가 매우 느린 원격 연결을 통해 파일 편집 속도를 높이도록 설계되었다는 것입니다. 오늘날 거의 발생하지는 않지만 연결 속도가 느리다면 GUI 텍스트 편집기를 실행하고 응답 할 수 있기를 바랍니다.

나에게 큰 생산성은

• 키보드로 거의 모든 것을 할 수 있습니다.
• 강력한 매크로.
• 9 개의 OS를 사용하는 20 년 간직 원에서 기본 키보드 바인딩은 변경되지 않았습니다. 나는 거의 모든 시스템에 뛰어들 수 있으며 이미 편집기에 대해 알고 있습니다.
• 텍스트 편집기에서 원할 수있는 거의 모든 기능이 이미 추가되었습니다.

내가 vim에 대해 정말 좋아 하는 한 가지는 "repeater"명령입니다. 기본적으로 .명령 모드에서 를 누르면 마지막 작업이 반복됩니다. 이것은 "프로그래머 텍스트 편집기"가 가지고있는 정말 멋진 기능 중 하나이지만 GUI에는없는 경우가 많습니다.

내 경험상, vim과 emacs (저는 vim 사람이지만 emacs는 확실히 유사합니다)가 제공하는 주요 생산성 향상은 다음과 같습니다.

• 당신은 할 수 있습니다 현대의 IDE가 (하나의 키를 편집 - 빌드 - 실행 사이클과 인라인 문서 및 탭 완성과 이것 저것 같은)를 제공하는 기능을 가지고 있지만, 당신은하지 않습니다 에 있습니다 . 생산성 향상? 보고 싶은만큼만 볼 수 있습니다. 내 경험상 IDE는 너무 많은 정보 (모든 종류의 브라우저) 를 보여 주었기 때문에 사람들의 생산성을 높이 지 못했습니다 . 이 "추가적인 힘, 필요할 때-그러나 조만간"IMHO의 생산성 향상을 가져옵니다.

• 편집기는 프로그래머들 사이에서 매우 인기가 있으며, 이는 스크립트, 서적 및 사용자 그룹의 방대한 저장소가 있음을 의미합니다.

• 제 경험상 (여기서는 vim에 대해서만 말할 수 있습니다) 일반적인 vim 사용자는 상당히 훌륭한 소프트웨어 엔지니어입니다. 왜 그런지 모르겠지만 (혹은 운이 좋을 수도 있지만) emacs 또는 vim과 같은 '오래된'도구에 익숙해지는 장벽을 가진 사람들은 올바른 헌신을 가지고있을 수 있습니다. ). 아마도이 편집자들의 간접적 인 영향 일 수도 있지만, IRC에서 다른 vim (또는 emacs) 사람들과 어울리는 것은 매우 흥미로 웠습니다. 같은 사람들이 모든 종류의 소프트웨어 엔지니어링 (또는 컴퓨터 과학) 문제에 상당히 관심이 있었기 때문입니다. . 이 편집자들은 어떤 종류의 개성을 끌어들이는 것 같습니다. :-)

작은 프로그램에 경량 emacs 클론을 사용하여 얻은 "생산성 향상"은 기름칠 번개처럼 시작된다는 것입니다. Visual Studio가 "샌드 박스"솔루션로드를 완료하기 전에 일반적으로 C #으로 빠른 테스트 프로그램을 실행할 수 있습니다.

물론 Visual Studio를 열어 둘 수 있지만 (또는 당시 작업중인 경우 다른 VS를 열어 둘 수 있습니다 ) 잠시 유휴 상태로두면 교체됩니다.

중요한 크기의 모든 경우 또는 내가 사용하는 API를 잘 모르는 경우 IDE가 앞으로 나아갈 길입니다. IMO.

저는 Windows 용 gvim을 사용하므로 기술적으로는 GUI 텍스트 편집기이지만 vim입니다 ..

생산성 향상을 위해 다음을 찾았습니다.

1. 마우스를 사용할 필요가 없으므로 더 빠릅니다.
2. 검색, 바꾸기, 복사 / 붙여 넣기 등은 vim 키 바인딩 대 마우스 움직임으로 모두 더 빠릅니다 (학습 곡선이 초과 된 후).
3. 이전 의견에서 언급했듯이 RSI가 크게 감소합니다. 내가 vim으로 옮긴 이후로 내 손목은 나에게 감사했다.
4. 가볍고 빠릅니다.

vi의 경우 삽입 및 명령 모드를 사용하는 것이 중요하다고 생각합니다. 커서 나 특수 키에 의존 할 수 없었던 시절로 되돌아가는 것처럼 보일 수 있지만 실제로 의미하는 것은 많은 강력한 동작 및 텍스트 조작 명령이 최소한의 키 입력이라는 것입니다. 생산적인 코딩은 대량 텍스트 입력 ( "현대"편집기의 기본값)에 관한 것이 아니라 대량 텍스트의 폭주에 이어 상당한 작은 조정과 더 긴 검색 기간이 뒤 따릅니다.

이것은 지연 시간이 긴 캠퍼스 네트워크를 통해 vi를 개인적으로 사용하는 데 앞장 섰습니다. 응답보다 10 자 또는 15 자 앞서 쉽게 얻을 수 있습니다. vi를 사용하면 이러한 명령이 나를 떠나는 위치를 편안하게 예측하고 거의 정상 속도로 작업 할 수 있습니다. 이 꼬인 전문 지식은 정상적인 조건에서 지속적인 혜택입니다.

commonplace * 및 # 단어 검색 액셀러레이터는 코드를 넘기는 데 적합합니다. 그리고 일치하는 괄호에 대한 %는 매우 유용합니다. 물론, ctl-]에 비해 거의 비슷해 보이지 않지만 키 입력의 절반이 더해집니다.

개인적으로 저는 vim이 가지고 있다고 확신하는 몇 가지 큰 것들을 추가하는 winvi를 사용합니다. 16 진수 모드로 빠르게 전환하면 "대체 무슨 일이 일어나고 있는지"텍스트 문제가 많이 해결됩니다. 그리고 줄 끝을 완전히 유연하게 처리하는 것은 텍스트 편집기의 예상 기능이 된 신의 선물입니다. 마지막으로 내용에 관계없이 모든 파일을 열 수 있습니다. 이것은 1 차 엘리트 해킹 기술에 해당합니다.

Unix에서는 프로그램 출력을 빠르게 캡처하거나 외부 명령을 통해 파일 섹션을 필터링 할 수도 있습니다. 매우 강력하지만 활용도가 낮은 기능이라고 생각합니다.

저는 Vim을 자주 사용합니다. 그래도 UltraEdit 를 대체하지는 않습니다 . 많은 긍정이 나열되었으므로 나는 결정에 반대하고 Vim에 대한 몇 가지 성가심을 나열 할 것입니다.

• FTP 처리가 약합니다. 많은 사이트를 "정렬"하고 원격 FTP 서버에서 파일을 쉽게 찾아보고 편집 할 수 없다는 것은 저에게 큰 결점입니다. NWRead는 충분 하지 않습니다 .
• Linux를 괴롭히는 것처럼 보이는 일반적인 터미널 문제에서 상속 된 콘솔 기이함. 나는 보통 PuTTY 를 사용하여 내 Linux 상자 (Ubuntu 실행)에 연결하고 어떤 이유로 화살표 키가 삽입 모드 (및 전체 색상 지원 문제)에서 A / B / C / D에 매핑됩니다. gVim에서 ctrl-tab은 "bn"에 쉽게 매핑 할 수 있지만 콘솔 모드에서는 매핑 할 수 없으므로 이러한 문제가 많습니다.
• 검색 / 바꾸기 옵션은 인터페이스 측면에서 매우 약합니다. 전체 내용을 한 줄에 입력하는 것만으로는 충분하지 않습니다. 실제 정규 표현식 지원이 훨씬 약할지라도 UltraEdit가 결국 훨씬 더 많은 힘을 제공한다고 말하는 훨씬 더 정교한 대화가 느껴집니다.
• 미국 키보드 레이아웃에 대한 의존도가 너무 높습니다. `와 같은 주요 기능에 사용되는 많은 키가 내 덴마크어 키보드 레이아웃에 인쇄되지 않습니다 (그리고 arkwardly 위치, $ 및 기타 여러 항목과 동일). 일부 기능을 사용하는 것이 매우 어색합니다.

원격 데스크톱은 기본 Windows 응용 프로그램 만 빠르게 표시합니다. 우리는 이클립스를 사용하여 유닉스에서 개발하려고했습니다. 그리고 그거 알아? 그것은 불가능했습니다.

두 번째 이유는 Vims와 Emacs를 확장하여 DB 브라우징의 모든 프로젝트 특정 작업을 특별한 방식으로 수행하여 자체 메타 언어를 강조하고 자동 완성 할 수 있기 때문입니다.

가장 큰 장점 중 하나는 vim 편집기의 확장 성입니다. CVS와 함께 작동하기를 원하는 경우 CVSMenu 플러그인을 가져 와서 편집기에 추가하여 해당 기능을 얻을 수 있습니다.

구문 강조 표시, 특정 파일의 동작 등과 동일합니다. 모든 종류의 항목을 vim에서 조정할 수 있습니다.

GUI 유형 편집기에서 쉽게 할 수 있는지 확실하지 않습니다.

VIM의 기록 및 재생은 매우 훌륭하며 GUI 기반 도구에서는 찾을 수 없을 것입니다.

또한 자동 증가 / 감소 는 프로그램을 작성하지 않고도 데이터 생성 기능을 제공합니다.

나는 수년 동안 끔찍한 Emacs 사용자였습니다. 그러나 실제로는 그것을 얻지 못했습니다. 그런 다음 Clojure (내 첫 Lisp)를 배우기 시작했고 ParEdit를 발견했습니다.

그리고 그것은 내 마음을 사로 잡았습니다.

(몇 가지 예를 보려면 여기를 참조하십시오 : https://www.youtube.com/watch?v=D6h5dFyyUX0 )

Lisp + ParEdit는 제가 지금까지 경험 한 것 중 가장 놀라운 편집 경험입니다. 다른 것은 아무것도 없습니다. Lisp는 더 이상 쓰기에 어색한 언어가 아니기 때문에 짜증나는 어리석은 괄호의 균형을 맞추는 것에 대해 걱정해야합니다. ParEdit를 사용하면 일관된 Lisp 구조가 작업하는 데 큰 보너스가됩니다. 동일한 트리 변환 (슬러 핑, 바핑, 분할 및 결합)이 제어 구조 및 데이터 구조에서 똑같이 모든 곳에서 작동합니다. 그리고 ParEdit는 내가 어리석은 실수를하는 것을 막아줍니다. 구문 오류를 만드는 것은 거의 불가능합니다.

이클립스와 달리 이것은 항상 백그라운드에서 실행되는 힘든 실시간 검사가 아니므로 프로세서가 소모됩니다. 그것은 비용이 들지 않습니다 ... ParEdit는 내가 요청할 때 단순히 올바른 구조적 변경을 수행합니다.

(일반적으로 Emacs는 필요한만큼 빠릅니다. Eclipse와는 달리 접착제로 입력하는 것과 같습니다.)

다음으로 발견 한 것은 Yasnippet ( http://emacswiki.org/emacs/Yasnippet )이었습니다. 다시 한 번, 나는 전에 이와 같은 것을 사용하지 않았습니다. 단순히 상용구를 추가하는 매크로가 아니라 동적이고 탐색 가능한 양식입니다.

마지막 기쁨은 내가이 일을 직접 확장하고 이러한 높은 수준의 생산성 도구를 더 많이 갖고 싶다면 Lisp 자체의 힘을 가지고 작업 할 수 있다는 사실을 깨닫는 것입니다.

(내 배경은 Visual Studio 및 기타 IDE에서 몇 년, Vim에서 15 년, Emacs에서 가장 최근 6 개월입니다.)

수명 — Vim / Emacs는 FOSS입니다. 이며 수십 년 동안 사용되어 왔습니다. 그들의 사용은 줄어들지 않을 것이고 그들의 기능은 많이 깨지거나 사라지거나 바뀌지 않을 것입니다. 따라서 당신은 단지 한 명의 편집자의 숙달을 중심으로 전체 커리어 도구 상자 핵심을 구축하는 데 의존 할 수 있습니다.

터미널에서 원격 / 유비쿼터스 액세스 — 둘 다 원격 파일을 편집 할 수있는 훌륭한 시스템이 있지만 로그인 한 모든 시스템에 설치할 수도 있습니다.

REPL 기반 개발 — 둘 다 작업중인 REPL 유형을 통합하는 다양한 형태의 "SLIME"모드가 있습니다. 예를 들어 CIDER에서 제공하는 것만 큼 강력한 반복 개발을 경험 한 적이 없습니다 .

Linting — 사용중인 언어에 따라 약간의 보풀이 있을 수 있습니다. 컴파일러에 내장되어 있든 외부 도구에 내장 되든간에 도구 . 이들은 Emacs / Vim과 원활하게 통합되어 거의 실시간으로 코딩 실수를 보여줍니다.

니모닉 명령의 문법 — 둘 다 배우는 데 시간이 좀 걸리지 만이 편집기는 몇 번의 키 입력과 키 조합으로 수천 개의 명령에 액세스하고 기억할 수있는 영리한 시스템을 갖추고 있습니다. 이렇게하면 마우스를 사용할 필요가 전혀 없어집니다.

기본 제공 도움말 시스템 — 여러 언어 및 해당 API에 대한 오프라인 문서는 이러한 편집기에 기본 제공되는 것이 일반적이며 이들이 제공하는 방대하고 포괄적 인 도움말 시스템에 유사한 간단한 방법으로 액세스 할 수 있습니다. 대부분의 일반적인 언어에 자동 완성 기능이 추가되었습니다. 또한 거의 모든 도움말 항목에 대한 다양한 토론 도움말이 있습니다.

탐색 — 태그, 유사 유사 항목, 표시, 창, 탭, vim-rails의 점프 및 더 많은 내장 기능.

패키지 관리자 / 저장소 — Emacs에는 몇 가지 (elpa, melpa, marmalade)가 있고 Vim도 좋습니다 (vundle, 병원체 등 ). 나는 이것에 필적하는 것을 제공하는 IDE 주변의 커뮤니티를 모른다. 나는 package-list-packages.

단순한 편집을 넘어서 -Emacs는 뉴스 읽기, 웹 탐색, 이메일 관리, 스프레드 시트 편집, 프레젠테이션 작성 및 모든 것을 구성 할 수있는 기능을 제공합니다.

디버거, 브라우저 동기화, 컴파일, 셸, 테스트 실행 등 다른 모든 것을 통합했습니다 .

무제한 사용자 정의 가능 — Elisp는 Emacs를 확장 / 수정하기위한 매우 강력한 언어입니다. VimL는 Vim과 동일합니다. 둘 다 쓴 책이 있습니다. 색상 테마와 동작을 원하는대로 조정하세요!

모든 콘솔 기반 편집기가 GUI 편집기에 비해 갖는 한 가지 장점은 screen 또는 tmux 와 같은 터미널 멀티플렉서에서 실행할 수 있다는 것 입니다. 이것이 좋은 이유는 무엇입니까?

• 마우스를 사용하거나 심지어 alt-tab을 사용하여 한 GUI 콘솔에서 다른 GUI 콘솔로 전환하는 것보다 한 터미널 멀티플렉서 콘솔에서 다른 콘솔로 전환하는 것이 더 빠릅니다. 콘솔 이름을 몇 자만 입력하여 이름을 지정하고 전환 할 수 있기 때문입니다.
• 편집기 세션이 터미널 멀티플렉서의 콘솔에있는 경우 모든 컴퓨터에서 액세스 할 수 있습니다. 집에서 작업을해야하는 경우에는 ssh를 내 상자에 넣고 이미 실행중인 터미널 멀티플렉서를 ssh 세션에 연결 한 다음 퇴근 할 때 중단 한 위치에 바로있을 수 있습니다.

vim / emacs는 2003 년부터 프로그래머와 C # 사용자가 자주 사용하기 때문에이 편향 관점에서 불공평 한 비교를 수행하는 것이 타당합니다 (다른 방법은 vim / emacs의 Visual Assist X 대 C ++가있는 VS C ++ 일 수 있습니다).

C # 및 Visual Studio의 경우 :

1. 이 줄에 대한 키 입력의 양을 계산했습니다.

       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. 코드에서 점프하기위한 emacs 기능에 대해 읽었습니다. 나는 그것이 정확히 그런 기능을 가지고 있다고 생각하지 않습니다. 그래도 비슷한 기능이 있습니다. 여기 VS의 단점이 있습니다. 많은 작은 기능이 있지만 시간이 지남에 따라 작동이 중지됩니다. 마지막으로 점프 기능이 작동하지 않는지 확인했지만 몇 년 전이었습니다. VS는 내가 대신 사용했던 새로운 그래픽 점프 기능을 도입했습니다. 마우스 나 터치가 필요합니다.

3. 여기서 emacs / vi가 승리합니다. 코드를 많이 살펴 봐야한다면 이에 대한 VS 기능이 존재하지 않거나 충분히 테스트되지 않았습니다.

마우스 기반 GUI 탐색의 문제점은

a) 매우 정적 인 자세로 앉아있는 것과 마찬가지로, 만약 그렇다면 마우스는 손가락도 정적 인 자세로 만드는 경향이 있습니다. 내 손목 통증은 트랙볼로 변경하면서 사라졌습니다. 나는 처음에 수직 마우스를 시도했지만 문제를 해결하지 못했습니다.

b) 이상적인 키보드에는 숫자 패드가없는 2 줄의 기능 키가 있으므로 트랙볼을 더 가까이 배치 할 수 있으므로 점프 거리를 더 견딜 수 있습니다.

그러나 궁극적으로 몇 개의 특정 위치 사이를 이동하려면 "마크 링"이 더 효과적이라는 것이 분명합니다. VS는 그 라인을 따라 뭔가를 가지고 있습니다 ... 마지막으로 사용했지만 안정적으로 작동하지 않았습니다 ...

c) 각 릴리스마다 중단되는 작은 기능이 많으므로 이것이 VS의 단점입니다.

이 "닫힌 소스"문제에 대한 해결책 : 전체 VS를 C #으로 작성한 다음 소스를 해제하지 않고 컴파일 된 코드를 수정 / 편집 할 수 있습니다 (런타임시, 다음 시작시 선택적으로로드되는 패치로 변경 사항 저장). 이것은 디 컴파일러가 들어갈 때와 같이 코드를 출력하도록함으로써 수행 할 수 있습니다. 네이티브 컴파일러의 작동 방식과 180도 차이가 있습니다. 바이너리는 .cs 파일과 .exe 파일 등의이 엉망진창 대신 소스 코드와 실행 파일이됩니다. 이미이 작업을 거의 수행 할 수있는 타사 도구가 있으므로 C # exe를 "수정"하는 것은 다소 사소한 작업이지만이 작업을 수행 할 것을 제안합니다. 논리적 결론 : .exe 및 .dll에 주석도 포함하십시오. 컴파일 된 C / C ++ 앱에 비해 파일은 여전히 ​​작습니다. 최적화? 사전 최적화 된 코드를 포함 할 수도 있습니다. 앱이 실행되는 동안 modder가 exe를 수정하면 수정되지 않은 "AST"와 함께 제공되는 최적화 된 바이너리가 다시 연결됩니다. C # 컴파일러에서와 동일한 아이디어이지만 더 나아갑니다. 다음 단계 :이 언어로 전체 OS를 작성하여 Windows가 닫힌 소스 일 때에도 소스 코드가 모든 바이너리와 함께 제공되므로 간단하게 수정할 수 있습니다. 환경 설정, 컴파일, 링크가 없습니다. 실행되는 동안 OS를 수정하십시오. 유사한 비유 : Common Lisp로 웹 브라우저를 작성한 경우 웹 브라우저를 중지하지 않고 편집하고 브라우저와 동일한 언어로 웹 페이지를 작성할 수 있습니다. 소스 코드가 모든 바이너리와 함께 제공되므로 간단하게 수정할 수 있습니다. 환경 설정, 컴파일, 링크가 없습니다. 실행되는 동안 OS를 수정하십시오. 유사한 비유 : Common Lisp로 웹 브라우저를 작성한 경우 웹 브라우저를 중지하지 않고 편집하고 브라우저와 동일한 언어로 웹 페이지를 작성할 수 있습니다. 소스 코드가 모든 바이너리와 함께 제공되므로 간단하게 수정할 수 있습니다. 환경 설정, 컴파일, 링크가 없습니다. 실행되는 동안 OS를 수정하십시오. 유사한 비유 : Common Lisp로 웹 브라우저를 작성한 경우 웹 브라우저를 중지하지 않고 편집하고 브라우저와 동일한 언어로 웹 페이지를 작성할 수 있습니다.