Emacs

이맥스. 유명한 UNIX 환경 문서 편집기 중 하나이다.

확장성이 매우 높은 것으로 유명한데, 키보드 단축키만 해도 1,000개가 넘어가는 엽기적인 면모를 갖추고 있다. 더군다나 매크로가 엄청나게 많아서, 다 익히는 것은 불가능에 가깝다. 1970년 중반부터 개발이 시작되었으며 2019년 현재까지도 활발하게 개발이 이루어지고 있는 상황이다. 역사가 긴 만큼 여러 버전이 있는데 역시 가장 정통으로 인정받는 버전은 GNU Emacs로, 현재 GNU Project(오픈 소스 프로젝트)에서 관리하는 버전이다. 그러나 이 외에도 XEmacs, Aquamacs 등 다양한 버전이 존재한다.

본디 TECO라는 편집기에 매크로를 짜 넣으면서 개발이 시작되었는데 유명한 리처드 스톨먼이 첫 주자로 개발을 시작했다. 이후 TECO 편집기 매크로를 짜던 여러 사람들이 합세하여 본격적으로 개발이 시작되었다.



UNIX 계열에는 이맥스 말고도 vim이라는 녀석이 있는데, 이 둘이 편집기 양강 체제를 구축하고 있는 상황이고, 오랫동안 둘을 비교하는 떡밥과 함께 키배가 진행되었다. 심지어 편집기 전쟁이라는 용어를 사용할 정도. 제공하는 기능 면에서는 이맥스가 확실한 우위에 있었지만, 가벼움 및 편리한 환경 이동에 있어서는 vim이 우위에 있었기 때문에 결국 편집기 워는 결론이 날 수 없는 네버엔딩 스토리가 되었다. M16 소총 vs. AK-47 과 비슷한 경우라 볼 수 있다. 역시나 최강자는 ed

vim이 vi였던 시절에는 vim script 같은 것이 존재하지도 않았기에 확장 기능을 개발하기에 무리가 있었다. 2020년 현재는 vim script도 여러 패러다임을 채용하여 상당히 범용 프로그래밍 언어에 가까워졌기에 이맥스 못지 않게 다양한 기능을 작성할 수 있게 되었고, 실제로도 굉장히 많은 플러그인이 존재한다. 그렇다고 하여도 여전히 vim이 이맥스의 기능을 구현하기는 무리가 있으며, 이맥스도 많은 확장 기능들이 개발되고 있기에, vim에 비해 확장성이나 제공되는 기능이 떨어진다고 보기 힘들다. vim이나 Emacs나 터미널에서도 기능을 온전히 사용할 수 있지만 생각보다 많은 플러그인들이 TUI와 잘 안 맞는다. 게다가 반대로 Emacs에서 터미널을 에뮬레이팅 할 수 있기에...[1] 다만 vim이나 Emacs나 스크립트 인터프리터가 무진장 느리기 때문에 플러그인을 많이 설치하면 둘 다 많이 느려진다. Emacs에는 Vim의 키 바인딩을 지원하는 Evil 모드가 있고, Spacemacs와 같은 키트를 이용하면 기본 설정이 Vim 바인딩이기 때문에 Vim을 쓸 줄 안다면 상당히 쉽게 Emacs를 사용할 수 있다.

실제로 클라이언트가 윈도우인 게임 서버를 제외한 거의 대부분의 분야에서는 유닉스/리눅스가 압도적으로 사용되고 증가하는 추세이다. 특히 발전소 시스템과 변전소 시스템은 유닉스/리눅스가 전부라 해도 좋을 정도이다. 이 때, 업체에선 납품할 서버에 업무와 관계없는 툴이나 앱은 최소한으로 설치하거나 디폴트를 유지하는데 vi/vim이 안 깔린 리눅스/유닉스 계열은 사실상 존재하지 않다 보니 자연히 그러한 개발 환경의 엔지니어들은 현장과 동일한 툴에 익숙해지는 게 유리하기 때문이기도 하고, 이맥스 특유의 커스텀이 자신이 설정하지 않은 환경에서의 사용에 심한 이질감을 느끼게 하는 것도 원인으로 지적된다. 다만 TRAMP를 쓰면 애초에 서버에 Emacs가 설치되어 있을 필요도, 터미널로 로그인 할 필요도 없이, 로컬 편집기에서 서버 파일을 수정할 수 있으므로 기존 설치 유무는 그다지 영향이 없다. 사실 Emacs를 쓰는 사람들은 VI를 대체로 쓸 줄 아는 사람들이기 때문에 그냥 깔려 있는 거 쓴다는 게 더 정확한 얘기일 듯. 게다가 Emacs 오래 쓰는 사람들은 당연히 자신의 Setting을 옮길 방법도 마련해 놓는다. 대표적으로 GitHub에 공유해놓거나 tar로 Portable 저장장치에 저장하는 경우가 있다. Emacs와 vim에 대한 공정한 비교는 Emacs는 vim만큼 많은 배포판에 기본으로 깔려있지 않다는 것으로 마무리 지어야 한다.

