Emacs 배우려다 실패하고 다른 쪽으로(e.g. vim)으로 가신 분들.

cinsk의 이미지

얼마전에 emacs vs. vi이란 글이 이 게시판에 올라왔었는데, 제 기억이 맞다면 "Emacs를 배우려고 했는데 어려워서... 지금은 vim을 잘 쓰고 있습니다."라는 글이 많이 올라온 것 같습니다.

다름이 아니고 구체적으로 어떤 점이 emacs가 배우기 어렵거나 쓰기 어렵다고 생각하셨나요? 물론 vim과 같은 다른 에디터가 훨씬 좋아서..가 이유였다면 상관없겠지만, emacs의 어떤 점이 좋지 않거나 힘들어서 다른 editor를 선택하셨다면, 그 이유를 알려 주셨으면 합니다.

나중에 emacs tutorial이나 기타 guideline을 쓸까 하고 생각하고 있는데 많은 도움이 될 것 같습니다. 단순히 선호도가 아닌, emacs의 특정 부분이 마음에 들지 않으셨다면 그 이유를 자세히 알려주시면 고맙겠습니다.

File attachments: 
첨부파일 크기
Image icon emacs-22.png57.56 KB
Image icon EmacsXftMonacoFont.png136.82 KB
zeon의 이미지

저는 vi(m)이 불편해서 emacs 씁니다.
-.-;

여친이 길르는 용..

alee의 이미지

일단 입맛에 맞게 고치는 것이 어렵습니다.
보통 글꼴이라든가 기타 환경들이 자신이 원하는 대로 갖춰져야 비로소 그 에디터를 써 볼 마음이 생기게 마련인데, Emacs는 Emacs에 “상당히” 익숙해지기 전에는 설정을 원하는 대로 바꾸기 어렵습니다.

물론 남이 만들어 놓은 설정 파일을 가져다가 고쳐 쓸 수도 있겠지만, 그것만으로는 많이 부족합니다. vim 같은 경우는 help만 잘 들여다 보면 원하는대로 요리해서 사용할 수 있습니다. 그런데 Emacs는 “도움말이 너무 방대해서” 자신이 원하는 부분을 찾아서 고치는 것이 상당히 어렵습니다. 게다가 “정말 자신이 원하는 대로” 요리하기 위해서는 lisp을 어느 정도 알아야 합니다.

또 한 가지 어려운 점은 “새끼 손가락”이 너무 힘이 든다는 점입니다.
CapsLock과 Ctrl의 위치를 바꿔서 써도 어차피 왼손 새끼손가락이 혹사당하는 것은 마찬가지더군요. vim의 경우 일단 Esc를 눌러서 모드 전환을 하면 명령어들이 대부분 키 하나지만, Emacs에서의 명령은 대부분 Ctrl이나 Mod와 동시에 눌러야 하기 때문에 손이 더 쉽게 피로해집니다.

익명 사용자의 이미지

저도 오히려 emacs가 쉽더군요. vi가 어려워서 pico(nano)만 쓰고 있었는데 emacs 쪽이 더 직관적이라는 느낌입니다. (나중에 익숙해지고 나서의 생산성이나 효율은 제쳐두고, 제로상태에서 처음 접했을 때 이야기)

아무래도 ctrl-단축키가 익숙하다면(GUI 환경에 익숙하다면) emacs 쪽이 쉬운 듯...

kwon37xi의 이미지

저 같은경우에는 한동안 Emacs 에 대한 동경으로 (VI 보다 더 뽀대나 보이더군요) Emacs 책도 사서 한 1년정도 썼었는데, 결국엔 포기했습니다.
(게으름이 가장 큰 원인이겠지만..)

첫째는 설정파일이 직관적이지 못하다는 거구요,
둘째는 그노무 Ctrl 키... ^^
셋째는 무겁다는 점인데, 사실 이건 그다지 큰 이유는 아니었습니다.

첫째 이유, 설정 파일... 제일 문제였습니다.

요즘은 모든 플랫폼에서 (G)VIM과 jEdit를 사용하고 있습니다.

jEdit는 아마 약간은 부족하겠지만, 자바로 만들어진 Emacs 에 필적하는 에디터가 아닐까 싶습니다. 사용법은 뭐 당연히 더 쉽습니다. ^^

nohmad의 이미지

저도 번번이 좌절한 케이스인데, 일단 한글을 쓸 수 있도록 세팅하는 것도 어려웠고, 키맵 또한 쉽게 익숙해지지 않았습니다. 그리고 제 머리의 용량이 좀 떨어져서 단축키 조합을 외우는데 vim이나 다른 편집기들에 비해 2배의 기억용량을 요구하는 것을 수용하기 어려웠다는 것도 큰 이유일 것 같습니다. 음.. 기억용량이 떨어지는 문제는 부모님과 의논해야 할 문제려나요? :cry:

creativeidler의 이미지

Quote:
기억용량이 떨어지는 문제는 부모님과 의논해야 할 문제려나요?

많은 기억 용량을 필요로 하는 툴이라는 것은 그 자체로 단점일 수도 있겠죠.
saxboy의 이미지

아유. 저도 가끔은 emacs쓴답니다. viper 라서 문제이긴하지만.... :oops:

kane의 이미지

제가 처음 emacs를 사용하려고 했을 때 가장 어려웠던 점은 emacs를 종료시킬 수 없었다는 겁니다. -_-; 파일 오픈 같은 건 어림도 없었죠. 이건 어찌어찌 해결했습니다만.

두번째 어려움은 vi와 다르다는 점이었습니다. vi도 처음 배울때는 상당이 이상한 에디터였지만, 이미 vi에 익숙한 상태에서는 emacs가 불편하게 느껴졌죠. 뭐 이건 어떻게 할 수 있는 문제는 아닌 것 같습니다. emacs를 쓰고 싶어하는 마음만이 이 문제의 해결책이 아닐까요. 저는 RMS가 emacs를 shell 대신 쓴다든가, customizing이 굉장히 유연하다든가, 심지어 elisp으로 '프로그래밍'할 수 있다든가 하는 점들에 마음이 끌려서 다시 시도했었죠. 다른 분들은 vi 잘 쓰고 있는데 굳이 emacs를 써야할 이유가 없다고 생각하실지도 모르겠습니다.

셋째 한글 문제는 다행스럽게도 주변 분들의 도움으로 쉽게 해결했습니다. 요새는 설정 방법만 아시면 누구나 쉽게 사용하실 수 있을 겁니다. 설정도 매우 간단합니다. (기본으로 제공하는 거나 다름 없죠.)

넷째 Ctrl의 압박은 아직도 좀 남아 있습니다. 저는 alt, ctrl을 양쪽으로 써서 그 압박을 많이 덜었습니다만, ctrl의 압박을 이겨낼 방도가 필요하겠네요.

다섯째 설정 파일이 이상하게 생긴 건 저한테 오히려 매력이었습니다. 프로그래밍 가능한 에디터(?)라니 말이죠. ^^; 설정은 elisp을 알든 모르든 customize 명령을 통해서 하는게 좋은 것 같습니다. 불가피하게 설정 파일을 손수 수정해줘야 하는 경우가 생길 수는 있지만 이건 나중 얘기니.. ㅎㅎ

여섯째로 명령어가 많아서 단축키도 덩달아 많아져 외우기 힘들다는 분도 계시는데, 전 단축키보다 명령어를 먼저 외우는 편입니다. 물론 명령어를 정확하게 외우는 건 매우 힘들고 M-x 후에 tab completion에 많이 의존합니다. 명령어가 키에 맵핑되어 있을 경우에는 해당 키를 알려주니 그걸 보면서 키를 외우기도 했죠. 뭐 단축키를 외우는 문제는 얼마나 익숙해지는가의 문제라고 봅니다. 그리고 GNU Emacs Manual 출력해서 제본해놓고 찾아보면서 하면 쉬워집니다. ^^;

일곱째로 내장 도움말을 보는게 힘들었습니다. info 시스템에 익숙하지 않아서 도움말이 있어도 볼 생각을 못 했죠. 매뉴얼이나 구글로 때우는 일이 많았습니다. 그리고 C-h k, C-h f 같은 help 시스템을 사용하기까지도 시간이 좀 걸렸었죠.

뭐 이러니 저러니해도 emacs를 포기하는 가장 큰 이유는 vi와 다르기 때문이라고 생각합니다. 사실 다른 에디터들과 비교해보면 emacs가 정상이고 vi가 비정상으로 보입니다만, vi에 익숙해지면 다른 에디터들이 비정상으로 보이죠. 게다가 갑자기 안쓰던 ctrl 키를 마구 써대니 "이게 뭔가.." 싶을지도 모르겠네요.
vi 사용자가 emacs에 매력을 느끼도록 하려면 역시 vi에 없는 걸 보여주는게 좋지 싶습니다. indent-region, comment-region(or comment-dwim), tab indent 등의 편리한 명령어라든가 speedbar 같은 뽀대나는 프로그램(?), gdb나 grep 등의 출력 결과와의 연동(?) 기능 등을 보여주면 한 번 더 도전해보고 싶어지지 않을까요. (예전에는 vi에서 화면분할도 지원해주지 않았었는데...)
그리고 에디터로써의 emacs 뿐만 아니라 작업 환경으로의 emacs를 보여주면 미끼에 걸린 고기를 확실히 낚을 수 있지 않을까요. ㅋㅋ gnus 때문에 emacs를 쓸 수 밖에 없다던 사람도 있으니까요. ^^; 저도 dired 등을 즐겨쓰고 있습니다. (한 때 diary를 사용하던 때도 있었죠. -_-; )

