Emacs 사용법을 배우는 데 시간을 투자 할 가치가 있습니까?
바로 앞에 : 종교 전쟁을 시작하고 싶지 않습니다 .
나는 내가 기억할 수있는 한 오랫동안 vi 를 사용해 왔고 , 몇 번 Emacs 를 집어 들려고 시도했지만 너무 길을 잃어 버려 금방 포기했습니다. 그러나 많은 사람들이 Emacs가 매우 강력하다고 생각합니다. 프로그래밍 가능성은 다소 전설적입니다. 저는 주로 Solaris + Java 개발을하고 있으며 간단한 질문을하고 싶습니다. Emacs를 다루는 데 시간을 투자하면 생산성이 향상 될까요? Vim을 통해 제공하는 기능이 합리적인 시간 내에 생산성 향상에 도움이 될까요?
반복 : "내 편집자가 당신보다 낫다"는 대답을 원하지 않습니다. 시간을 투자 할 가치가 있는지 여부에 대해 예 또는 아니오로 대답하고 싶습니다. 내 생산성이 정말 향상 될까요?
나는 vi보다 emacs를 선호하지만, 둘 다 편안합니다.
vi보다 더 강력하게 만드는 emacs에서 할 수있는 일들이 있지만, 그들 모두가 심지어 프로그래밍과 관련된 것은 아닙니다. (vi 내에서 이메일을 보내거나 뉴스를 읽을 수 있나요? 아니요,하지만 누가 신경 쓰나요?) lisp에 익숙하다면 (아니요) 삶을 만들기위한 추가 기능과 모드 등을 작성할 수있을 것입니다. 더 쉽지만 구문 색상과 중괄호 일치 및 눈 사탕 일 가능성이 높습니다.
이제 그만 떠들지 않겠습니다. 당신의 것입니다 생산성 이맥스를 사용하여 증가? 아니.
업데이트 : 아래 내 의견을 참조하십시오. 나는이 게시 때문에, 나는 한 이맥스를 사용하는 것은 VI를 사용하는 것보다 좀 더 생산적으로 만든 것을 방법으로 건너.
[면책 조항 : 개인적 으로 저는 Vim을 선호합니다. 면책 조항 : 계속 읽어보세요.]
Vim은 작은 부분에서 탁월합니다. 동작과 동작을 별개의 개념으로 만들고 복잡한 반복을위한 기능을 제공함으로써 짧은 키 입력만으로 매우 강력한 편집 작업을 수행 할 수 있습니다. Emacs에서 스크립팅을해야하는 일반적인 편집 과정에서 Vim에서 쉽게 작업을 수행 할 수 있습니다. 또한, 사용하는 전력의 대부분은 광대가 그렇게하더라도 상자에서 나오는 .vimrc기회는 당신이 생산적으로 작업 할 수 있으며, 사용자 정의한 내용을 어떤 빔 설치.
Emacs는 전반적으로 탁월합니다. 모든 UI 개념을 Elisp의 기본 구조와 개념에 직접 매핑함으로써 특정 종류의 파일 또는 상황에 대한 기능을 전역 적으로 도입하는 것이 매우 쉬워 져 Emacs가 텍스트 기반과 훨씬 더 구조화됩니다. 프로그래밍 가능한 형태의 Excel. 이것은 개인의 필요와 선호도에 맞게 환경을 사용자 지정하는 데 많은 시간을 할애 할 것이라고 가정합니다. 물론, Emacs는 모든 일과 당신이하고 싶은 모든 일에 대해 하나의 환경에 쉽게 머물 수 있도록 최선을 다합니다.
궁극적으로 어느 쪽도 우월하지 않습니다. 그들은 서로 다른 스타일을 제공하며, 당신의 성향에 따라 하나 또는 다른 것이 당신의 개인적인 필요와 더 나은 사고 방식에 적합 할 것입니다. 물론 둘 다 (및 더 많은 편집자)를 아는 것이 항상 도움이됩니다. 그러나 당신은 이런 식으로 더 생산적이지 않을 것입니다.
vi는 부엌 칼입니다.
vim은 정말 멋지고 날카로 우며 균형 잡힌 요리 사용 칼입니다.
Emacs는 라이트 세이버입니다.
대부분의 경우 제 직업은 야채를 썰어 야합니다. 때로는 로봇 군대 전체를 맡아야합니다.
저는 20 년 동안 Emacs를 사용해 왔습니다. Firefox의 텍스트 상자에 텍스트를 넣거나 꺼낼 수있는 "It 's All Text" 라는 위젯을 사용하여 지금 Emacs에 입력 하고 있습니다. 나는 Emacs에서 정말 빨리 갈 수 있습니다. 나는 그것 없이는 훨씬 덜 생산적입니다.
이것은 매우 논쟁의 여지가 있지만, Emacs를 배우면 프로그래밍에 대해 놀라운 양을 배울 수 있다고 생각합니다.
코딩 방법에 따라 생산성이 향상 될 수 있습니다. 배경으로는 오랫동안 vim 사용자이지만 약 2 년 전에 emacs를 배웠고 이제는 서로 바꿔서 사용할 수 있습니다.
실제로 emacs를 배우게 된 이유는 한 번에 많은 파일을 열고 파일간에 쉽게 전환 할 수있는 유용한 기능이었습니다. 많은 수업을 추가하고 건 드리는 기능을 도입하는 중이었습니다. (이것은 C ++이므로 일반적으로 클래스 당 두 개의 파일이있었습니다.) 여전히 인터페이스를 강화하고 있었기 때문에 일반적으로 다른 파일을 변경해야한다는 것을 깨달을 때 한 파일을 업데이트하는 도중에있었습니다.
gvim을 사용하면 각 파일에 대해 새 창을 여는 것이 가장 쉬웠으며 다루기 어려워졌습니다. 그러나 Emacs를 사용하면 같은 창에서 새 파일을 여는 것이 간단했습니다 (Ctrl-x, Ctrl-f). Emacs가 파일을 열면 열린 버퍼 (Ctrl-x, Ctrl-b) 사이를 앞뒤로 쉽게 전환 할 수 있습니다.
한 단계 더 나아가 단일 emacs 세션이 여러 창을 열 수 있으므로 창을 수직으로 분할하는 것 외에도 파일 작업을 중단하지 않고 파일 옆에있는 다른 파일을 열도록 결정할 수있어 효과적으로 나란히 작업 할 수 있습니다. 각 창을 기본 80 자 너비로 유지하면서 측면.
여전히 vim에서 더 쉬운 것 (예 : 블록 선택 모드, 간단한 매크로 기록, diff 모드)과 Emacs에서 더 쉬운 것 (라인 정렬, 파일 / 버퍼 관리, 창 / 화면 관리)이 있습니다. 따라서 나는 내가 예상하는 편집 작업에 따라 두 가지를 번갈아 가며 (때로는 둘 다 동시에 사용하는 경우도 있음) 발견합니다.
여전히 확실하지 않은 경우 시도해 보는 것이 좋습니다. Emacs 자습서를 실행 한 다음 도움에 크게 의존하여 아침 또는 하루 동안 코드를 작성하는 데 사용하십시오. 여전히 표시되는 내용이 마음에 들지 않으면 vim을 사용하세요. 편집자가 테이블에 가져 오는 내용에 관계없이 도구에 대한 친숙 함과 지식은 생산성에 가장 중요한 요소입니다.
나는 거룩한 전쟁을 원하지 않지만 매우 주관적인 질문에 예 / 아니오로 대답하십시오.
예, 강력한 기능으로 인해 생산성이 향상 될 수 있습니다.
아니요, emacs에서 사용되는 패턴과 은유가 당신의 두뇌와 일치하지 않을 수 있기 때문에 생산성이 증가하지 않을 것입니다.
귀하의 질문에 대한 짧은 대답은 "예"입니다. 자세한 내용은 아래에서 확인하세요.
저는 1980 년부터 1991 년까지 거의 독점적으로 vi를 사용했습니다. vi를 사용하지 않은 유일한 시간은 vi를 포함하기에는 너무 작은 Unix의 최소 설치를 처리 할 때였 기 때문에 ed로 돌아 가야했습니다. 원래 vi가 위에 구축 된 편집 기능의 최소한의 하위 집합.
1985 년경부터 제가 일했던 다른 프로그래머들은 끊임없이 emacs의 찬사를 부르고있었습니다. 그러나 나는 그것을 배우려고 할 때마다 멀리 가지 않을 것입니다. 나는 emacs turorial (Ch t)을 거치면서 한 시간을 보내고 그 끝에 텍스트를 삽입하고 수정하고 화면을 이동하는 방법을 알 수있었습니다. 그 시간에 emacs로 배운 것보다 vi로 훨씬 더 많은 일을 할 수있어서 전환 할 수 없었습니다. 3 개월 후 나는 또 다른 시간을 보낼 시간을 찾았고 결국 같은 자료를 읽게되었습니다. Emacs에는 대문자 "L"이있는 학습 곡선이 있습니다. 다른 사람들이 emacs를 사용하는 계약을 맺을 때까지는 한 번에 한 시간 이상을 배워야한다고 결정했습니다. 튜토리얼과 포함 된 문서를 통해 작업하는 것 외에는 하루를 조금 넘게 보낸 후, 마침내 vi로는 할 수 없었던 emacs로 작업을 할 수있는 지점에 도달했습니다. 그때부터 나는 돌아가고 싶지 않았습니다. 잠자면서도 vi 명령을 입력 할 수 있지만 emacs로 훨씬 더 많은 일을 할 수 있습니다.
내가 vim이 아니라 emacs와 vi를 비교하고 있다는 것을 이해하십시오. 저는 vim이 vi에 추가 한 확장 기능을 배운 적이 없으며, 대부분이 emacs에서 복사 한 기능 일 가능성이 높습니다. 그렇다면 이미 vim에 능숙하다면 emacs가 많은 이점을 제공하지 못할 수도 있습니다.
내가 emacs에서 항상 의존하는 것들은 다음과 같습니다.
emacs를 사용하면 모든 것이 텍스트로 처리됩니다. 이것은 거의 동일한 명령으로 모든 버퍼의 데이터를 조작 할 수 있음을 의미합니다. 그리고 버퍼가 일부 표준 명령을 사용할 수없는 모드에있는 경우 기본 모드에서 실행중인 다른 버퍼에 텍스트를 복사하고 거기에서 표준 명령을 사용할 수 있습니다.
Emacs는 문자 셀 터미널에 표시 할 수있는 다중 "창"환경을 제공합니다. 비트 맵 그래픽과 실제 창 이전에 emacs는 ascii 문자와 커서 위치를 사용하여 창과 같은 동작을 시뮬레이션하도록 작성되었습니다. 아마 "그건 고대 역사 잖아. 왜 오늘 그걸 신경 써야하지?" 나는 여전히 그 기능을 매일 사용합니다. SSH 액세스를 허용하는 웹 호스팅 회사를 사용하고 있습니다. 따라서 인터넷을 통해 Linux 호스트에 로그인하고 셸 명령을 실행할 수 있습니다. 이 기능은 매우 강력하지만 emacs를 사용하여 터미널 에뮬레이터를 "창"으로 나누고, 여러 "창"에서 쉘을 실행하고, 다른 창에서 파일을 편집하고, 여전히 다른 "에서 디렉토리를보고 편집 할 수있는 것이 훨씬 더 강력합니다. windows ".
사실, 이전 단락에서 "window"라고 말했을 때 나는 정말로 "버퍼"를 의미했습니다. Emacs의 창 문자 셀 에뮬레이션은 화면 영역을 분할하는 방법입니다. emacs 버퍼는 현재 표시되거나 표시되지 않을 수있는 콘텐츠 (파일, bash 쉘, 디렉토리, 파일과 관련되지 않은 임의의 텍스트 등)와 관련됩니다. 버퍼에있는 내용을 보려면 창을 선택하고보고 싶은 버퍼를 지정합니다. 따라서 화면에 표시 할 공간보다 더 많은 작업을 수행 할 수 있습니다. 창을 아이콘 화 / 아이콘 화 해제 할 때 최신 비트 맵 그래픽 GUI에서 수행하는 작업과 거의 유사합니다.
나는 이미 emacs 버퍼 내에서 쉘을 실행할 수 있다는 사실을 암시했습니다. 원하는만큼 쉘을 실행하는 버퍼를 가질 수 있습니다. 셸 버퍼와 텍스트 파일 사이에서 텍스트를 복사하여 붙여 넣거나 텍스트를 복사하거나 두 개의 다른 텍스트를 비교하는 데 사용하는 것과 똑같은 키 입력 시퀀스를 사용하여 셸 버퍼와 텍스트 파일 사이의 텍스트 일부를 비교할 수 있습니다. 텍스트 파일. 실제로 이것은 파일과 관련된 쉘 버퍼 및 버퍼뿐만 아니라 대부분의 버퍼 유형에 적용됩니다.
emacs의 명령을 사용하여 파일을 열지 만 실제로 선택한 것이 디렉토리 인 경우 버퍼는 dired (디렉토리 편집기) 모드로 실행됩니다. 이 모드에서는 한 번의 키 입력으로 커서가 현재 가리키는 파일 또는 하위 디렉토리가 무엇이든 열 수 있습니다. dired 모드의 버퍼는 Mac 또는 Windows 탐색기의 Finder와 유사한 문자 셀 터미널 지향 아날로그 파일 관리자입니다.
내가 거의 끊임없이 사용하는 emacs 기능 중 하나는 "비교 창"입니다. 이클립스에 내장 된 것과 같은 명령 줄 "diff"또는 GUI 비교 도구보다 이것을 매우 선호합니다. Diff 또는 Eclipse는 전체 파일을 비교하고 어떤 줄이 다른지 보여줍니다. 하지만 매우 비슷해 보이는 두 개의 다른 선이 있으면 어떻게 될까요? 다음을 고려하세요:
이 선과 다른 선의 차이점은 무엇입니까?
이 선과 다른 선의 차이점은 무엇입니까?
차이를 발견하는 데 얼마나 걸립니까? (힌트 : ASCII와 유니 코드 아포스트로피는 거의 비슷합니다.)
다른 행만 표시하는 diff 및 Eclipse와 달리 emacs의 "compare-windows"기능은 대화 형입니다. 창 내용이 동일한 지점에 나란히있는 두 창 각각에 커서를 놓습니다. "compare-windows"를 실행하면 각 창의 커서가 다른 첫 번째 문자로 이동합니다. 창 중 하나의 커서를 다른 창과 동일한 지점으로 재배치하고 "compare-windows"를 다시 실행하여 다음 차이점을 찾습니다. 이렇게하면 파일의 하위 부분을 쉽게 비교할 수 있습니다.
내가 정기적으로 "비교 창"을 사용하는 또 다른 것은 체크섬을 비교하는 것입니다. 많은 소프트웨어 프로젝트는 tarball의 MD5 해시를 포함하는 페이지에 응용 프로그램의 tarball을 배포합니다. 따라서 배포 페이지의 MD5 해시를 다운로드 한 파일에서 계산 된 MD5 해시와 어떻게 비교합니까? Emacs는 이것을 사소하게 만듭니다.
먼저 웹 페이지의 MD5 해시를 새 emacs 버퍼로 복사합니다. 그런 다음 .tar.gz 파일을 다운로드 한 후 다음을 실행하십시오.
md5sum 다운로드 됨 file.tar.gz
쉘 버퍼에서. 이 두 버퍼가 나란히있는 emacs 창에 표시되면 체크섬의 시작 부분에있는 각 창에 커서를 놓고 "compare-windows"를 실행합니다. 같으면 각 창의 커서가 각 체크섬의 끝에 위치합니다.
이전 포인트에서, 나는 라인에서 "compare-windows"를 실행하는 예를 제시했습니다.
이 선과 다른 선의 차이점은 무엇입니까?
이 선과 다른 선의 차이점은 무엇입니까?
"compare-windows"는 각 줄의 아포스트로피에 커서를 둡니다. 이제 어떤 문자가 다른지 알 수 있습니다. 그러나 그들은 어떤 캐릭터입니까? 두 개의 키 입력 명령 CTRL-x =를 입력하면 emacs는 문자, 8 진수, 10 진수 및 16 진수로 된 ASCII 값, 파일 시작부터의 문자 오프셋 및 줄 시작부터의 문자 오프셋을 표시합니다. ASCII는 7 비트 인코딩이므로 모든 ASCII 문자는 상위 비트가 꺼져 있습니다. 첫 번째 아포스트로피의 값이 0x27이고 두 번째 아포스트로피가 0x92 인 것을 확인하면 첫 번째 아포스트로피가 ASCII 문자 집합에 있고 두 번째 아포스트로피가 아닌 것이 분명합니다.
Emacs는 아마도 최초의 IDE 중 하나였습니다. 특정 언어에 대한 모드가 있습니다. 코드를 더 읽기 쉽게 만들기 위해 코드에 일관된 들여 쓰기를 적용하는 데 유용합니다. 코드 컴파일 및 디버깅을위한 기본 제공 기능도 있습니다. C와 같은 컴파일 된 언어를 작성할 때 쉘 프롬프트에서 그렇게하는 데 익숙했기 때문에 컴파일 기능을 많이 사용하지 않습니다. 디버깅 기능은 C와 C ++에서 매우 훌륭했습니다. 이제 Eclipse의 디버깅 기능과 거의 동일한 기능을 얻을 수있는 방식으로 gdb를 편집기와 통합했지만 최신 GUI 기반 IDE가 수행하는 방식으로 화면 공간을 낭비하지 않았습니다. 이론적으로 디버거 통합은 거의 모든 다른 언어에 쉽게 적용 할 수 있어야합니다.
Emacs를 사용하면 입력중인 내용을 기억하기 시작할 때와 중지 할 때를 알려줌으로써 매크로를 만들 수 있습니다. 이것은 자주하는 작업에 매우 강력합니다.
Lisp를 알고 있다면 Emacs는 무한히 확장 할 수 있습니다. 그러나 Emacs Lisp를 배운 적이 없지만 Emacs는 내가 사용해 본 도구 중 가장 강력한 도구 중 하나입니다.
Emacs 키 바인딩. 나는 Emacs 키 바인딩이 형편 없다는 것을 인정하는 첫 번째 사람이 될 것입니다. 하지만 제가 사용한 다른 어떤 것보다 훨씬 강력해서 키 바인딩을 기꺼이 감수 할 것입니다.
유머러스 한 맥락에서, 수년 전 Emacs의 저자 Richard Stallman (GPL의 창시자, GNU 프로젝트의 창시자, FSF의 창시자)은 vi 대 emacs를 거룩한 전쟁으로 취급하는 사람들을 칭찬했습니다. 그는 Emacs 교회의 "Saint IGNUcius"라는 캐릭터를 발명했습니다. Stallman은 "때때로 사람들은 다른 텍스트 편집기 vi를 사용하는 것이 Emacs 교회의 죄인지 묻습니다. 음, vi vi vi가 짐승의 편집자이지만 무료 버전을 사용하는 것은 사실입니다. vi는 죄가 아니라 참회입니다. " ( http://stallman.org/saint.html 참조 . 그의 귀여운 사진도 있지만 StackOverflow를 처음 사용했기 때문에 하나 이상의 URL을 게시 할 수 없습니다. 동일한 도메인으로 이동하세요. 하지만 saintignucius.jpg 파일을 가져옵니다)
저는 2 년 전 Emacs를 탐구하기 전까지 10 년 동안 Vim을 사용했습니다. 시간이 지남에 따라 생산성 곡선이 어떻게 변했는지에 대해 상당히 신선한 기억이 있습니다.
내 포인트는 모두 조건부, YMMV는 귀하의 강점과 경험에 따라 다릅니다.
셸에서 작동하는 Ca, Ce, Cn, Cp, Ck, Cy 등에 익숙 할만큼 Unix와 명령 줄을 충분히 사용했다면 동일한 바인딩을 사용하도록 전환하는 데 오래 걸리지 않을 것입니다. 기본값) Emacs에서. 최근에 XCode도 이러한 바인딩을 사용한다는 사실을 발견했습니다.
항상 실행되는 편집기, 텐딩 버퍼 (브라우저 탭과 같은)에 익숙하고 애플리케이션에 거주하는 (브라우저에서 Web2.0 앱을 사용하는 것처럼) Emacs는 즉각적인 생산성 향상을 보여줄 것입니다.
일반적으로 많은 관련 파일의 프로젝트에서 작업하는 경우 이러한 지속성은 해당 버퍼에 대한 컨텍스트를 유지하는 데 몇 가지 추가 이점을 제공합니다. 각 버퍼는 열린 파일에서 컨텍스트 화되어 해당 프로젝트에 대한 다양한 생산성 향상 도구 (예 : grep-find, eshell, run-python 및 slime)를 편리하게 사용할 수 있습니다. 이것은 텍스트 완성, yasnippets 등과 결합하여 구성에 따라 특별하고 크게 개별화되었지만 IDE와 같은 작은 부분으로 보이기 시작합니다. 이것은 ECB와 같은 좀 더 문명화 된 Emacs IDE와 같은 서비스와는 다릅니다.
내 생산성은 처음에 "jjjkkk"를 입력하면서 첫 주 정도 Esc-Esc-Esc-Esc를 계속해서 입력했습니다. 다음 주에는 조심스럽게 오른쪽 탐색 키를 사용하기 시작했습니다. 그런 다음 구성 파일을 발견했습니다 ... 솔직히 처음부터 Emacs Starter Kit 가 있었다면 내 생산성이 3 ~ 4 주에 걸쳐 서서히 동등하게 돌아 갔다고 말했을 것입니다.하지만 구성 파일 토끼 구멍으로 내려갔습니다. 하지만 제 동료가 vim에서 emacs로 방금 전환했고 방금 Starter Kit를 챙겨 가고 있습니다. 첫 주에 그는 편안하고 모든 놀라운 혜택을 누리고있는 것 같습니다 (그 감각은 아마도 10 년 동안 지속될 것입니다).
마지막으로, 실수를하면 원형 킬 / 양 크링 및 언두 링으로 즉시 생산성 (및 자신감)을 얻을 수 있습니다. 나는 또한 개인적으로 지역별 실행 취소의 팬입니다.
내 짧은 대답은 예입니다. Emacs를 배우기 위해 3-4 주 동안 생산성 저하를 겪을 가치가 있습니다. 개발을 위해 Emacs보다 간소화 된 유닉스 유틸리티 콤보를 선호한다고 결정하더라도 편집기를 넘어 광범위하게 적용 할 수있는 교육을 얻을 수 있습니다.
Emacs 문서는 포레스트입니다. 저는 Vim의 문서가 얼마나 체계적이고 많은 기능이 얼마나 잘 어울리는 지 깨달았을 때 Emacs에서 Vim으로 왔습니다. Emacs 전문가의 길에 무엇이 있는지는 모르겠지만 유용한 것을 배우는 데는 오랜 시간이 걸리고 nethack에서 더 나은 결과를 얻지 못할 것이라고 경고합니다. Vim을 고수하십시오.
Textmate 는 더 나은 Mac 용 Emacs이지만 Solaris에서는 도움이되지 않습니다. Eclipse는 멋지고 많은 플러그인이 있습니다.
Emacs는 귀하의 필요에 맞게 학습하고 사용자 정의하려는 경우 생산성 향상을 제공합니다. 대부분의 사람들은 그렇지 않습니다. 생산성을 높이려면 단순한 편집 이상의 도구를 사용해야합니다. 대부분의 사람들은 단순한 편집을 지나치지 않습니다.
다음은 간단한 테스트입니다. 환경을보다 효율적으로 만들기 위해 창 관리자를 사용자 정의 했습니까 (요구에 맞게 조정 됨)? '아니오'이면 emacs를 배워서 ROI를 얻지 못할 것입니다.
즉, Java를 개발하는 경우 Eclipse가 표준 답변이므로 질문은 꽤 논쟁의 여지가 있습니다.
저는 Vim에 매우 만족했지만 org-mode에 대해 들었을 때 Emacs를 배우기 시작했습니다. org-mode는 Emacs를 배우는 강력한 이유 중 하나 일 수 있습니다.
나는 emacs를 사랑하고 매일 사용합니다.
즉, 학습 비용이 향후 생산성 향상으로 회수 될 것이라고 생각하지 않습니다.
Java를 프로그래밍하는 경우 좋은 IDE가 필요합니다. Emacs는 하나가되기위한 공정한 길을 가고 있지만, 현실을 직시하자, IDEA 등은 손을 내 밀었습니다. (emacs는 아마도 많은 IDE에서 영감을 얻었을 것입니다. 그러나 그것은 또 다른 이야기입니다).
두 번 나는 Emacs를 배우려고 노력했습니다. 내 두뇌가 작동하는 방식에 맞지 않아서 사용하지 않습니다.
Emacs (또는 vim)는 vim (또는 Emacs)보다 훨씬 낫지 않습니다. 둘 다 놀라운 일을 할 수있는 많은 옵션을 추가 할 수 있습니다. Emacs에서 수행 할 수있는 모든 작업은 표준이 아닌 Vim에서도 수행 할 수 있습니다.
Emacs를 사용해보십시오. 더 잘 맞는지 확인하십시오. 잃지 않는 상황입니다.
emacs를 더 자세히 살펴보고 싶지만 오랜 시간 동안 사용할 수 없습니다. 손이 아파요. 내가 끔찍하게 잘못하고 있습니까?
vim과 emacs는 가장 유능한 편집자이며 꽤 오랫동안 사용되어 왔습니다. 당신이 정말 잘 안다면 그 과정에서 많은 것을 얻을 수있을 것 같지 않습니다 ...
그러나 몇 가지 새로운 플러그인이 생산성을 향상시킬 수 있기 때문에 어떤 플러그인을 사용할 수 있는지 살펴 보는 것은 항상 좋은 생각입니다.
/ 조한
아니요 (그리고 둘 다 사용했습니다).
종교 전쟁을 찾지 않는 것과 같은 맥락에서 (하지만 꼭해야한다고 생각한다면 저를 비하하십시오) 왜 vi에 대한 유일한 선택이 이맥스라고 생각합니까? 개발중인 OS입니까, 아니면 탐색 한 옵션입니까?
Java 개발 환경은 코드 편집 및 리팩토링 지원과 관련하여 최고는 아니지만 요즘 최고의 IDE (무료 및 유료) 중 일부를 즐깁니다 .IntelliJ IDEA에는 집에서 더 많은 것을 느낄 수있는 vi 플러그인도 있습니다. 예를 들어 (Eclipse에서 비슷한 것을 사용할 수 있는지 확실하지 않음). 도구를 변경하는 것은 학습 곡선을 의미하지만 도약이 충분히 크면이를 수행하는 데 소요되는 시간이 가치가있을 수 있습니다.
얼마나 빨리 입력합니까? 당신이 사냥하고 펙을한다면, emacs는 당신을위한 것이 아닙니다. 빠른 방법이라면 항상 마우스를 잡을 필요가 없습니다.
일반적으로 emacs는 vi보다 강력합니다. emacs에서 더 많은 일을 할 수 있습니다.
텍스트 편집기를 프로그래밍하는 데 시간을 투자하기로 결정하면 생산성이 향상됩니다. 두 편집기 중 emacs는 더 나은 프레임 워크 또는 지속적인 사용자 정의를 제공합니다. 텍스트 편집기를 프로그래밍하지 않으면 편한 방식으로 유지하십시오.
Emacs를 배우는 한 가지 좋은 이유는 다른 프로그램도 Emacs 키 바인딩을 사용하기 때문입니다. 예를 들어 bash 프롬프트에서 Emacs 키 바인딩을 사용하거나 GNU readline을 사용하는 다른 모든 것을 사용할 수 있습니다. 다른 프로그램에서 사용할 수 있도록 Emacs에서 기본 동작 및 단어 / 줄 삭제 및 실행 취소 / 다시 실행 코드를 배우는 것이 좋습니다. Emacs를 다시 사용하지 않더라도 다른 도구에서 생산성이 향상됩니다.
저는 Vim과 Emacs를 알고 있으며 Vim은 제 두뇌와 습관에 더 잘 맞습니다. 그러나 다른 사람들은 Emacs에 대해서도 똑같이 주장합니다. 시도하지 않으면 자신을 알 수 없습니다. Emacs를 잘 배우는 데 그리 오래 걸리지 않아 좋아할지 여부를 알 수 있습니다.
내 생산성이 정말 향상 될까요?
처음 며칠 / 주 동안은 절대 그렇지 않습니다.
당신이 뭔가를 편집하고 싶을 때마다 튜토리얼을 읽지 않아도된다면 ..
Emacs 는 vim보다 "강력"하고 스크립팅 엔진이 훨씬 더 유연하며 emacs를 중심으로 구축 된 훨씬 더 많은 스크립트, 모드 및 유사 기능이 있습니다.
그렇긴하지만 정반대가 맞습니다. vim에 대한 지식을 향상시키는 데 같은 시간을 투자했다면 생산성도 ..
같은 방식으로 생산적이지 않을 수도 있습니다. vim이 파일 편집에 더 빠르고 emacs가 다른 모든 작업을 수행하는 데 더 낫다고 말하고 싶습니다 (다시 말하지만 개인적으로 flymake-mode, VCS 바인딩은 vim에 해당하는 것보다 사용하기가 더 빠릅니다)
나는 Alan Storm에 동의합니다. "Emacs에서 사용되는 패턴과 은유가 당신의 두뇌와 일치하지 않을 수 있기 때문입니다."
이것은 매우 중요한 요소입니다. 다른 두뇌는 다른 인터페이스에 다르게 적응합니다.
Some of the main - and easily available - features I really love Emacs for, and I count as productivity enhancers:
1. "yank-pop" facility - every cut/copy is saved into a stack so you can later choose which to paste (don't know if vi / Vim has this but most Java IDEs don't)
2. the Ctrl-key navigation mapping - this allows you to navigate your file without moving your hands off to use the arrow keys. (key-binding in other editors helps of course)
3. available on almost every platform (true of vi/Vim too of course) - whether GUI- or text-based (Java IDEs are available on most platforms too but only in GUI mode, and are significantly larger and need to be installed separately whereas Emacs is generally more widely available - BSD / *nix / Linux / Mac systems
4. I prefer my editor to stay out of the way until I need it - Emacs' spartan display forces me to think before I type.
5. The basic navigation keys in Emacs are kind of universally available - on my Mac OS, I can use these keys in terminal, mac mail, etc.
Ultimately, if Emacs' philosophy appeals to you, you will put in the extra effort to learn it. And it will reward you.
Since vi/Vim and Emacs are pretty close in terms of what they can or cannot do, productivity with these two editors comes from experience in using it.
In my opinion, being a programmer it won't take you long to get the general idea about Emacs once you start using it. Others can only say so much, you got to try it out for yourself to know it.
As for me, I use both. It's like taking more than one weapon to a war, use the right one in the right circumstances. ;)
I like Emacs, you can extend it by your needs- in my eyes, any system which you can extend by yourself is award-worthy.
Disclaimer: I'm ignorant. I've been an emacs user for about 4 years, and vim user for about 6 months, maybe more like 15 if you count all the times I've tried to learn it and hated it. (The writing vs moving mode distinction kills me. Every time. So if it doesn't kill you then my opinion might be completely worthless.) That said, I think my opinion is actually interestingly different from the 26 others that I've seen on here, so I'm going to voice it. :Disclamer
My opinion:
- Emacs is better for typing, especially large-scale "I'm writing a new feature and it will be a while before I even try to see if it runs".
- Vim is better for editing, especially quick edits.
When I need to understand and hack in 8 files simultaneously, Emacs' properties as a tiling window manager with multi-buffer (buffers have a 1.2:1 correspondence to files, they're often the same thing, but aren't necessarily) regexp-search (and replace) are incredible.
If I don't like some small thing because of git diff in the shell (I don't use emacs' VC features very often, although when I do I love them) I open it with vim and get the hell out faster than I could hit Alt-TAB.
The fact that Emacs' editing commands are more readily available while typing make typing much faster than it is in Vim. Ctrl+a is much faster than ESC ^ i, and you don't have the cognitive load of "do I want a or i or o or O..." which, god, I hate thinking about. And same for all the other movement commands commands.
I type faster, much faster, in Emacs. That means things like Org Mode (which I use for everything: TODO lists, bug tracking, notes, long emails, documentation...) make more sense (to me) in Emacs than they would in Vim.
And, Elisp is incredible, even though it sucks. It totally makes up for Emacs' broken regular expressions: you can use the full power of emacs everywhere, including in a multi-file regexp-replacement. And in text snippets.
If you are concerned about the health of your hands choose Vim.
I suffered from a bout of RSI in the past, and I found one of the main culprits was "chording" i.e. holding down many keys at the same time. Emacs uses chording extensively whilst VIM uses single letter commands chained in quick succession. This puts much less strain on your hands as the muscles don't have to twist and contort to perform commands in the editor. Injury due to RSI can ruin your productivity so in your calculations be sure to account for this.
I really see no reason to switch. I've used vi for a long time and am quite comfortable with it; about every six months I would install emacs to give it a go, then quickly just switch back. Yes there were things I much preferred about vi, but the main reason I never stuck with it is because the time investment to fully learn another editor when I already know an extremely capable one isn't worth it.
I'm reminded of this rather dated study.
In my opinion, SLIME is about the only reason to switch to emacs if you're already proficient with vi.
No
I've been using emacs for years, I'm a convert from VIM, and I love it to bits.
But any productivity gains from having a better, programmable editor will be totally wiped out by the enormous amount of head-fucking that it takes to get the hang of emacs. It was designed as a console editor, and its idea of interface is not yours.
And even when you've got it completely, your extra productivity will mainly be expressed in the extra emacs lisp you can write.
Who cares? It's great fun, and lisp is the dogs! If you want to 'get things done', then forget about programming. You can always hire programmers to 'do' 'things'.
The only circumstance under which I'd recommend learning emacs for productivity reasons is if you're a lisp/scheme/clojure programmer. It makes such a good lisp environment that then the few seconds it will save you every time you want to do anything will quickly add up to a real gain. And elisp (which stands in relation to lisp as excel macros stand to ALGOL) will seem much less alien if you already use a real lisp.
If you do give it a try, use it on a virtual console where it feels more like a sane way to arrange an editor. Only when that makes sense try to use it under a window system, which will fight with it.
In an earlier answer, Aristotle Pagaltzis wrote: "Vim excels in the small ... You can easily do things in Vim in the normal course of editing that would require you to drop down to scripting in Emacs."
I switched to Emacs after over a decade of exclusively using vi, and initially I would have agreed with the claim, "You can easily do things in Vim in the normal course of editing that would require you to drop down to scripting in Emacs." But then I discovered that by using Emacs' macro capability and a large repeat count, I could easily make Emacs do pretty much everything that vi had made easy, and a great deal more.
Emacs' macro functionality involves three commands:
C-x ( start remembering keystrokes
C-x ) stop remembering keystrokes
C-x e replay the remembered keystrokes
For example, in vi if I wanted to find all <a> tags in an HTML file and add a target attribute, I might do something like the following:
:g/^<a/s/>/ target="_blank">/
This example is not perfect, since it assumes that all <a> tags are on a line by themselves. But it's good enough for illustrating how one accomplishes the equivalent task in two different editors.
To achieve the same effect easily in emacs, here's what I do:
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
Here's a description of what each keystroke above does:
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
It looks complicated, but it's actually very easy to type. And you can use this approach to do lots of things that vi can't do, without ever dropping down to Lisp code.
ReferenceURL : https://stackoverflow.com/questions/48006/is-it-worth-investing-time-in-learning-to-use-emacs
'IT TIP' 카테고리의 다른 글
| 모서리가 둥근 CGRect (Swift)로 UIImage / -View를 만드는 방법 (0) | 2020.12.27 |
|---|---|
| 배경에 16 진수 색상 코드를 설정하는 방법 (0) | 2020.12.27 |
| iPhone HTML5 비디오 재생 버튼 숨기기 (0) | 2020.12.27 |
| 서명하는 동안 오류가 발생했습니다. (0) | 2020.12.27 |
| Twitter Bootstrap은 li에 활성 클래스를 추가합니다. (0) | 2020.12.27 |