처음 개발이 시작된 곳은 MIT AI Lab에서 Incompatible Timesharing System (ITS) 이라는 OS에 쓰이던 TECO(Tape Editor and Corrector)라는 편집기에서 시작되었다. 요즘 쉽게 접할 수 있는 편집기들과 달리 TECO는 편집 모드, 추가 모드, 문서 출력 모드가 따로 존재했으며 텍스트를 타이핑해 입력했어도 바로 현재 편집 중인 문서에 반영되지 않고 명령어를 이용하여 해당 문자열을 입력하도록 프로그램 하여야 비로소 입력되는 불편함을 자랑했다. 사실 이 당시 편집기들은 이 정도면 편리한 것이었다. 옛날에는 펀치 카드로 프로그래밍을 했다는 것을 상기해 보자. 이와 비슷한 편집기로 vi의 전신인 ed라는 녀석이 존재한다.

스톨먼은 1972~1974년 동안 스탠퍼드의 AI Lab 을 방문하면서 E라는 편집기를 접하게 되는데, 이게 바로 WYSIWYG(What You See Is What You Get)기능을 가지고 있었다. 여기에 놀란 나머지 이후 MIT로 돌아와서 TECO에 비슷한 기능을 구현하게 되고, 편의를 위해 여러 매크로를 추가하면서 점점 불려나가기 시작했다. 이후 매크로가 점점 많아짐에 따라 MACS라는 은어가 쓰이게 되었고, Editing MACroS라고 아예 새로운 이름으로 부르게 된 것이 EMACS의 시작이다. 초기 버전은 MIT AI Lab에서 쓰이던 PDP 계열 컴퓨터에서만 쓸 수 있었다.

이후 다른 기종에 쓰일 수 있도록 코드를 다시 쓰는 과정에서 SINE, EINE, ZWEI 같은 편집기가 나왔는데, 이들의 특징은 LISP 언어를 사용하여 짜여졌다는 것이었다. 이후 LISP 언어는 모든 Emacs 버전에서 채용되었고 현재까지도 GNU Emacs나 나머지 변종들은 전부 LISP 언어 기반으로 작동한다. 1981년에 드디어 C로 쓰여진 Emacs가 UNIX에 쓰이기 시작했는데 이 당시에는 자유 소프트웨어가 아니었다.

앞에서 언급한 1981년 버전은 상용이었기에 1984년 리처드 스톨먼은 Emacs를 자유 소프트웨어로 만들려 했다. 1981년의 상용 버전과 다른 점은 LISP 엔진을 오리지널로 교체하였고 거의 모든 코드를 새로 짜 넣으면서 GNU로써 최초의 프로그램으로 나오게 된다. 이후 상용 버전보다 더 많은 기능을 구현하게 되어 결국에는 다시 UNIX로 돌아와 상용 버전을 밀어내게 되었고, UNIX에서 사용되는 Emacs 편집기의 가장 대표적인 예로 자리잡게 된다. 이후 1986년에 보안 허점이 발견되어 루트 계정이 털리는 사건이 일어난 후 1999년까지 성당과 시장 모델을 도입함에 따라 개발이 지체되게 된다. 흑역사 현재는 스톨먼이 직접 개발하는 것은 아니고 슈테판 모니어(Stefan Monnier)와 정이동(Chong Yidong)에게 물려주었다.

1991년에 시작된 가장 유명한 Emacs 변종으로, Lucid Inc.에서 GNU Emacs 알파 19 버전을 기반으로 개발되었다. 초창기에는 Lucid Emacs라 불리다 XEmacs로 바뀌었다. 현재는 GPLv2 라이선스를 통해 공짜로 풀려 있다. GNU Emacs 개발이 지체된 흑역사기간 중 C++ IDE를 만들어야 하는 입장에 놓인 개발자들이 직접 개발한 것. 덕분에 개발 당시에는 GNU Emacs보다 훨씬 미려한 GUI 인터페이스를 가지고 있었다. 원래 Lucid Inc.에서 개발되었기 때문에 처음에는 당연히 상용이었으나 1994년 도산하는 바람에 결국 오픈 소스 프로그램으로 전환하게 된다. 이름을 XEmacs로 바꾸었는데 X Window System과는 전혀 관계가 없고, X로 붙인 이유는 단지 더 이상 Lucid를 붙일 이유가 없었기 때문.

역시나 GNU Emacs와 같은 기능을 가지고 있으며 많은 언어를 지원(적어도 이들 언어로 문서를 작성 가능)한다. 물론, Windows와 macOS 플랫폼에서도 돌릴 수 있다. Emacs Lisp 언어를 이용해 여러 기능을 건드릴 수 있다는 점도 동일하다. 이렇듯이 기능이 흡사한 만큼 GNU Emacs와 저작권 문제로 시끄러웠던 적이 있지만 뭐, 이것도 이제는 오픈 소스인데... 앞에서 언급되었듯이 XEmacs는 원래 기업용으로 개발한 것. 게다가 현재 XEmacs 코드 전반의 저작권을 행사하는 곳은 다름 아닌 GNU. 게다가 지금도 GNU Emacs와 코드를 공유할 정도.