yuni의 이미지

이멕스의 단축키 외울만 합니다. 아래한글 외울때 처럼 이렇게 하는 것이 더 시간을 줄여 준다고 생각하면 당연히 사용자는 수용을 하겠지요. 더구나, 한번 익혀 두면 열 에디터 안 부럽게 쭈욱 쓸 수 있으면서 익숙해 지면 질 수록 편리하다라는 생각이 들면 불만은 즐거움이 될겁니다.

문제는 설정인데, 아직도 설정하는 것이 어렵습니다. 최근에 겨우 글꼴과 화면배색이 마음에 드는 것을 골랐는데 이러고 나니 이멕스를 더욱 더 가까이 하게 되었습니다.
책을 보아도 설정에 관한 부분은 좀 미진한 것이 아닌가 하는 생각이 듭니다. 그렇다고 새로운 언어를 파기에는 좀 아깝기도 하고.

좋은 가이드라인이나 튜토리얼을 기대해 봅니다. 화이팅~ :P

==========================
부양가족은 많은데, 시절은 왜 이리 꿀꿀할까요?
=====================
"지금하는 일을 꼭 완수하자."

익명 사용자의 이미지

처음 배우는 유저라면 emacs가 차라리 더 쉽지 않을까 싶군요. 전 물론 vi유저라서 control키를 눌러야 하는 압박감때문에 emacs를 배우지 못했습니다만... ^^;;

vi를 첨 배울때는 그 강력한 기능을 거의 이해하지 못하고, 파일 읽기, 파일 저장하기, 끝내기 등등의 경우 다섯 손가락 안에 드는 기능만 사용했습니다. (ESC시도때도 없이 누르고, x와 커서 hjkl키 누르고 등등)

나중에 좀 익숙해진 후에 기타 다른 명령들 (/,? :%s 등등)을 익히기 시작했죠.

"emacs 첨 시작하기"같은 매뉴얼이 있으면 합니다 (이미 있는데도 모르는지도..)

익명 사용자의 이미지

몇번 시도했다가 포기 하고 언제가는 다시시도하려고하고 있는중입니다.
설정이 너무 너무 어려워요. 원하는 글꼴하나 설정하기가 힘들더군요.
지원되는 폰트가 있고 안되는 폰트가 있나요?
어째든 쉽지 않네요....

단축키들이야 숙달을 요하는 것이고 하니....

crimsoncream의 이미지

아주 잘 준비된 튜토리얼이 있습니다. 요즘 배포판의 X 환경이시면 별다른 설정없이 한글로 나올꺼구요.
M-x help-with-tutorial
근데 vi와 emacs 모두를 꽤 오래 써왔다고 생각했는데 몇가지 이해가 안가는 말씀들이 있군요.

예를 들어 emacs 명령의 경우 C-x와 M-x의 역할만 이해하고 몇가지 기본적인 이동, 파일관리, 종료 명령만 외우면 된다고 생각하는데요. 다른 툴 특히 vi에 비해서 특별히 어렵지는 않다고 생각합니다. vi도 사실 모드에 대한 이해와 hjkl 만 이해하면 쓰는데는 큰 문제 없다고 생각하고요. 세부적인 명령어는 그때그때 찾아보다가 익으면 외우는 거지 따로 외울 필요는 없으므로 찾아볼 정보가 없다라면 문제겠지만 vi, emacs 공히 인터넷에 널린게 튜토리얼이라고 보는데요.

그리고 ctrl 키의 경우 제 타이핑 스타일이 워낙에 느긋해서 그런지 몰라도 특별히 부담이 된다고 느낀 적이 없거든요? esc를 왼손 중지로 누르는데 이게 오히려 불편하다고 느끼고 횟수도 vi 쓸때 esc 누르는 횟수가 emacs 쓸때 ctrl 누르는 횟수보다 오히려 많지 않나 싶은데 아닌가요?

그리고 HHk의 경우 emacs 유저에게 오히려 더 환영받지 않을까 싶은데요. ctrl의 위치나 큼직만한 alt도 그렇고 esc가 가까운 것도 emacs 유저입장에서 아주 반갑습니다. 저갈은 경우는 M-x 할때 엄지를 안쪽으로 구부리거나 손을 이동하늘 걸 안좋아해서 esc가 가까우면 esc를 이용해서 M-x를 쓰거든요.

제 생각엔 emacs를 굳이 써야할 이유가 없으므로 굳이 안쓰는 이유를 댈 필요는 없지만 쓰고 싶은데 이래서 안쓴다라고 하기에 여태까지 나온 이유들은 좀 약하군요 :)

Anonymous wrote:
처음 배우는 유저라면 emacs가 차라리 더 쉽지 않을까 싶군요. 전 물론 vi유저라서 control키를 눌러야 하는 압박감때문에 emacs를 배우지 못했습니다만... ^^;;

vi를 첨 배울때는 그 강력한 기능을 거의 이해하지 못하고, 파일 읽기, 파일 저장하기, 끝내기 등등의 경우 다섯 손가락 안에 드는 기능만 사용했습니다. (ESC시도때도 없이 누르고, x와 커서 hjkl키 누르고 등등)

나중에 좀 익숙해진 후에 기타 다른 명령들 (/,? :%s 등등)을 익히기 시작했죠.

"emacs 첨 시작하기"같은 매뉴얼이 있으면 합니다 (이미 있는데도 모르는지도..)

오늘 우리는 동지를 땅에 묻었습니다. 그러나 땅은 이제 우리들의 것입니다.
아직도 우리의 적은 강합니다. 그러나 우리는 그들보다 많습니다.
항상 많을 것입니다.

satyrs의 이미지

전 현재 vi를 행복하게 쓰고 있습니다.

그런데 emacs를 배워야 할 필요가 있습니다.

R이란 통계패키지를 자주 쓰는데 Emacs Speaks Statistics 라고

emacs로는 R을 매우 편하게 쓸 수 있다고 하더군요.

써볼려고 보니 우선 hjkl이 아닌 방법으로 커서 이동하는 것 같아서 이것이 가능할까 걱정이 되고...

그리고 무었보다도 emacs가 하나가 아니더군요. xemacs, gnu emacs, 뭘로 시작해야 하는지..^^

cinsk의 이미지

지금까지 나온 의견을 종합해보면 다음과 같습니다:

첫째. 설정을 바꾸기가 힘들다. 설정 파일을 바꾸기 위해서는 약간의 elisp을 알아야 하기 때문에 어려울 수도 있고, 폰트 설정과 같은 부분이 잘 설명되어 있는 부분이 부족하다. 물론 info manual에 자세히 나와 있지만 오히려 정보의 양이 너무 많아서 힘들다.. 이 말에는 공감이 갑니다. 아직 kldp에 emacs start-up script에 관한 내용이 부족한 것, 인정해야겠습니다. 시간이 나면 곧 올리겠습니다. :)

둘째. control key를 자주 쓰기 때문에 힘들다.. 새끼 손가락이 힘이 든다고 하는데, 솔직히 제 의견을 말하면, 왜 힘든지 모르겠습니다. 글을 쓰신 분들이 control의 위치를 [tab] 아래로 바꾸었다고 하셨는데, 그렇다면 힘들 이유가 전혀 없다는게 제 개인적인 생각이거든요.. meta로 쓰이는 alt의 경우, M-x로 시작하는 명령을 위한 것인데, control로 binding되어 있는 key에 비해 쓰이는 빈도가 낮기 때문에 큰 무리가 없을 것이라고 생각하는데... 글쎄요.. 어쨌든 오히려 emacs key binding이 더 쉽다는 분도 있으니, 주관적인 경향이 많은 것 같아 제외하겠습니다.

세째. info system에 익숙치 않다.. 이것은 어찌할 도리가 없을 것 같습니다. glibc나 gcc등 대부분 필수 utility들의 manual이 전부 info page로 되어 있다보니, (emacs도 마찬가지) info(1) 명령에 익숙해져야 하는 것은, GNU tool을 쓰시는 분들에게는 필수라고 생각합니다. 따로 terminal을 띄우지 않고, emacs 내부에서 info를 처리할 수 있는 것은 커다란 장점이라고 생각하는데, 오히려 이것이 불편하다고 하시면.. :cry: info 형태로 된 manual이 불편하다고 생각하시면 info(1) 명령 자체를 싫어하신다는 말인데, 그럼 GNU tool의 도움말을 어떻게 보시는지 궁금합니다.

네째. vi랑 다르기 때문이다고 하신 분이 있는데.. :shock: 이 말은 너무나 주관적인 것이라고 생각하기 때문에 제외하겠습니다.

다섯째. 단축키 조합이 어렵다는 말도 주관적이긴 하지만, 그나마 조금 현실성이 있어보입니다. 그런데, emacs의 단축키는 emacs에서만 쓰는 것이 아니라 웬만한 gnome, gtk application이나, bash의 command-line (좀 더 정확히 말해서 readline library를 쓰는 모든 app), info 명령 등에서 모두 동일한 형태의 단축키를 사용합니다. emacs의 단축키가 어렵다고 생각하시는 분들은 다른 application에서는 단축키를 쓰지 않으시는 것은 아닐텐데.. 어떻게 사용하시는지요? 간단히 예를 들어, 다음 단축키들은 emacs에서 쓰일 뿐만 아니라 대부분 다른 application에서도 많이 쓰입니다:

  • C-n emacs(커서를 아래줄로) bash(history에서 다음 명령), info(커서를 아래줄로), python(history에서 다음 명령), GtkTextView (아래 줄)
  • C-p emacs(커서를 윗줄로) bash(history에서 윗 명령), info(커서를 윗줄로), python(history에서 윗 명령), GtkTextView (윗 줄)
  • C-e emacs(줄의 맨 끝), bash (줄의 맨 끝), info (줄의 맨 끝), python (줄의 맨 끝), GtkEntry/GtkTextView widget (줄의 맨 끝)
  • C-a emacs(줄의 맨 처음), bash (줄의 맨 처음), info (줄의 맨 처음), python (줄의 맨 처음), GtkEntry/GtkTextView widget(줄의 맨 처음)
  • C-d emacs(한글자 지움), bash (한 글자 지움), python (한글자 지움), GtkEntry/GtkTextView widget (한글자 지움)
  • C-k emacs (한 줄 지움), bash (한 줄 지움), python (한 줄 지움), GtkEntry/GtkTextView widget (한 줄 지움)

  • M-f emacs (다음 단어), bash (다음 단어), info (다음 단어), python (다음 단어)
  • M-b emacs (이전 단어), bash (이전 단어), info (이전 단어), python (이전 단어)
  • M-d emacs (한 단어지움), bash (한 단어 지움), python (한 단어 지움)

  • C-s emacs (아래로 검색), info (아래로 검색)
  • C-r emacs(위로 검색), info (위로 검색), bash (history에서 위로 검색)

예를 들어서, firefox에서 C-l을 누르면 커서가 주소창으로 이동합니다. 그 다음 C-a를 누르면 커서가 주소창의 맨 처음으로 이동하고, 그 다음 C-k를 누르면 주소창에 있는 주소를 지워줍니다.

또 bash에서 명령을 어느 정도 친 다음, C-a를 누르면 커서가 친 명령의 맨 처음으로 이동하고 C-k를 누르면 지금까지 친 내용을 지워줍니다.

이런 식으로, emacs key binding이 쓰이는 곳은 매우 많습니다. 따라서 일단 한 번 외워두면, 다른 application을 쓰더라도 얼마든지 활용할 수 있기 때문에 reusability가 높다?고 할 수 있습니다.

몇가지 정리를 해 보았는데, 슬프게도? emacs를 쓰지 않는 원인이 대부분 주관적이라는 게 제 의견입니다. 객관적인 원인이 많다면, 그나마 문제 해결을 할 수 있지만, 주관적인 의견이 많다면, 어찌할 도리가 없습니다.

제가 보기에는 그나마 해결할 수 있는 것은, 설정 파일에 관한 것인것 같습니다. 언제 시간이 나면 설정 파일 예제와 꾸미는 법?에 대해서 글을 써봐야겠습니다. 다른 분들도 환영합니다. ;-) 아마도 kldp wiki의 응용 프로그램 란에 써야 할 것 같군요.

또 다른 의견 있으시면 올리 주시기 바랍니다.

[/]
Prentice의 이미지

C-h t의 튜토리얼이 너무 장황합니다.

처음에 vim을 시작했을 때 vimtutor를 한번 돌리고 나면, 전부는 기억이 안나더라도 유용하게 써먹을 수 있는 부분이 많았지만, emacs의 튜토리얼의 경우 같은 시간을 투자할 경우 건질 수 있는 내용이 좀 적었다는 느낌이 듭니다.

어쩌면 착각일지도 모르지만, vimtutor는 (기억력이 나빠서) 심심할 때 마다 돌렸던 적이 있지만 이맥스 튜토리얼은 하다보면 지쳤던 것 같습니다.

"조금만 참으면 주옥같은 기능이 손에" vs "시간을 투자해도 왜 건지는 게 적지"

Prentice의 이미지

공자님 앞에서 문자 쓰는 것 같지만 용기내어 적어봅니다.

참고로 emacs에서는 단축키 대신에 명령을 tab-completion을 써서 입력할 수 있다고 알고 있습니다.

단축키가 외우기 힘드시다면 단축키의 대안으로 어느 정도는 유용하리라 생각합니다.

김도현의 이미지

예전에 KTUG에 이런 글을 올린 적이 있습니다.

Quote:
Emacs 와 Vim. 편집기界의 양대 산맥. 그 중에 지금은 Vim을 많이 쓰고 있다. 거의 끼고 산다고 보면 된다. TeX뿐 만 아니라 모든 텍스트파일 편집을 이걸로 해결한다. 예전엔 Emacs를 주로 썼었다. 그런데 UTF-8환경으로 옮아오고부터는 Emacs가 불편하게 되었다. 아직 내부적으로 유니코드 지원이 완전히 이루어지지 못하고 있기 때문이다. 이를테면 “ㅤㄸㅗㅁ”이라는 글자를 Emacs는 화면에 표시해주지 못한다. mule-ucs를 얹으면 한글도 유니코드로 입출력할 수 있지만 아쉽게도 KSC5601의 범위 내에서만 가능한 것이다. AUCTeX이라는 매혹적인 환경을 못내 뿌리치고 Vim을 주로 쓰게 된 것은 Vim의 발빠른 행보와 Emacs의 상대적 지체현상이 원인이었다(물론 다음 버전 이맥스는 유니코드를 완전히 지원할 것이므로 그때 가면 뭘 쓰고 있을지 나도 모른다 ). 그리하여 본격적으로 쓰게 된 Vim은 AUCTeX환경에는 아무래도 못 미치지만 차츰 익숙해지고 단축키도 몇가지 정의해두고 보니 그런대로 Emacs가 크게 부럽지 않을 지경까지 이르게 되었다.

물론 평소 “ㅤㄸㅗㅁ” 같은 글자를 칠 일이 거의 없지만 당시 TeX에서 한글 utf-8 인코딩 지원한다고 법석을 떨던 때라 그리 되었습니다. 이 문제는 어떻게 생각하시는지, 혹은 이미 해결된 문제인데 저만 모르고 있는건지 고견을 듣고 싶습니다.
익명 사용자의 이미지

cinsk wrote:

첫째. 설정을 바꾸기가 힘들다. 설정 파일을 바꾸기 위해서는 약간의 elisp을 알아야 하기 때문에 어려울 수도 있고, 폰트 설정과 같은 부분이 잘 설명되어 있는 부분이 부족하다. 물론 info manual에 자세히 나와 있지만 오히려 정보의 양이 너무 많아서 힘들다.. 이 말에는 공감이 갑니다. 아직 kldp에 emacs start-up script에 관한 내용이 부족한 것, 인정해야겠습니다. 시간이 나면 곧 올리겠습니다. :)

쉽게쉽게 올려주세요... 부탁드리겠습니다. :)
vim상당히 잘쓰고 있지만 emacs써보고 싶은 욕망이 꿈틀꿈틀 설정에서 좌절좌절...
기본 설정된 한글 폰트 않좋아서 바꾸고 싶은데 안되니 emacs 쓰기 시로시로 그래도 배경색이랑 syntax랑은 설정해서 써봤어요... :)

익명 사용자의 이미지

이맥스 관심은 가는 데 이미 vimpire한테 물린지라
써볼 엄두도 안나는 군요.

몇번 시도하려고 이맥스 가동시켰다가 끌 줄 몰라서
슬립시켜서 나온다음에 kill해 버리곤 하죠 =_-;;;

저는 개인적으로 튜토리얼 맨 처음에
동기부여를 강하게, 인상깊게 해 주시면 조금 따라가기 어렵더라도
열심히 따라하지 않을까 합니다.

vim에서 못하는 기능을 보여준다던지..
vim은 편집기이고 emacs는 개발 통합환경(? ) 이라서
나와바리가 다르다는 것을 보여준다던지..

개인적으로는 동기부여부분 뿐만 아니라 설명 부분들도
스크린샷을 적당히 첨부해 가면서 해 주시면 감사하겠습니다.

C-x라는건 컨트롤+x라는 것 같은데 M-x같은거에서 M은 뭐죠? -_-

kane의 이미지

cinsk wrote:
세째. info system에 익숙치 않다.. 이것은 어찌할 도리가 없을 것 같습니다. glibc나 gcc등 대부분 필수 utility들의 manual이 전부 info page로 되어 있다보니, (emacs도 마찬가지) info(1) 명령에 익숙해져야 하는 것은, GNU tool을 쓰시는 분들에게는 필수라고 생각합니다. 따로 terminal을 띄우지 않고, emacs 내부에서 info를 처리할 수 있는 것은 커다란 장점이라고 생각하는데, 오히려 이것이 불편하다고 하시면.. :cry: info 형태로 된 manual이 불편하다고 생각하시면 info(1) 명령 자체를 싫어하신다는 말인데, 그럼 GNU tool의 도움말을 어떻게 보시는지 궁금합니다.