여러 가지 변종들이 나왔는데, 일본에서 윈도우즈 기반으로 제작된 Meadow, XEmacs의 사생아 SXEmacs, OS X 용으로 개발된 Aquamacs가 유명하다. 이것들 외에도 클론 버전들이 아타리 사태를 방불케 할 정도로 많이 출시되었다. 이렇게 된 이유는 당시 Emacs 가 돌아가는 환경이 비교적 고사양이었기 때문. 32비트 주소 공간과 1메비(MiB)바이트[2]의 램을 필요로 했기 때문이다. 유명한 변종들의 리스트는 다음과 같다.

등 많이 있다.

이맥스는 기본적으로 텍스트 에디터이다. 즉, 워드프로세서와 달리 폰트 기반의 텍스트를 다루는 것이 아니고, 노트패드처럼 텍스트를 다룬다. 기본적인 텍스트 편집기 기능 외에도 단어나 문장 단위로 편집할 수 있는 기능을 가지고 있고, 여타 프로그래밍 언어 개발 환경에서 보이는 구문 강조 기능 및 매크로 기능이 존재한다. 기반은 TECO 같은 물건이지만 사실상 현재 나와 있는 텍스트 편집기들과 사용 방법은 다르지 않다.

LISP의 dialect로 Emacs Lisp라는 컴퓨터공학 전공이 아니면 보통 접할 일이 없는 특이한 컴퓨터 언어 인터프리터를 내장하고 있어서, 마음만 먹으면 여러 가지 강력한 매크로는 물론 심지어 게임 까지도 만들어 버릴 수 있다. 인터프리터 방식을 사용함에 따라 프로그램을 재 시작하거나 재 컴파일할 필요 없이 새로운 기능을 마음껏 구현할 수 있는 것이 특징이다. 이맥스를 확장하는 방법은 대략,

으로 나눌 수 있다. 관련만화

이렇기 때문에 만들어 넣기만 한다면 대체로 이맥스로 못 하는 것을 발견하기가 어려울 정도인데, 덕분에 타 프로그램들과 연동하여 거의 무한에 가까운 확장성을 자랑한다. 예를 들어, 프로그래밍을 위한 IDE(Integrated Development Environment)를 구성할 수도 있고, LaTeX 타입세팅을 위한 환경을 조성하는 것도 가능하다.

버전 24부터 기본으로 포함된 Emacs의 패키지 관리 시스템이다. package-list-packages 모드에서 대부분 간단하게 설치/삭제가 가능하다.

관련 링크: http://emacswiki.org/emacs/ELPA

유명한 저장소 주소 (대개 이 세 군데의 저장소에 있는 패키지로 Emacs가 할 수 있는 거의 모든 것을 다 할 수 있다.)

아래는 유명한 확장 기능들을 나열한 것이다.

물론 이 외에도 엄청나게 많다... 그리고 이 중에서 AUCTeX와 Org-mode 는 가히 이맥스의 킬러앱이라 봐도 될 정도로 많은 기능을 내장하고 있고, 프로그래밍이나 다른 용도로 쓰지 않더라도 저것만을 위해 이맥스를 사용하는 사람들도 있을 정도. Org-mode는 익숙해지면 생활의 모든 기록을 Org-mode를 통해서 해도 될 정도로 편하다. 단 높은 진입 장벽이 문제. 근데 기능이 많은 만큼 배우기도 어렵다.편집기 속의 일개 모드 주제에 매뉴얼만 책 한 권 분량 저것들이 다 잘 유지보수되는 것은 아니지만, 인기 있는 확장은 유지보수가 잘 되는 편.

앞에서 언급되었다시피 초창기에는 상당한 고사양의 머신을 요구했으므로 성능 자체는 텍스트 에디터 치고는 별로 좋지 않았다. 이맥스가 개발된 시기를 생각해보자. 1970년대에 PC 성능이란 그야말로 안습 그 자체. 이는 주로 Lisp 인터프리터를 사용해야 했기 때문인데 덕분에 Eight Megabytes And Constantly Swapping이라는 오명을 얻기도 할 정도였다. 이 또한 줄이면 EMACS가 된다. 다른 표현으로는, Emacs Makes A Computer Slow, Eventually Mallocs All Computer Storage, Eventually Makes All Computers Sick이 있다. 그래서 편집기 전쟁 키배가 일어나면 항상 까이는 원인이 되고 말았다.