man과 web으로 때웁니다. - -;
info가 싫은게 아니라 man+구글에 익숙해서 info를 잘 사용하지 않습니다.
다른 분들은 info 많이 사용하시나요? 전 주변에서 info 사용하는 모습을 본 적이 없어서..
kane의 이미지

_김상욱 wrote:
C-x라는건 컨트롤+x라는 것 같은데 M-x같은거에서 M은 뭐죠? -_-

Meta라고 쓰고 Alt라고 읽습니다. :wink:
jj의 이미지

cinsk님의 행동에 용기를 내서, 마지막으로 한번 더 도전해보도록 하지요. 기도해주세요. :-)

--
Life is short. damn short...

아르아의 이미지

Emacs는 다용도로 쓸 수 있고, 기능도 방대한듯 한데(vi도 방대하지만요)
대부분의 emacs메뉴얼이나 책들도 설명이 방대해서
처음 접하는 사람 입장에서는 좀 정신없고 어려운것 같습니다.

예를들어 vi는 간단한 파일을 작성하려면
"vi (프로그램 시작)
i -> 내용 입력 -> esc -> wq엔터 치세요"
하면 끝나죠. 여기에 더해 단축키 같은것을 땡길때마다 하나씩 배워나가면 되는데(제가 그랬습니다)
반면에 emacs는 버퍼, 버퍼간 이동, 버퍼저장, 파일 여닫기, 저장하기?
처음부터 익혀야 할것이 좀 많고 단축키도 vi보다 좀 길고 말이죠(C-c C-k 같이)
게다가 버퍼라는 개념에 익숙해지기 전까지는
emacs의 장점을 제대로 느끼기 힘든듯 합니다.

다시말해서 emacs가 정말 좋은 프로그램일지는 몰라도
편집기능만 대충 알면 되는 vi에 비해서
emacs는 편집기능 + 버퍼(+추가 기능들) 를 대충 알아야 하기에
진입장벽이 더 높은듯 하다는거죠

기본적인 사용법을 후딱 익힌 후, 유용한 기능들은 하나씩 간간히 배우길 원하는데
emacs는 그러기 힘들더군요.
그런식으로 설명해주는 문서를 제가 못봐서인지도 모르겠습니다.

하지만 cinsk님의 글을 보니 많은 도움이 될듯 합니다 :D

nohmad의 이미지

cinsk wrote:
다섯째. 단축키 조합이 어렵다는 말도 주관적이긴 하지만, 그나마 조금 현실성이 있어보입니다. 그런데, emacs의 단축키는 emacs에서만 쓰는 것이 아니라 웬만한 gnome, gtk application이나, bash의 command-line (좀 더 정확히 말해서 readline library를 쓰는 모든 app), info 명령 등에서 모두 동일한 형태의 단축키를 사용합니다. emacs의 단축키가 어렵다고 생각하시는 분들은 다른 application에서는 단축키를 쓰지 않으시는 것은 아닐텐데.. 어떻게 사용하시는지요? 간단히 예를 들어, 다음 단축키들은 emacs에서 쓰일 뿐만 아니라 대부분 다른 application에서도 많이 쓰입니다:

readline의 emacs 키바인딩은 <C-a>와 <C-e>, <M-f>, <M-b> 정도만 외웁니다. 그런데 윈도의 터미널들은 대부분 <Alt> 키를 막아버리고 있어서, <Esc-f>, <Esc-b> 식으로 눌러야 하는데 이거 좀 귀찮죠. 거기다 <C-a>는 screen 하고 충돌이 나기 때문에 역시 또 사용 불가.

저는 readline의 기본 키바인딩을 vi로 바꿔서 사용합니다. screen 단축키와 readline에서 vi 모드에 익숙한 저에게는 emacs 키바인딩은 너무 불편하기 짝이 없습니다. screen을 몰랐다면, 저는 예전에 emacs로 옮겨갔을 것 같습니다. emacs에 비하면 확실히 떨어지는 vim 버퍼 모드의 단점을 screen이 모두 커버해주는 바람에 emacs로 옮겨가기가 쉽지 않습니다. ;-)

irondog의 이미지

전 VIM을 쓰다가 C언어 분석 기능을 좀 비주얼하게 쓰고 싶어서 LISP까지 배우면서 emacs에 도전했던 사람인데요. 3개월 정도하다가 포기 했습니다.

일단 윈도에서 한글이 안되는게 첫번째 문제였죠.
XEmacs인가요? 그걸 썼었는데 국내 이용자가 얼마 없었는지 한글화가 안되어 있더군요. 입력 시스템이 따로 있었던 것으로 기억하는데, 암튼 짜증나서 포기했죠.

그리고 두분째는 제 경우에만 해당되는 것인지 모르겠는데 잘 죽더군요. 어이가 없었죠. -.-;;

윈도 환경은 그렇다치더라도 터미널 환경이라면 왜 EMacs를 쓰는지 도저히 이해가 안가던데요. 편집기 상에서 디버깅 하는거 말고 특별히 더 좋은 점을 발견 할 수가 없었습니다. LISP언어도 좀 짜증났고요.

만일 cinsk님께서 도와 주실 수 있다면... 다시한번 도전해 보고 싶군요. ㅋㅋㅋ

antibug의 이미지

검은해 wrote:

"조금만 참으면 주옥같은 기능이 손에" vs "시간을 투자해도 왜 건지는 게 적지"

굉장히 중요한 얘기인것 같습니다.
음... 저는 거의 모든 일을 윈도에서 하고 있습니다마,
GNU에 대한 짝사랑(-.-)으로 그럭저럭 cygwin으로나마 몇가지
툴도 개발하고 뭐 그러고 있습니다만....! vi는 비교적 게으른(?)
사용자도 쓸 수 있지만 emacs는 절대로(!?) 게으른 사람은 쓰기
쉽지 않더라구요.."더더욱(!)" 게으르기 짝이 없는 윈도 사용자들은
손대기도 힘듭니다.

제 경우(쫌 부끄럽지만)를 간단히 예로 들어보자면...

우선 저는 대부분의 에디터를 사용할 때 단축키를 먼저 살펴보는
습성(?)이 있습니다. 그래서 대부분의 프로그램에서 키보드 우선
작업을 하죠. 가급적 마우스 안쓰려고 합니다. 요즘엔 손목도 별로
좋지도 않구요... ㅠ.ㅠ;;

그리고 키보드가 적당히 느리지 않은 편(과연?)이라서 그런지
콘솔을 매우 좋아하는 습관(?)이 있죠.

하여튼... emacs를 위해 요청이 있다면.....

1. C-c라는 표기가 emacs 또는 리눅스쪽의 표준 표기라면
일부러라도 ^c 또는 Ctrl-C정도의 표기를 '찾을 수' 있게라도
해줬으면 합니다. 이 글을 보고 처음 알았습니다. (게을러서
죄송합니다.... ㅠ.ㅠ;;;; )

2. 마찬가지로 M-c라는 표기도... (역시 죄송... -.--; )

3. 종료하는 커맨드가 뭔가요...? (처음부터 끝까지 죄송...?)

4. (이건 리눅스 전반적인 얘기가 될 수 있을지 모르지만) 매뉴얼이
있는데 왜 참조하지 못하느냐... 라고 하시겠지만... 대부분 모든
사람이 게으르다는 것을 인정해야 할 것이라고 봅니다. 개발자의
게으름 뿐만 아니라 모든 사람의 게으름이 미덕인 것이죠. 그런
상황에서 읽는 사람의 레벨을 구분하지 못하는 매뉴얼은 심하게
말하면 쓰레기랄수 밖에 없을 것 입니다. (매우 많은 경우에)
이런 류의 매뉴얼은 엄청나게 많습니다. 영문으로 작성된 매뉴얼도
어쩌면 그런류에 포함될 수 있겠구요, 언어에 상관없이 기능이나
옵션을 수페이지에 걸쳐 나열한 매뉴얼은 솔직히 읽기도 싫습니다.
제 생각에 매뉴얼은 여러 단계에 걸쳐서 설명해야 하지 않을까 싶
습니다. 우선 시작하고 종료하는 문제! 저도 그렇지만
위에 글을 읽어보니 의외로 어떻게 끝내는지 모르는 분이 많이
보이는 군요. 더불어 기본 기능. emacs의 기본이 편집기라면
시작-편집-수정-저장-종료의 진행은 당연할 텐데 대부분의 설명서
에는 이 과정에 대한 설명이 없습니다. 제가 가진 컴퓨터 사용에
관한 상식이 잘못됐는지 모르겠지만 제 상식대로 입력하는 것으로는
수정 및 저장, 종료가 잘 안되더군요. vi처럼 hjkl로 커서 이동한다는
정도의 정보도 얻기 쉽지 않습니다. 기본 편집 기능을 이해
하기 시작했다면 고급 편집기능도 어렵지 않게 알 수 있습니다.
이정도 되면 스스로 원하는 기능도 (고생은 하더라도) 만들어 쓰려는
의지가 있으니 이후에는 고급 매뉴얼 정도는 스스로 읽고 해결할
것으로 보입니다.