그러나 하드웨어의 발전으로 이러한 지적들은 더 이상 유효하지 않게 되었고, 현재 사용되는 GUI 워드프로세서 혹은 IDE 프로그램들과 비교하면 훨씬 빠르게 로딩된다. 게다가 vi의 정식 후계자라 볼 수 있는 vim도 기능을 이거저거 추가하다 보니 이맥스와 사이즈 측면에서 비견이 가능할 정도로 불어나게 되었다. 다만, 이맥스의 경우 실행 시 Elisp 설정 파일을 불러오는데 Elisp이 속도가 느린 편이라 설정 파일이 좀 거대한 경우는 실행 시간이 여전히 vim 에 비해 상당히 떨어지는 편이다. vim도 물론 설정파일을 불러오긴 하지만, 거대한 정식 프로그래밍 언어인 Elisp에 비하면 말 그대로 그냥 설정 파일 수준이라 오늘날 컴퓨터 기준으로 속도에는 거의 영향이 없다. 32비트 시스템에서 거대한 파일을 다루는 데 문제가 발생하기도 했는데, 23.2 버전 이전에는 고작 256MB 정도의 크기만 다룰 수 있었고, 현재도 512MB 정도 밖에는 못 다룬다. 물론, 64비트 시스템에서는 이러한 문제가 없다. 1024PB가 최대 한도.

또 타 OS에 비해 Windows에서 성능이 떨어지기도 한다. 주로 텍스트 렌더링 부분이 그러다 보니 저사양 컴퓨터에서는 스크롤하다가 렉이 심하기도 하다.

GUI 파트를 제외한 순수한 이맥스는 Elisp 인터프리터와 소수의 primitive function 정도만 C로 만들어져 있으며, 나머지는 전부 그걸 사용하는 Elisp 코드로 구성되어 있다. 바꿔 말하면 C 언어가 지원되는 환경에선 이맥스가 돌아간다. 그리고 윈도우를 비롯한 대부분의 플랫폼은 다 C 언어가 지원되기 때문에 현존하는 거의 모든 운영체제를 지원한다. 유닉스 계열 시스템은 물론, 도스, 윈도우즈에서도 구동시킬 수 있는 버전이 있다. 또한, 텍스트 터미널에서 구동시킬 수도 있고, GUI 환경에서 구동시킬 수도 있다는 특성이 있다. 반대로 경쟁자인 vi는 gvim 같은 GUI 기반의 파생형이 나오기 전까지는 텍스트 터미널에서만 구동 가능했고, gvim의 경우는 별개의 프로그램으로 취급한다. Unix 계열의 플랫폼에서는 X Window 시스템에서 gtk 라이브러리 기반으로 작동하고, OS X에서는 Cocoa 기반으로 작동(현재 24.3 버전)한다. 물론 윈도우즈에서도 다른 GUI 라이브러리를 설치할 필요 없이 잘 작동한다. 윈도우즈 버전 같은 경우에는 인스톨도 필요가 없는 포터블 버전이다.

지구상의 모든 언어를 전부 사용할 수 있다. 영어는 물론, 한국어, 중국어, 히브리어, 페르시아어 등을 지원하며, 이 언어들의 입력기들도 자체적으로 제공을 하고 있으며, ispell이라는 맞춤법 검사 프로그램과 연동시키면 맞춤법 검사도 가능하다. 역시 UTF-8을 지원하기 때문이다. 그러나 한 가지 문제는 오른쪽에서 왼쪽으로 쓰는 문자의 경우 현재 안정 버전에서는 문제가 있으나 bzr에 있는 최신 버전은 문제 없다.

또 한 가지 단점은 유저 인터페이스가 영어로 쓰여져 있었고, 현재까지 지역화가 안 되었다는 것이다. 물론 튜토리얼도 영어로 되어 있으므로 제대로 사용하려면 영어 공부가 필수이지만, 이걸 사용하는 사람들 중에 이 정도 영어를 해석하지 못 하는 사람은 없을 것이다. 짧은 튜토리얼은 한글화가 되어 있다. 하지만, 본격적인 매뉴얼이 시작되는 나머지 부분은 죄다 영어. 사실 분량이 정말 많기 때문에 누군가 번역을 해 준다면 한국 이맥스 역사에 이름이 남을지도 모른다!

덤으로 시각장애인들을 위해 청각적으로 피드백을 주는 이맥스피크(Emacspeak) 시스템을 지니고 있다.

vi의 단타 커맨드가 이맥스에서는 배 이상으로 불어나는 게 대부분이기 때문에 vi에 비해 편집이 불편한 것은 기정 사실이다. 하지만, 이맥스에서는 vi에서 불가능한 수많은 것들이 가능하고, 그중 하나가 유연한 사용자 정의이다. 일단 이맥스에서는 모든 단축키를 바꾸는 게 가능하다. 단축키 수준을 넘어서 아예 Extensible VI Layer(Evil) 등과 같이 vi 스타일로 바꿔 버리는 것도 가능하며, vi를 넘어선 본인에게 맞춤 형식으로 바꿔 버리는 것 역시 가능하다. 키를 바꾸는 것 외에 기존 기능을 이용하여 새로운 기능을 추가하고 여기에 단축키를 붙이는 것도 문제가 없다. 또한, vi에서 구경하기 힘든, 보통은 쓸데없지만 누군가에게는 유용할 수 있는 별의별 희한한 기능을 디폴트로 다 포함하고 있다. 예를 들어 현재 커서가 가리키고 있는 문자의 폰트에 대한 정보나, 버퍼에서 선택한 부분만 문자 인코딩을 바꾸는 기능[3], 화면의 문자를 가지고 장난치는 기능[4]등을 포함하여 이리저리 찾아보면 그야말로 lisp 해커들의 잉여력을 보여주는 듯한 기능들이 넘쳐흐른다.