다시한번 부탁(?)드립니다만, emacs에 대한 고급 매뉴얼은 인터넷
세상에 넘치고 넘쳐있는 것 같습니다. (음... 제가 이해할 수 없는
모든 emacs 매뉴얼을 고급 매뉴얼로 간주한다면... ㅠ.ㅠ;; )
제게 필요한 매뉴얼은... 메모장(또는 cat!!!?) 을 편집기로 사용하는
사람이 emacs를 사용할 때 필요한 매뉴얼입니다.

...

저를 emacs의 세계로 이끌어 주세요... ^^;

--------------------------------------
재미없는 일은 하지 말자는 인간 쓰레기.
-.-;

익명 사용자의 이미지

질문할 곳도 변변찮은데
사용자는 거의 없고(희한한게 vi 애기만 나오면 emacs 애찬론자들이 나타났다가 질문하면 다 사라짐)

질문해봐야 아는 사람 없고(내가 모르면 남도 모르는..)

튜토리얼은 많은데 기본적인 편집기능이고.

그외..

가장 핵심적인것은 emacs 몰라도 전혀 불편하거 없고
무거운 emacs 띄울빠에 한텀에서 vi 치는게 훨씬 효율적이고 간편하다는 점이 아닐까요.

cinsk의 이미지

nohmad wrote:

readline의 emacs 키바인딩은 <C-a>와 <C-e>, <M-f>, <M-b> 정도만 외웁니다. 그런데 윈도의 터미널들은 대부분 <Alt> 키를 막아버리고 있어서, <Esc-f>, <Esc-b> 식으로 눌러야 하는데 이거 좀 귀찮죠. 거기다 <C-a>는 screen 하고 충돌이 나기 때문에 역시 또 사용 불가.

윈도우의 terminal emulator의 설정 부분을 찾아 보시면, alt key가 terminal로 전달되게 하는 옵션이 있을 것입니다. 지금 Windows를 쓸 수 있는 환경이 아니라 잘은 모르겠지만 아마 제 기억이 맞다면 putty나 CRT 정도면 있었던 것 같습니다.

C-a는 screen하고 충돌이 납니다. 그래서 전 screen의 escape를 C-c로 바꾸어서 씁니다. /etc/screenrc에

escape ^ca

를 추가합니다.

antibug wrote:

1. C-c라는 표기가 emacs 또는 리눅스쪽의 표준 표기라면
일부러라도 ^c 또는 Ctrl-C정도의 표기를 '찾을 수' 있게라도
해줬으면 합니다. 이 글을 보고 처음 알았습니다. (게을러서
죄송합니다.... ㅠ.ㅠ;;;; )

2. 마찬가지로 M-c라는 표기도... (역시 죄송... -.--; )

3. 종료하는 커맨드가 뭔가요...? (처음부터 끝까지 죄송...?)


^^. Emacs를 시작하면 맨 먼저 나오는 화면에 menu에서 tutorial을 실행할 수 있다고 알려 줍니다. C-h t 또는 [Help]->[Tutorial]을 선택하면, 제일 먼저 나오는 화면이 다음과 같습니다.

이맥스 명령들은 대개 제어쇠 (CTRL이나 CTL이라고도 표시) 혹은
META쇠 (EDIT이나 ALT라고도 표시)를 사용합니다.  이런 글쇠를 매번 다
쓰기 보다는 우리는 다음과 같은 약식 표현을 쓰기로 합시다:

 C-<문자>  제어쇠를 누른 채 <문자> 글쇠를 칩니다.  즉, C-f는 제어쇠를
	   누른 상태에서 f 글쇠를 치는 것을 말합니다.
 M-<문자>  META쇠나 EDIT쇠 혹은 교체쇠(ALT)를 누른 채 <문자> 글쇠를
	   칩니다. META쇠, EDIT쇠 혹은 교체쇠가 없으면 나옴쇠(ESC)를
	   눌렀다 놓은 후 <문자> 글쇠를 칩니다.  나옴쇠는 <ESC>이라고
	   쓰기로 합니다.

유의:  C-x C-c를 치면 이맥스를 종료할 수 있습니다.

많은 분들이 쉽게 볼 수 있는 tutorial이 있었으면 하는데, 사실 tutorial이나 guideline은 많습니다. 또 대부분 게을러서 방대한 양을 쉽게 볼 수 없다고 말씀하시는데, 이 부분은 어떻게 할 수 없을 것 같습니다. 그나마 가장 편하게? 할 수 있는 것이라면, 개발 목적으로 쓸 때, 얼마나 편하게 할 수 있는가.. 정도를 따라서 만들어 볼까 합니다. 회사 일로 바빠서 아마도 한두달 내에는 힘들 것 같군요.
:oops:

baraboau의 이미지

cinsk님, 먼저 쓰레드와 관련 없는 질문 글 올려서 죄송하구요..
하나만 좀 여쭤볼께요.
제가 hhk키보드를 사용하는데 아시다시피 hhk의 스페이스바 양옆으로 메타키가 붙어 있습니다.
그런데 이 hhk의 메타키와 이맥스에서 사용되는 메타키가 다른 개념의 키인가요?
이맥스에서 hhk의 메타키가 먹히질 않네요. 현재는 그냥 Alt로 누르고 있습니다.
cinsk님도 hhk를 사용하신다고 하니 혹시 도움 좀 얻을 수 있을까 해서 질문 드립니다.
OS는 젠투리눅스 사용중입니다.

herblover의 이미지

AI 수업때 CLISP을 배우는 바람에, Emacs를 잠깐 다뤄 볼 일이 있었습니다.
주력으로 사용중이었던 것은 vi 였고요.

가장 당혹스러웠던 점은, 도대체가 블럭지정, 복사, 붙여넣기를 하기가 힘들었다는 점입니다. 여러가지 찾아가 보고, 따라해 보고 했지만, 도저히 직관적으로 블럭지정, 복사, 붙여넣기의 단계가 어려워서 포기해 버렸습니다.

제일 힘들었던 점은 이거네요. 여차하면 언제든지 마우스를 쓸 준비가 되어 있었기 때문에 종료, 저장은 별 문제 없었던 걸로 기억합니다.

jemiro의 이미지

제가 젠투 리눅스를 쓰는 관계로 emacs cvs 빌드를 사용하고 있습니다.
gtk2에 바인딩 되어 UI가 상당히 깔끔하게 변했습니다 (기본틀은 동일한데 세부적인 곳에 하나씩 개선되어 가고 있는 모습들이 보입니다).

firefox와 mozlla의 차이처럼 emacs-cvs 에서 개선 작업이 이루어 지고 있는것 같습니다.

구글에서 emacs cvs windows로 검색해 윈도용 emacs-cvs를 찾아 사용해보니,
firefox처럼 윈도 UI와 잘어울려져 있고,
기존 처럼 폰트를 지정하지 않아도 한글이 잘나오더군요.

처음 사용하시는 분들에게 도움이 될만한건,
툴바쪽 기능들이 많이 개선 되어 있습니다.

리눅스에서 gtk2 바인딩 된 emacs를 쓰기 위해 cvs버젼을 사용하고 있었는데, 윈도용 emacs-cvs의 완성도도 만족스러워서,
혹 윈도 환경에서 처음 이멕스를 접하시는 분이 계시면 사용해보실것을 추천 드립니다.

http://www.crasseux.com/emacs/
http://www.crasseux.com/emacs/emacs_bin_cvs_2005_04_16.tar.bz2

이렇게 링크를 올리면 안될것 같은 생각이 들지만,
문제가 되면 삭제 하겠습니다. 관심 있으시면 한번 사용해보세요.

sangu의 이미지

jemiro wrote:
제가 젠투 리눅스를 쓰는 관계로 emacs cvs 빌드를 사용하고 있습니다.
gtk2에 바인딩 되어 UI가 상당히 깔끔하게 변했습니다 (기본틀은 동일한데 세부적인 곳에 하나씩 개선되어 가고 있는 모습들이 보입니다).

firefox와 mozlla의 차이처럼 emacs-cvs 에서 개선 작업이 이루어 지고 있는것 같습니다.

구글에서 emacs cvs windows로 검색해 윈도용 emacs-cvs를 찾아 사용해보니,
firefox처럼 윈도 UI와 잘어울려져 있고,
기존 처럼 폰트를 지정하지 않아도 한글이 잘나오더군요.

처음 사용하시는 분들에게 도움이 될만한건,
툴바쪽 기능들이 많이 개선 되어 있습니다.

리눅스에서 gtk2 바인딩 된 emacs를 쓰기 위해 cvs버젼을 사용하고 있었는데, 윈도용 emacs-cvs의 완성도도 만족스러워서,
혹 윈도 환경에서 처음 이멕스를 접하시는 분이 계시면 사용해보실것을 추천 드립니다.

http://www.crasseux.com/emacs/
http://www.crasseux.com/emacs/emacs_bin_cvs_2005_04_16.tar.bz2

이렇게 링크를 올리면 안될것 같은 생각이 들지만,
문제가 되면 삭제 하겠습니다. 관심 있으시면 한번 사용해보세요.

또 다른 CVS Emacs MS 윈도용 패키지

http://ourcomments.org/Emacs/EmacsW32.html

이 패키지는 인스톨 프로그램이 포함되어 있습니다.

eungkyu의 이미지

저도 열심히 emacs를 배워보던 때가 있었는데요
결국을 포기하고 vim으로 돌아왔습니다 ^^

emacs를 막 배우면서 재미붙일때는 진짜 이것저것 전부 emacs에서 해결해보자 하는 생각이 있었거든요, 그런데 지나다보니까 내가 왜 이짓을 하고있나... 하는 회의가 들더라구요.

왜 좋은 mutt 놔두고 emacs에서 메일확인을 하려할까...
왜 좋은 터미널 + bash를 놔두고 eshell를 써야 할까...
왜 나비 이런거 놔두고 자체 im을 써야하나...
등등

지금은 안쓴지 오래되서 잘 생각이 안나는데, 어쨋든 이런 이유로 인해서 결국은 다시 자유롭게 수많은 툴을 사용하는 세상으로 돌아왔습니다. emacs 안에 갇히기 싫더라구요.

그러다보니까 주변 기능은 포기하고 편집기로서의 emacs를 살펴보자, 하니까 이제 새로운 문제가 여럿 생기더군요.

그 중 가장 큰 것은 왜 내가 아직도 이렇게 삽질하며 폰트를 골라야 하나, 이거였습니다. 당시 cvs버전 깔면 gtk2로 된다고 해서 깔아봤으나 ui만 그렇고 편집니 내부는 여전하드라구요. 당시 새로운 xft+fontconfig에 심취해서 무조건 x core font를 사용하는 프로그램은 배제하고 있었습니다. 지금도 gtk1은 라이브러리 자체가 안깔린 상태에서 사용하고 있구요.

각종 ui 및 폰트같은 것들은 gtk2에서 모두 따오고, 기능이나 단축키 등은 emacs와 같으면서 닫힌 세상으로 끌어들이지 않는 에디터는 어디 없을까 하는 생각을 해보았습니다.

cinsk의 이미지

baraboau wrote:
cinsk님, 먼저 쓰레드와 관련 없는 질문 글 올려서 죄송하구요..
하나만 좀 여쭤볼께요.
제가 hhk키보드를 사용하는데 아시다시피 hhk의 스페이스바 양옆으로 메타키가 붙어 있습니다.
그런데 이 hhk의 메타키와 이맥스에서 사용되는 메타키가 다른 개념의 키인가요?
이맥스에서 hhk의 메타키가 먹히질 않네요. 현재는 그냥 Alt로 누르고 있습니다.
cinsk님도 hhk를 사용하신다고 하니 혹시 도움 좀 얻을 수 있을까 해서 질문 드립니다.
OS는 젠투리눅스 사용중입니다.

결론부터 말하자면 HHK의 meta키는 emacs에서 말하는 meta와 같은 키입니다. 그런데, HHK의 설정 (뒷부분에 있는 dip switch)과 X window system의 설정에 따라 약간씩 다르게 동작할 수 있습니다. HHK의 뒷부분 dip switch를, HHK의 밑면에 나와 있는 방법 대로, <> 키가 meta key로 동작하게 설정하면 됩니다.
그런데, 이 방식을 쓰면 한가지 염려스러운 것이, Windows로 부팅할 경우, 제대로 인식이 되지 않을 수 있습니다. 이 경우, <> 키를 meta key로 인식시키기 위해서는 xmodmap(1)을 써서 key mapping을 강제로 바꿀 수 있습니다.
이때 보통 키 값을 조사하기 위해서 xev란 유틸리티를 같이 쓰는데 먼저,
EmacsGdbEtagsCscope을 훑어 보시기 바랍니다. 자세한 것은 여기서 다루기가 좀 그렇군요. 힌트를 드리자면, <> key를 눌렀을 때 나오는 키 symbol이 xmodmap을 그냥 실행했을 때 출력되는 mod1 entry에 등록이 되어 있어야 합니다.
cinsk의 이미지

GTK+ 2.0 style look을 원하시면 emacs 22.0 이상의 버전(현재 emacs cvs에 있는)을 쓰기 추천드립니다. 아직 stable 단계는 아니지만, 그래도 쓰는 데에는 큰 문제 없어 보입니다.

Gentoo 사용자시라면 단순히 USE flag에 gtk를 추가하시고 (대부분 기본적으로 되어 있을 것임), 다음을 실행하면 됩니다:

# emerge emacs-cvs

기타 배포판 사용자이시라뎐, 다음과 같이 직접 cvs에서 받아서 할 수 있습니다.

# export CVS_RSH=ssh
# cvs -d :ext:anoncvs@savannah.gnu.org:/cvsroot/emacs co emacs
# ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --mandir=/usr/share/man --with-x-toolkit=gtk --infodir=/usr/share/info --with-png --with-gif --with-tiff -with-jpeg --with-xpm CFLAGS='-march=pentium4 -O2'
# make bootstrap
# make all && make install

위 configure에서 입맛에 따라? prefix 위치와 CFLAGS를 조정하기 바랍니다.

댓글 첨부 파일: 
첨부파일 크기
Image icon 0바이트
cinsk의 이미지

아, 참고로 요 며칠째 cvs 버전 build가 실패하는 일이 있었는데, 패치가 이미 적용되었기 때문에, 이 글을 보시는 시점에서는 설치에 문제가 없을 것입니다.

sangu의 이미지

eungkyu wrote:

그 중 가장 큰 것은 왜 내가 아직도 이렇게 삽질하며 폰트를 골라야 하나, 이거였습니다. 당시 cvs버전 깔면 gtk2로 된다고 해서 깔아봤으나 ui만 그렇고 편집니 내부는 여전하드라구요. 당시 새로운 xft+fontconfig에 심취해서 무조건 x core font를 사용하는 프로그램은 배제하고 있었습니다. 지금도 gtk1은 라이브러리 자체가 안깔린 상태에서 사용하고 있구요.

http://lists.gnu.org/archive/html/emacs-devel/2005-03/msg00904.html

현재 emacs cvs에 Xft를 이용하는 branch(XFT_JHD_BRANCH)가 있습니다. 그런데 cjk쪽 입출력에 문제가 있습니다.

----
http://people.redhat.com/petersen/emacs/current/i386/
Emacs CVS fedora development rpm 패키지

댓글 첨부 파일: 
첨부파일 크기
Image icon 0바이트

baraboau의 이미지

cinsk wrote:
baraboau wrote:
cinsk님, 먼저 쓰레드와 관련 없는 질문 글 올려서 죄송하구요..
하나만 좀 여쭤볼께요.
제가 hhk키보드를 사용하는데 아시다시피 hhk의 스페이스바 양옆으로 메타키가 붙어 있습니다.
그런데 이 hhk의 메타키와 이맥스에서 사용되는 메타키가 다른 개념의 키인가요?
이맥스에서 hhk의 메타키가 먹히질 않네요. 현재는 그냥 Alt로 누르고 있습니다.
cinsk님도 hhk를 사용하신다고 하니 혹시 도움 좀 얻을 수 있을까 해서 질문 드립니다.
OS는 젠투리눅스 사용중입니다.

결론부터 말하자면 HHK의 meta키는 emacs에서 말하는 meta와 같은 키입니다. 그런데, HHK의 설정 (뒷부분에 있는 dip switch)과 X window system의 설정에 따라 약간씩 다르게 동작할 수 있습니다. HHK의 뒷부분 dip switch를, HHK의 밑면에 나와 있는 방법 대로, <> 키가 meta key로 동작하게 설정하면 됩니다.
그런데, 이 방식을 쓰면 한가지 염려스러운 것이, Windows로 부팅할 경우, 제대로 인식이 되지 않을 수 있습니다. 이 경우, <> 키를 meta key로 인식시키기 위해서는 xmodmap(1)을 써서 key mapping을 강제로 바꿀 수 있습니다.
이때 보통 키 값을 조사하기 위해서 xev란 유틸리티를 같이 쓰는데 먼저,
EmacsGdbEtagsCscope을 훑어 보시기 바랍니다. 자세한 것은 여기서 다루기가 좀 그렇군요. 힌트를 드리자면, <> key를 눌렀을 때 나오는 키 symbol이 xmodmap을 그냥 실행했을 때 출력되는 mod1 entry에 등록이 되어 있어야 합니다.

자세한 말씀 감사드립니다^^
알려주신 방법대로 해서 드디어 성공했습니다~
맨처음 showkey로 meta의 키코드값을 확인하고 xmodmap 명령으로 meta키의 코드값을 mod1에 등록시켰는데
여전이 alt만 먹고 meta는 인식이 안되더군요.
그래서 다시 구글로 몇가지 검색한 후에 xkeycaps을 emerge로 설치하고
xkeycaps 프로그램을 통해서 meta키를 mod1로 설정하니 이번에는 제대로 잘 됩니다.
(xkeycaps에서 만들어지는 설정파일을 xmodmap으로 읽어 들였습니다)
아마 제가 처음에 meta키의 코드값을 잘못 설정했었나 봅니다.
cinsk님의 자세한 설명 덕분에 드디어 해결이 되었네요.
정말 감사드립니다~ ^^
체스맨의 이미지