기본 설정을 포함하여 자가 커스터마이제이션은 Elisp 코드로 하기 때문에 기본적인 Lisp 지식이 필요하지만, 워낙 많은 것들이 이미 내장 함수로 정의되어 있기 때문에 Lisp의 기본적인 문법 정도만 아는 수준으로도 상당히 유용하게 뜯어고칠 수 있으며, 패키지 저장소에서 다운 받은 패키지도 역시 동일하게 수정이 가능하다.

덕분에 vi가 단순히 키스토로크 수준의 중독성을 보이는 반면, 이맥스는 Elisp이라는 금단의 영역으로 발을 들여 놓게 되면 사용한 시간에 비례하여 용도나 워크플로우 자체가 아예 일반적인 편집기의 세계와는 점점 멀어지는 경향이 생긴다. 이 때문에 골수 이맥스 유저들에게는 OS나 플랫폼은 그냥 하드웨어에서 이맥스를 작동시켜 주는 무엇 정도로 전락하고 모든 것을 이맥스로 처리하는 경향이 있다.Q: 윈도우 쓸래, macOS 쓸래, 리눅스 쓸래? A: 이맥스만 돌아가면 아무래도 좋아...

일단 이맥스를 실행시키면 메모장과 비슷한 느낌으로 편집을 시작할 수 있다. 자판으로 문자 입력, 방향키로 커서 움직이기, 백스페이스로 지우기 등 전부 동일하며 키보드로 특수 명령을 입력하려면 주로 컨트롤 키와 메타 키 조합을 이용한다. 과거 키보드에서 Meta 키라는 게 있었으나, 오늘날엔 당연히 없고 Alt와 ESC가 Meta로 매핑이 되어 있다. 이 명령을 입력하는 방식이 약간 재미있는데, 예를 들어 저장을 하려고 하면 Ctrl+x를 누른 뒤, Ctrl+s를 누르면 된다. 이 경우 Ctrl 키를 그대로 누르고 있어도 상관 없다. 기능이 워낙 많아지다 보나 명령어를 입력하기 위해 마치 대전 격투 게임 스킬 사용하는 것처럼 시퀀셜(?)한 조합을 하는 방식이다. 사용하다 보면 게임하는 기분? 사실 이 부분이 vi와의 가장 큰 차이인데, vi의 편집 모드에서 단타 혹은 쌍타로 가능한 명령이 이맥스에서는 타수가 2배 가깝게 늘어나는 경우가 많은데다가 그 각각에 Ctrl/Meta 같은 modifier 키까지 조합되는 경우가 많아서 커맨드 입력 방식이 불편해 보일 수도 있다.

Buffer(버퍼)라는 개념이 있는데, 탭 기능을 가진 편집기를 생각하면 된다. 그러나 이 개념이 약간 더 유동적이라, 현재 문서의 상태 및 커서의 위치, 명령어 조합 등을 나타내 주는 '미니버퍼'라는 부분이 따로 존재한다. 여기서 문서 작업 외에 컴파일이나 타입세팅 명령을 내리던가, 검색 키워드를 입력하는 등 입 출력 작업을 하게 된다. 더 재미있는 것은 Bash 셸처럼 명령행 자동 완성 기능까지 있다. 이를 볼 때 얼마나 복잡한 명령어들이 많이 들어있는 지 실감할 수 있을 정도이다.

이맥스는 프레임(우리가 흔히 말하는 윈도우/창과 동일)과 그 안의 윈도우로 구성되어 있어서, 한 프레임을 여러 윈도우로 분할하여 사용할 수 있는데, 버퍼는 이러한 윈도우에 표시하는 것이 가능하다. 최근 편집기와 비교하면 탭 기능과 유사하다고 볼 수 있다만, 프레임을 나눠서 사실상 두 문서를 동시에 편집하거나, 한 문서를 부분 부분 나누어 편집하는 것도 가능하다. 심지어 한 버퍼는 문서를 펴 두고, 나머지는 설정 메뉴를 열고, 마지막 버퍼는 현재 돌리고 있는 프로그램의 결과물을 출력하는 등 다중 작업을 할 수 있다. 요즘에는 일반적인 일이지만 앞에 언급했던 것과 같이 1MB가 초 고사양이었을 시기에는 그야말로 충격과 공포의 기능이었다 할 수 있다. 물론 지금은 vim도 지원한다.

RSI(Repetitive Stress Injury)는 반복 사용 긴장성 손상 증후군이라는 흠좀무한 이름을 가진 질병으로, 젊었을 때 타이핑 작업을 많이 한 사람의 손가락에, 특히 엄지손가락 등의 강한 손가락보다는 새끼손가락 등 약한 손가락에 자주 발생한다. Esc-meta-alt-ctrl-shift 라는 이명을 가진 이맥스가 이 원인이 될 수 있다는 비판이 많다. 위 키들 대부분은 새끼손가락으로 누르기 쉬운 위치에 있고, 실제로 이맥스의 대부인 스톨먼도 이 질병으로 고생 중이다(이게 가장 타격이 컸다). 이맥스가 처음 개발될 당시 키보드는 Ctrl 키가 스페이스 바 바로 옆에 위치하여 있었다. 이맥스의 명령들이 대부분 Ctrl 키를 동반하는 것이 이것 때문인데, 문제는 현재 많이 사용되는 IBM PC 키보드의 경우 Ctrl 키가 대부분 끝쪽에 위치해 손가락을 쫙 펴야 하는 단점이 존재한다. 덕분에 새끼손가락이 많이 고생하는데[5], 이 때문에 Caps lock 키를 Ctrl 키로 매핑하는 기능이 존재한다. 다만, MacOS 버전의 경우 자주 사용되는 명령을 맥 키보드 스페이스 바 바로 옆에 있는 Command 키에 매핑하기 때문에 이런 문제가 적다. 그러나 확장 명령의 경우 얄짤 없이 Ctrl 키 조합을 써야 하니 그게 그거...

하지만, 사실 이는 이맥스만의 문제는 아니고 현재 IBM 키보드 배열 자체가 굳이 이맥스가 아니더라도 자주 쓰는 키들을 새끼손가락으로 누르기 좋은 위치에 배열하여 인체공학적으로 매우 좋지 못한 배열을 갖고 있는 것이 진정한 원인이다. 이맥스는 이것을 가속화하는 정도라고 보는 것이 옳다. 요즘은 저런 자주 쓰이는 키들을 중앙으로 몰아 엄지손가락 위치에 배열한 인체공학 키보드들도 있으며다만 가격이 흠좀무, 몇몇 이맥스 유저들은 오른발 왼발 위치에 페달을 배치하여 Alt, Ctrl에 매핑하여 쓰기도 한다.드럼을 배우자. 텍스트를 편하게 편집하고 싶으면 주변기기를 사라고! 결국 뾰족한 해결책이 있다기보다는 정기적인 스트레칭, 생활 습관, 그릐고 개인적인 꼼수의 영역에 맡길 수 밖에 없는 불가피한 문제.

유독 Ctrl, Alt, Shift 등을 많이 사용하기 때문에 이맥스를 주력 편집기로 쓸 생각이 있을 경우, 웬만하면 저 키들을 엄지 위치로 뺀 인체공학 키보드를 장만하는 것이 좋다. 키네시스, 말트론 등과 같이 전통적인 고가의 모델도 있고, 최근 Truly Ergonomic 같은 경우는 Ctrl, Alt, Shift가 바깥쪽에 있긴 하지만 키맵으로 간단히 가운데 나열된 키와 바꿀 수 있다. 일반적인 키보드의 경우 페달을 장만하는 것도 결코 나쁘지 않은 선택이다. 페달은 왠지 모르게 거부감이 들긴 하지만, 사실 고가의 인체공학 키보드보다 키감 좋은 일반배열 키보드에 페달이 더 나은 선택이다. 예를 들어 C-u C-x C-e 같은 명령을 내릴 때 아무리 키배치가 좋다고 해도 손가락 하나가 Ctrl을 누르고 있다 보면 불편해지는데, 페달에 Ctrl 을 지정했다면 그냥 밟은 상태에서 u x e만 눌러주면 된다. 단축키 편의성이 거의 vi에 근접하는 수준으로 향상되고 한 손으로도 복잡한 명령을 간단히 칠 수 있게 된다.

이맥스 유저들은 vi를 불편하게 모드들이 존재하는 모달편집기라며 비판하는 경우가 많았다. 하지만 실상을 보면 이맥스도 여기서 그다지 자유롭지 못하다. 이맥스의 경우 자주 사용하는 몇몇 명령어들을 제외하면 C-x, C-u, C-c, M-x 등으로 시작하는 것들이 많다. 이는 사실 어쩔 수 없는 것이, 이맥스가 제공하는 명령어는 수천 개 단위인데, 일반적으로 키보드에서 누를 수 있는 키는 100여 개 정도가 전부이고, 그것도 명령어로 사용 가능한 키만 따져보면 몇 개 되지도 않는다. 그러니 저런 식의 조합이 반드시 필요해진다. 문제는 그런 식으로 보면 다른 명령어를 위해 눌러줘야 하는 C-x 같은 키는 사실상 vi에서의 normal mode로 진입하게 해 주고, 명령어 입력 후 insert mode로 자동으로 빠져나가게 해주는 키라고 볼 수 있게 된다. 결국, 이런 관점에서는 vi는 normal mode가 기본값인 모달 편집기, 이맥스는 insert mode가 기본값인 모달 편집기라 해도 할 말 없다.