위에도 언급은 있었지만, 저는 Emacs 의 큰 용량때문에 아예 더 익숙해질 생각을 하지 않았습니다. 리누스 토발즈도 이 부분에 대해 지적했던 적이 있었던 것으로 아는데요...

개인적인 생각으론 VI 든 Emacs 든 다른 에디터든 익숙해지고자 한다면 어려워서 못한다는 건 말이 안된다고 생각합니다. 단지 저 같은 경우는 큰 용량이 문제였습니다. 용량이 훨씬 작은 VI 가 원활하게 작동하는 시스템이, 아주 열악한 시스템에서라도 더 많을 것이라는 생각때문에 VI 를 택했습니다.

Orion Project : http://orionids.org

perky의 이미지

cinsk wrote:
  • C-n emacs(커서를 아래줄로) bash(history에서 다음 명령), info(커서를 아래줄로), python(history에서 다음 명령), GtkTextView (아래 줄)
  • C-p emacs(커서를 윗줄로) bash(history에서 윗 명령), info(커서를 윗줄로), python(history에서 윗 명령), GtkTextView (윗 줄)

python에서는 emacs 키 바인딩을 지원하지 않습니다. 단지, readline을 선택적으로 지원할 뿐입니다. readline 지원을 빼고 컴파일하면 emacs 키 바인딩은 전혀 지원 되지 않고, 입력제어와 관련된 유일한 키인 백스페이스 조차도 emacs와 다르니까 전혀 다르다고 볼 수 있겠죠. :)

readline은 vi와 emacs 바인딩 모두 지원하니까 bash, python, mysql, postgresql 등 readline을 사용하는 프로그램에 대해서는 언급을 빼야 옳겠죠.

[/]

You need Python

irondog의 이미지

emacs유저들이 말하는 기능 중에 이거 써봐라, 저거 써봐라 하는 기능의 대부분이 vim에서 잘 쓰고 있던
기능들이라 매료될만한 기능이 없었죠. 단지 써보고 싶게 만들었던 기능이 있다면 편집기에서 디버깅이
가능하고 그래픽컬한 기능이 vim보다는 뛰어났다는 것인데요.

그런 자료를(화면캡쳐) 올리셨던 분에게 질문을 해봤지만 대답이 없더군요. -.-;

그래서 뭐가 어려운지가 아니라 어떤 기능이 특별한지 보여주시고 알려 주시면 다시한번
도전해 보고 싶습니다. vim을 배웠을 때 그랬듯이 모든 것을 잊고 다시 배우는 기분으로 해보고 싶네요.

지금 제일 궁금한건 window보다는 frame인데요 이거 따로 띄워서 C언어 소스의
define, function등을 따로 정리해서 list해주는 화면을 어떻게 만드는지...
(물론 vim에도 tlist라는 기능으로 가능 합니다만 덜 visual적이죠. 화면 옮겨 다니는 것도 좀 불편하고...
헌데 emacs의 그것은 윈도에서 source-insight의 화면을 보는듯한 인상을 받았습니다.)
그럼 window에 비해 frame을 옮겨다니는게 얼마나 편한 것인지 직접 체험 해 볼 수도 있고 괜찮을듯 싶네요.

바쁘시더라도 한번 도와주세요. ㅋㅋㅋ

익명 사용자의 이미지

김도현 wrote:
예전에 KTUG에 이런 글을 올린 적이 있습니다.
Quote:
Emacs 와 Vim. 편집기界의 양대 산맥. 그 중에 지금은 Vim을 많이 쓰고 있다. 거의 끼고 산다고 보면 된다. TeX뿐 만 아니라 모든 텍스트파일 편집을 이걸로 해결한다. 예전엔 Emacs를 주로 썼었다. 그런데 UTF-8환경으로 옮아오고부터는 Emacs가 불편하게 되었다. 아직 내부적으로 유니코드 지원이 완전히 이루어지지 못하고 있기 때문이다. 이를테면 “ㅤㄸㅗㅁ”이라는 글자를 Emacs는 화면에 표시해주지 못한다. mule-ucs를 얹으면 한글도 유니코드로 입출력할 수 있지만 아쉽게도 KSC5601의 범위 내에서만 가능한 것이다. AUCTeX이라는 매혹적인 환경을 못내 뿌리치고 Vim을 주로 쓰게 된 것은 Vim의 발빠른 행보와 Emacs의 상대적 지체현상이 원인이었다(물론 다음 버전 이맥스는 유니코드를 완전히 지원할 것이므로 그때 가면 뭘 쓰고 있을지 나도 모른다 ). 그리하여 본격적으로 쓰게 된 Vim은 AUCTeX환경에는 아무래도 못 미치지만 차츰 익숙해지고 단축키도 몇가지 정의해두고 보니 그런대로 Emacs가 크게 부럽지 않을 지경까지 이르게 되었다.

물론 평소 “ㅤㄸㅗㅁ” 같은 글자를 칠 일이 거의 없지만 당시 TeX에서 한글 utf-8 인코딩 지원한다고 법석을 떨던 때라 그리 되었습니다. 이 문제는 어떻게 생각하시는지, 혹은 이미 해결된 문제인데 저만 모르고 있는건지 고견을 듣고 싶습니다.

저도 같은 생각인데요.
emacs. UTF-8지원하나요?
gonEH의 이미지

헛.. 잘못하고 로그인을..;;

윗글은 저의 글입니다.

익명 사용자의 이미지

Anonymous wrote:
김도현 wrote:
예전에 KTUG에 이런 글을 올린 적이 있습니다.
Quote:
Emacs 와 Vim. 편집기界의 양대 산맥. 그 중에 지금은 Vim을 많이 쓰고 있다. 거의 끼고 산다고 보면 된다. TeX뿐 만 아니라 모든 텍스트파일 편집을 이걸로 해결한다. 예전엔 Emacs를 주로 썼었다. 그런데 UTF-8환경으로 옮아오고부터는 Emacs가 불편하게 되었다. 아직 내부적으로 유니코드 지원이 완전히 이루어지지 못하고 있기 때문이다. 이를테면 “ㅤㄸㅗㅁ”이라는 글자를 Emacs는 화면에 표시해주지 못한다. mule-ucs를 얹으면 한글도 유니코드로 입출력할 수 있지만 아쉽게도 KSC5601의 범위 내에서만 가능한 것이다. AUCTeX이라는 매혹적인 환경을 못내 뿌리치고 Vim을 주로 쓰게 된 것은 Vim의 발빠른 행보와 Emacs의 상대적 지체현상이 원인이었다(물론 다음 버전 이맥스는 유니코드를 완전히 지원할 것이므로 그때 가면 뭘 쓰고 있을지 나도 모른다 ). 그리하여 본격적으로 쓰게 된 Vim은 AUCTeX환경에는 아무래도 못 미치지만 차츰 익숙해지고 단축키도 몇가지 정의해두고 보니 그런대로 Emacs가 크게 부럽지 않을 지경까지 이르게 되었다.

물론 평소 “ㅤㄸㅗㅁ” 같은 글자를 칠 일이 거의 없지만 당시 TeX에서 한글 utf-8 인코딩 지원한다고 법석을 떨던 때라 그리 되었습니다. 이 문제는 어떻게 생각하시는지, 혹은 이미 해결된 문제인데 저만 모르고 있는건지 고견을 듣고 싶습니다.

저도 같은 생각인데요.
emacs. UTF-8지원하나요?

emacs 에서 제일 답답한 부분이죠.
UTF-8 은 지원하지만 euc-kr 을 벗어나는 한글은 처리하지 못합니다. 반쪽짜리죠.

cinsk의 이미지

emacs!!! wrote:

emacs 에서 제일 답답한 부분이죠.
UTF-8 은 지원하지만 euc-kr 을 벗어나는 한글은 처리하지 못합니다. 반쪽짜리죠.

슬프게도? :oops: 아직까지는 그렇습니다.
익명 사용자의 이미지

irondog wrote:
emacs유저들이 말하는 기능 중에 이거 써봐라, 저거 써봐라 하는 기능의 대부분이 vim에서 잘 쓰고 있던
기능들이라 매료될만한 기능이 없었죠. 단지 써보고 싶게 만들었던 기능이 있다면 편집기에서 디버깅이
가능하고 그래픽컬한 기능이 vim보다는 뛰어났다는 것인데요.

그런 자료를(화면캡쳐) 올리셨던 분에게 질문을 해봤지만 대답이 없더군요. -.-;

그래서 뭐가 어려운지가 아니라 어떤 기능이 특별한지 보여주시고 알려 주시면 다시한번
도전해 보고 싶습니다. vim을 배웠을 때 그랬듯이 모든 것을 잊고 다시 배우는 기분으로 해보고 싶네요.