vi의 성공신화의 중심에는 hjkl 로 커서를 이동하는 것이 있었다. 즉, 커서를 이동하고 다시 타자를 치고 할 때 오른손이 바쁘게 키보드 가장자리의 커서 키와 중심으로 왔다갔다 할 필요가 없다는 것이 큰 장점으로 여겨졌다. 이맥스도 키보드 중심에서 커서 키를 이동하는 방식을 제공하는데... C-n, C-p, C-f, C-b가 그것이다. 보면 알겠지만, 손가락 배열을 전혀 생각하지 않고 '의미' 위주로 만들어진 배치이다.(next, previous, forward, backward) 이맥스 튜토리얼은 이것이 더 편리하다고 강조를 하지만, 실제로는 Ctrl과 조합을 해야 한다는 점, 그리고 키배치가 엉뚱하다는 점 때문에 사용이 오히려 불편하다며 커서 키를 이용하는 사람이 많다.

이맥스는 어찌 보면 단순한 편집기라기보다 편집기의 탈을 쓴 가상 LISP Machine이라 보는 게 타당할 정도로 엄청난 확장성을 가졌다. 여기에 버퍼를 이용하면 이맥스 내에서 거의 모든 것이 가능하다며 하나의 OS 라고 찬양을 받던 시절이 있었고[6], vi 유저들도 이맥스는 '좋은 편집기만 존재했다면 완벽한 OS' 라며 공감을 하였다. 실제로, 편집기 기능에 더하여 웹 브라우징, 메일 클라이언트, 간단한 게임, PIM 등 일반적으로 사용하는 대부분이 제공된다. 하지만, 이는 전적으로 CLI 시절에나 해당되는 것이다. 오늘날의 OS는 대부분 GUI와 멀티태스킹이 지원되는 환경을 제공하여, 편집기를 열고, 옆에 이맥스가 제공하는 것보다 '더 좋은' 웹브라우저를 열고, 이맥스가 제공하는 것보다 '더 좋은' 메일 클라이언트를 열고 간단한 마우스 클릭으로 혹은 윈도우 매니저가 지원할 경우 단축키로 간단히 이동하면서 사용이 가능하다. 덕분에 이런 장점은 빛이 바랬고 기호의 영역으로 전환되었다.

또한, 커맨드라인 위주로 사용하는 올드스쿨 유닉스 유저들에게 있어서도 이게 그리 좋은 평가는 못 받았다. 기본적으로 유닉스에서 제공하는 다수의 셸 명령들을 깡무시하면서 자체적으로 그와 같은 기능을 하는 명령들을 새로이 탑재하고 독자적인 환경을 조성하는 육중한 하나의 소프트웨어로 만드는 것이 유닉스의 기본적인 철학에 크게 위배되었기 때문이다. 실제로 유닉스를 만들었던 벨 연구소의 개척자들인 데니스 리치, 켄 톰슨, 스트로스트럽, 롭 파이크 등은 편집이라는 목적에만 충실하고 나머지는 다른 유닉스 도구에 의존하는 단순한 편집기인 ed, acme, sam 등을 끝까지 선호하였다. 이에 대해 셸과 함께 딸려오는 수많은 유닉스 툴 역시 덩치가 큰 건 이맥스와 마찬가지고 선택의 문제라고 보는 주장도 있긴 하다.진짜 OS 와 경쟁을 하고 앉았다.

Emacs는 학습 곡선의 초반 그래프 기울기가 완만하다고 할 수 있다. 오늘날 이맥스가 뒤쳐지게 된 가장 큰 이유 중 하나이다. 굳이 접근성이 높은 다른 위지위그 편집기와 비교할 것도 없이, vi/vim과 비교해 봐도 Emacs보다는 vi/vim 유저가 훨씬 많다. 그 가장 큰 이유는, 이맥스는 제대로 다루기가 매우 힘든 편집기이기 때문이다. 반면에 해커들에겐 가장 인기 있는 편집기이기도 한데, 강력함이 이유라기보다는 단지 해커 특유의 입맛에 맞게 뜯어고치기가 되다 보니 인기가 좋은 것. 리눅스 역시 같은 이유로 인기가 높다. vi/vim도 난해하다는 평가를 주로 듣지만, 자주 쓰는 몇십개 정도의 키 스트로크만 익숙해져도 웬만한 타 편집기의 생산성을 크게 앞서갈 수 있기 때문에, 공들인 대가가 상당히 빠르게 찾아오는 편이다. 하지만 이맥스의 경우 Elisp이라는 하나의 프로그래밍 언어에 어느 정도 익숙해져 자신에게 적합한 세팅/기능을 만들어 적용하는 게 가능해지기 전까지는 vi/vim뿐만 아니라 여타 편집기에 비해서도 뒤진다. Elisp은 단순히 이맥스 커스터마이징에 사용되는 문법 정도가 아니라 진짜 프로그래밍 언어이다. 그것도 난해하다고 유명한 Lisp family. 게다가 유연성은 Elisp보다 떨어지지만, vi/vim에서 제공하는 빌트인 함수만으로도 편집으로만 제한하면 상당히 많은 것들이 가능하기 때문에, 굳이 일반 프로그래머들이 생소한 Elisp으로 바닥부터 짜야 할 이유가 별로 없다.

약간 과장해서 vim script가 bash라면, Elisp은 C 언어 정도에 해당된다. C 언어는 물론 bash로 하지 못하는 많은 것들이 가능하지만, 일반적인 셸 작업은 bash로 못할 것이 없으며, bash 몇 줄로 처리 가능한 작업이 C 언어로는 리얼 프로젝트가 돼버린다. 물론, 비교를 위해 C 언어를 이야기한 것일 뿐 Elisp 자체도 상당한 하이레벨 언어고 vi보다 훨씬 많은 내장 함수를 제공하기때문에 생산성은 C보다 훨씬 높다. Elisp으로는 vim script로 구현하기 힘들거나 불가능한 터미널 에뮬레이터라든가, 멀티미디어, 게임, 메일 클라이언트 기타 등등이 다 가능하지만, 정작 순수 편집기 기능으로 보면 vi/vim과 이맥스가 큰 차이가 없다. 또한 이맥스에서 복잡한 기능들을 구현한다고 해 봤자, 잘해야 기존 IDE 와 비슷한 정도. 즉, 단순한 편집기 기능에는 vi/vim과 비슷하거나 조작성 문제로 비효율적이고, 리팩토링 등의 복잡한 기능을 비교하면 IDE에 비해 메리트가 적어 난해하기만 해서 중간에 끼인 상황이다.

어쨌든 이러한 난해함 때문에 도전했다가 포기하는 유저가 대부분이며 도전할 엄두조차 내지 못하는 사람들은 할아버지 프로그래머들이나 애용한다며 비난한다. 과거 유닉스로 이맥스를 가장 먼저 포팅했던 제임스 고슬링조차도 시대에 뒤쳐졌다며 이맥스를 깠다. 자사 IDE인 넷빈즈 쓰라는 이야기이긴 했지만.

이러한 난해함에도 불구하고 사용하는 메리트를 끄집어내어 본다면, Gnuplot이나 LaTeX, Octave용 패키지가 잘 지원되고 특히 LISP 계열 언어를 개발하는 데 막강한 편리성을 제공한다는 점이다. nREPL을 통해 별도로 실행되는 Lisp 프로세스와 통신하며 즉석에서 코드를 주입하여 실행해 결과를 보면서 코딩하고 디버그를 할 수 있다. 물론 다른 편집기나 개발환경에서도 이러한 것을 지원해 주기는 하지만 Emacs만큼 편리하고 직관적인 환경을 제공하는 툴은 아직까지 찾기 힘들다.

Common lisp과 비슷하지만, 아무래도 좀 구형이라 Common lisp에 비해 기능은 상당히 떨어진다. 그래서, Elisp을 대체하자는 소리도 많이 나왔고 스톨만은 Guile이라는 언어로 대체할 생각이 있다는 이야기도 했다. Guile은 Scheme family라 같은 lisp이긴 하지만, Common lisp 쪽과 더 유사한 Elisp과는 차이가 좀 있다. Common lisp이 오만가지 기능을 다 때려 넣은 C++라면, Scheme은 핵심적인 부분만 컴팩트하게 유지하는 C 언어로 비교할 수 있다. 물론, 예전 이야기이고 R6RS 부터는 Scheme도 상당히 육중해졌다. 하지만 저게 이미 10년도 더 전에 나온 소리인데 아직 구현이 안됐다. 물론 Elisp 코드가 수십만줄 이상이라 간단히 가능한 것은 아니지만 대체를 위한 활동 자체가 미미하다. 결국 바닥부터 새로 만들기보다 Elisp을 Guile 내에 임베딩하는 식으로 얼마 전 GSoC에서 마이너 이슈만 좀 있고 거의 다 끝난듯한 뉘앙스를 풍겼는데 GSoC 이후로는 다시 침체인 듯.

사용법을 알고 싶다면 여기저기 방문해 보자.

이런 패키지도 참고해 보자. prelude

Vim에 더 익숙하지만 특별한 이유 때문에 이맥스를 사용하고자 한다면 Vim 키바인딩이 기본으로 설정되어있는 스페이스맥스도 나쁘지 않은 선택이다. spacemacs

보통 Unix 기반의 운영 체제들은 기본적으로 탑재하고 있거나 손쉽게 패키지를 다운받을 수 있다.