지금 제일 궁금한건 window보다는 frame인데요 이거 따로 띄워서 C언어 소스의
define, function등을 따로 정리해서 list해주는 화면을 어떻게 만드는지...
(물론 vim에도 tlist라는 기능으로 가능 합니다만 덜 visual적이죠. 화면 옮겨 다니는 것도 좀 불편하고...
헌데 emacs의 그것은 윈도에서 source-insight의 화면을 보는듯한 인상을 받았습니다.)
그럼 window에 비해 frame을 옮겨다니는게 얼마나 편한 것인지 직접 체험 해 볼 수도 있고 괜찮을듯 싶네요.

바쁘시더라도 한번 도와주세요. ㅋㅋㅋ

http://ecb.sourceforge.net/
http://ecb.sourceforge.net/screenshots/index.html

ecb 를 말씀하시는듯 하네요.
ecb 가 보기엔 좀 이쁘고 기능도 좀 더붙어있고 한데, taglist 와 별차이 없습니다.(사실 이렇게는 말할수 없는게.. ecb 는 lexer, parser 가 붙은 엽기적인 놈입니다. ctags 에 의존하는 taglist 와는 본질적으로 다릅니다. 하지만 결국 용도는 비슷합니다.)

vim 에서 못하고 emacs 에서만 되는 그런 기능은 거의 없습니다. 기능적으로는 거의 유사합니다. 차이점은 emacs 는 자체가 하나의 개발환경같은.. 거라서 커스터마이징의 영역이 vim 과는 비교가 안되죠. vim 만으로 못하는게 좀 있긴 하지만 vim + 다른툴 쓰면 해결되는 문제죠. emacs 쓰시는 분들은 모든일을.. 기본적인 shell 을 띄우는일까지도.. emacs 안에서 처리하고(할수있고), vim 쓰시는 분들은 다른 툴과 연동해서 쓰게 됩니다.

다른 에디터는 모르겠고, vim 을 쓰다가 emacs 로 바꾸면서 vim 에는 없는 기능을 바란다면 다시 vim 으로 돌아갈 가능성이 높습니다. 편집기로서는 둘다 비슷하니까요. 자신에게 최적화된 개발환경을 꾸미고 싶다.. 이런 식으로 접근을해야 emacs 만의 장점이 보일겁니다.

저도 emacs 로 옮긴 가장 큰 이유는 편집때문이 아니고, gnus(메일,뉴스그룹리더) 와 planner(일정관리등등) 때문이었습니다...

cinsk의 이미지

아직, 게으름을 다 씻지 못해서? :wink: 대충 시작만? 해 봤는데.. 이 정도 글을 여러 개 만들어 놓으면 어떨까 합니다. 아직 완전한 것이 아니니까 여러분들의 피드백을 바랍니다.

너무 쉽다거나 (좋은 반응이죠. :wink: ),
내용이 없다거나 ( :oops: ),
아예 다른 스타일의 글을 원하신다면 ( :roll: ),

피드백을 주시기 바랍니다.

EmacsChangeColors

익명 사용자의 이미지

cinsk wrote:
emacs!!! wrote:

emacs 에서 제일 답답한 부분이죠.
UTF-8 은 지원하지만 euc-kr 을 벗어나는 한글은 처리하지 못합니다. 반쪽짜리죠.

슬프게도? :oops: 아직까지는 그렇습니다.

mule-ucs의 문제인건가요?

mule-ucs에 있는건 단지 ksc5601 <-> UCS간의 변환 테이블인것 같던데, cp949<->ucs간의 테이블이 필요한건가요?

kane의 이미지

M-x customize 로 설정하는 법이 빠졌어요~
==3=3

cinsk의 이미지

kane wrote:
M-x customize 로 설정하는 법이 빠졌어요~
==3=3

완전하지는 않지만 추가했습니다. :wink:

냐함.. 잘 시간이군요.. 그럼 :twisted:

kane의 이미지

cinsk wrote:
kane wrote:
M-x customize 로 설정하는 법이 빠졌어요~
==3=3

완전하지는 않지만 추가했습니다. :wink:

냐함.. 잘 시간이군요.. 그럼 :twisted:


수고하셨습니다.
좋은 꿈 꾸세요. :oops:
익명 사용자의 이미지

Anonymous wrote:
cinsk wrote:
emacs!!! wrote:

emacs 에서 제일 답답한 부분이죠.
UTF-8 은 지원하지만 euc-kr 을 벗어나는 한글은 처리하지 못합니다. 반쪽짜리죠.

슬프게도? :oops: 아직까지는 그렇습니다.

mule-ucs의 문제인건가요?

mule-ucs에 있는건 단지 ksc5601 <-> UCS간의 변환 테이블인것 같던데, cp949<->ucs간의 테이블이 필요한건가요?

emacs-src/leim/quail/korean.el 에 Eha 을 똠 에 대응하도록 추가해봤는데
똠 이란 문자를 아예 읽지를 못하네요.( 인코딩이 7bit 로 되어있길래, euc-kr 로 수정후 똠 을 추가했습니다. ) 여기저기 뒤져보니까 emacs-src/lisp/language/korean.el 에서 korean-iso-8bit 란 코딩시스템을 정의하는데, 이걸 좀 손보면 되지 않을까하는 생각이 막연히...

근데 make-coding-system 도움말을 보니까,

  0: Emacs internal format,
  1: Shift-JIS (or MS-Kanji) used mainly on Japanese PCs,
  2: ISO-2022 including many variants,
  3: Big5 used mainly on Chinese PCs,
  4: private, CCL programs provide encoding/decoding algorithm,
  5: Raw-text, which means that text contains random 8-bit codes.

중국어랑 일본어는 make-coding-system 내부에서 잘 지원되는 모냥이군요. korean.el 도 일본에서 나온 소스인듯 하구요... :roll:
익명 사용자의 이미지

http://emacswiki.org/cgi-bin/wiki/JorgenSchaefersEmacsConfig

RFC 문서 자주 보시는분께는 유용하겠네요.

(defun rfc (num)
  "Show RFC NUM in a buffer."
  (interactive "nRFC (0 for index): ")
  (let ((url (if (zerop num)
                 "http://www.ietf.org/iesg/1rfc_index.txt"
               (format "http://www.ietf.org/rfc/rfc%i.txt" num)))
        (buf (get-buffer-create "*RFC*")))
    (with-current-buffer buf
      (let ((inhibit-read-only t))
        (delete-region (point-min) (point-max))
        (let ((proc (start-process "wget" buf "wget" "-q" "-O" "-" url)))
          (set-process-sentinel proc 'rfc-sentinel))
        (message "Getting RFC %i..." num)))))

(defun rfc-sentinel (proc event)
  "Sentinel for `rfc'."
  (with-current-buffer (process-buffer proc)
    (goto-char (point-min))
    (view-mode 1)
    (when (fboundp 'rfcview-mode)
      (rfcview-mode)))
  (display-buffer (process-buffer proc)))
peccavi의 이미지

cinsk wrote:
아직, 게으름을 다 씻지 못해서? :wink: 대충 시작만? 해 봤는데.. 이 정도 글을 여러 개 만들어 놓으면 어떨까 합니다. 아직 완전한 것이 아니니까 여러분들의 피드백을 바랍니다.

너무 쉽다거나 (좋은 반응이죠. :wink: ),
내용이 없다거나 ( :oops: ),
아예 다른 스타일의 글을 원하신다면 ( :roll: ),

피드백을 주시기 바랍니다.

EmacsChangeColors

좀전에 따라해 봤는데, :wink: 입니다. 그림이랑 같이 보니 너무 좋아요.. ^^

근데 .Xdefaults 설정으로 변환하는게 이상하게 저는 안되네요.. 잘못했나.. -_-;;

한글설정이나 개발환경 구축에 관한 문서 꼭좀 부탁드리겠습니다~~

----
jai guru deva om...

singlet의 이미지

peccavi wrote:
근데 .Xdefaults 설정으로 변환하는게 이상하게 저는 안되네요.. 잘못했나.. -_-;;

저와 같은 경우이신 것 같습니다. 저는 다음 방법으로 해결했습니다.
ln -sfn .Xdefaults .Xdefaults-`hostname`
cinsk의 이미지

peccavi님과 singlet님의 문제에 대한 내용 EmacsChangeColors에 추가했습니다. :wink:

cinsk의 이미지

글꼴에 대한 것은 좀 쓰기가 까다로운데, 읽어 보시고 조언바랍니다:

EmacsChangeFonts

irondog의 이미지

음... 윈도 환경에서는 따라 해보기가 여간 힘든게 아니로군요. -.-;;
일단 한글 입력을 포기하고 cygwin에서 설치해서 써봤는데...
HOME에 한글 디렉토리가 들어가니까 당장 ECB에서 에러가 뜨네요.

귀찮어~~~ ㅡ.ㅜ

cinsk의 이미지

손쉽게 글꼴 색상을 바꿀 수 있도록 script를 만들어 보았습니다. 읽어보시고, 원하시는 테마 색상 조합을 알려 주시거나, 조언 바랍니다.

EmacsChangeThemes

lovian의 이미지

업무환경이 유닉스입니다.
종류별로 다양하지요.

문제는 주로 사용하는 녀석이 HP인데.
HP용 emacs가 없습니다. T_T

-----------------
한글을 사랑합니다.

-----------------
한글을 사랑합니다.

skyer9의 이미지

emacs 까페 한개 만들었네요
뇌이버에서 emacs 검색해 보세요