EMACS 사용 3일째

gurugio의 이미지

그노무 리숩을 좀 해보겠다고 설치다가
기어이 이막스까지 손을 대고 말았습니다.
3일째 이막스로 일을 하고 있는데요
아주아주 먼 옛날 독수리 타법으로 레포트쓰던 시절이 떠오릅니다.
강의 시간은 다가오는데 손을 느리고 자꾸 틀리고 미치지요.

vim에서는 0과 O이 구분되는 글꼴을 썼는데 (bitstream sans ~~라는 긴 이름)
이막스에서는 같은 글꼴이라도 모양이 많이 다르네요.
기본 글꼴로 쓰고있는데 0/O이 구분이 안되서 거슬립니다.

그 외에는 아직 손에 안붙는다는거외에 불편함이 없습니다.
불편함이 있을 정도로 이것저것 많이 쓰고 있지도 않지요.

태그까지 쓰고있고, 빌드/svn 연동만 익히면 됩니다.
ctrl때문에 왼손 새끼가 좀 아프네요.
화살표를 안쓰려고 하는데, 확실히 손목이 좀 덜아픕니다.
화살키 누르려고 오른손목을 오른쪽으로 꺽으면 아플때가 있었거든요.

아참. 이막스의 shell 에서는 제가 정의한 환경 변수들이 잘 안되네요.
shell은 별수없이 터미널을 하나 더 띄어서 쓰고 있습니다.

youlsa의 이미지

축하드립니다.

쉘은 eshell 사용하시면 편합니다.

그리고...
설마 Ctrl을 Caps Lock 위치에 매핑 안해놓고 쓰고 계신건 아니겠죠?

=-=-=-=-=-=-=-=-=
http://youlsa.com

=-=-=-=-=-=-=-=-=
http://youlsa.com

gurugio의 이미지

eshell이 shell보다 편리하네요.
근데 한글이 안되고, 환경 설정해놓은게 호환이 안되는 문제는 같습니다.
차차 찾아봐야지요.

ctrl위치는 바꿨는데 새끼 손꾸락을 잘 안쓰다가 쓰니까 불편해서 그런것 같습니다.

----
섬기며 사랑하면 더 행복해집니다.
몸에 좋은 칼슘이 듬뿍담긴 OS 프로젝트 - 칼슘OS http://asmlove.co.kr/wiki/wiki.php/gurugio

klenui의 이미지

언어문제는 set-language-environment 로 거의 해결됩니다만..
eshell 관련 문제가 있다면 windows에서 사용하고 계시나 보네요..
예전에 set-processing-coding-system 으로 어쩌고 해서 해결했던 기억이 나는데..
더 자세한 내용이 기억 나지 않네요..
너무 답답해서 el파일들을 고치고 디버깅 메세지 보고.. 이런식으로 해결했던 기억이 납니다만..
정말 좌절의 나날이었습니다.. 그냥 리눅스에서 쓰는게 편해요...

jongi의 이미지

잠깐 만지작 거리다보니, 환경 설정 문제라면 bash를 사용중일 경우, .bashrc 등에 저장한 내용이 반영되지 않는다는 말씀이시죠?

shell은 잘 되는데, eshell은 안 되는군요.

웅... 초보의 어려움... ^^

--
종이한장 * 이성으로 비관하더라도 의지로 낙관하라! (그람시)

--
종이한장 * 이성으로 비관하더라도 의지로 낙관하라! (그람시)

jongi의 이미지

우분투 9.04에 들어있던 스냅샷 버전을 통해 이맥스로 전향(까지는 아니고 vim도 잘 쓰고 있어요. ^^) 했는데, eshell로 바꾸면 이상하게스리 열어두었던 버퍼와 eshell 버퍼가 꼬여서 "이게 뭐야? 도대체 어떻게 쓰는거지?"하고 포기했다가, "eshell 사용하시면 편합니다"는 말에 다시 한 번 시도했더니..... 읔...

지금은 Kubuntu 9.10에 기본으로 들어있는 23.1.1 버전인데, 제대로 되는군요. ㅠㅡ;
그럼 그렇지 이러니까 편하다 편하다고 말씀하셨던 것일텐데....

--
종이한장 * 이성으로 비관하더라도 의지로 낙관하라! (그람시)

--
종이한장 * 이성으로 비관하더라도 의지로 낙관하라! (그람시)

달리나음의 이미지

캡스락이 콘트롤 기능을 양보하셨나요? 다른 경우도 캡스락 대신에 콘트롤 키를 쓰는게 유리하지만 특히 이맥스에선 필수적입니다.

dl3zp3의 이미지

VIM사용자는 캡스락을 두번째 ESC키로 두고, Emacs는 캡스락을 세번째 Ctrl키로 두고, TeX사용자는 /를 두번쨰 \키로 두면 편하죠.

dl3zp3의 이미지

저는 이맥스를 사용한지 한 1년이 되가는데 Elisp가 불편하더군요. Elisp는 함수이름이라든지 그런게 좀 정리가 안된 느낌. 아직도 적응이 안되요. 그리고 Python처럼 Batteries Included가 아니라는 것도 불편해요. Elisp가 그 문법만큼이나 깔끔하면 얼마나 좋아요, 이건 완전 뭐 지원하는 함수들이나 라이브러리들이 정리 제대로 안된 도서관을 보는 듯 해요.

Elisp = bad Lisp?

johan의 이미지

최대 장점이자 단점이 될 수 있죠. 사용하다가 불편하세요? 그럼 직접 프로그래밍 하시면 됩니다. 그렇게 해서 모인 코드들이 오늘날의 Emacs 라이브러리라고 할 수 있죠. 제가 아는 사람 중 Elisp으로 처음 Lisp 프로그래밍 시작해서 현재는 Lisp 프로그래머로 아주 잘 나가는 사람 있습니다. 그 사람은 그런 불평을 하기 보다는 자기가 직접 그 마음에 안드는 코드를 수정하고 버그 보고하고 하면서 잘못된 것으로 부터 뭔가 배워서 그렇게 된 것입니다.

Emacs와 Elisp은 그냥 사용자용 개발환경이 절대 아닙니다. 툴을 자기 입맛에 맞게 프로그래밍 할 수 있거나 최소한 (성공/실패를 떠나서) 그렇게 하려고 시도하는 사람, 즉 해커를 위한 프로그래밍 가능한 개발환경입니다. 그게 싫고 남이 만들어준 뭔가 완제품 같고 속을 뜯어볼 수 없거나 뜯어보기 힘들거나 뭔가 내부를 들여다보는 행동을 해서는 안될 것 같은 개발환경을 원하신다면 Eclipse나 Vi 등 다른 적당한 개발환경이 있지 않나요? 저는 대부분 보증기간이 얼추 지나서 이상이 생긴 물건은 뭐든 바로 뜯어보는 성격이라 Emacs가 적성에 맞습니다만, 아닌 경우도 충분히 이해합니다. (개인적으로 Windows나 Mac을 별로 좋아하지 않는 것도 그런 이유 같습니다. 뜯어서 내부를 들여다 보기 힘든 구조). 저보다 더한 사람도 많더군요. 보증기간 중에도 바로 뜯어보거나 자기가 고장난 것 고치겠다고 들이대는 사람(개인적으로 그런 분들의 돈을 상관치 않는 모험심을 존경합니다). 최근 Arduino라는 장난감을 구입했는데, 비슷한 맥락에서 마음에 듭니다. 하드웨어와 소프트웨어 모두 뜯어서 어떻게 생겼는지 보기 좋은 구조라서.

그래서 Emacs는 대부분의 사람들에게는 맞지 않는 개발환경임에 틀림없습니다 - 소수를 위한 개발환경이고 그 특별한 소수가 존재하는 한 계속 발전할 개발환경입니다.

tj의 이미지

그냥 에디터로만 10년 넘게 쓰고 있습니다. 컨픽은 M-x customize에서 하고, 에디터 외의 기능은 이거저거 써보다가 관뒀습니다. 뭐든 할 수는 있는데, 이거 뭐 꼭 이렇게 해야하나 싶은 경우가 대부분이더라구요 (옆에 터미널 창 두고 쓰는 게 더 편한). 한동안 기본 에디팅 기능에 신경쓰이는 버그가 꽤 있어서 qemacs로 갈아타려다 당시 multi-window 기능이 없어서 포기했습니다. 그냥 에디터로만 써도 괜찮아요.

guybrush1의 이미지

뜯어본다는게 무슨 말인지는 잘 모르겠지만, Eclipse와 Vim에서도 (충분히) 툴을 입맛에 맞게 프로그래밍할 수 있습니다 (Vim의 경우는 IDE로는 좀 불편한 점이 있을수는 있겠습니다만)

Emacs쓰는 사람들 중에 심심치 않게 Emacs가 (해커를 위한) 최고의 에디터/IDE(!)라고 생각하고, Emacs를 써야 해커라고 생각하는 사람들이 있는데, 좀 웃기다고 봅니다.
사실, Emacs쓰는 분들 중에 해커가 많기는 합니다. 제가 아는, 메이저 오픈소스 프로젝트 리더도 쓰는데, 다른점은 그분은 그냥 자기가 지금까지 써와서 쓰는거고 세팅이나 그런거는 다른 사람 것을 카피해서 그냥 쓴다고 하더군요. (그리고 자기는 다른 사람에게 쓰라고 권하지 않겠다고 하더군요.)

저도 리습 프로그래밍을 할 때에는 emacs를 썼고 좋아하는 편이지만, emacs도 결국은 그냥 툴입니다. Emacs쓰는거랑 해커를 연관시켜서 이야기하는것은, 일부 맥 사용자들이 맥을 쓰는 것 자체에 대해서 (본인들이 특별하다고 느끼는) 자부심을 가지는 것과 비슷한 것 같네요.

johan의 이미지

무슨 뜻인지 잘 모르면 무의미한 답글을 다는 것보다는 스스로 답을 찾거나 공손히 물어야 배울 수 있습니다만, 정말 아무것도 모를 수 있다는 생각이 들어서 더 무의미할 수 있는 답글을 다시 답니다.

http://en.wikipedia.org/wiki/Hacker_(programmer_subculture):
The Jargon File, a compendium of hacker slang, defines hacker as "A person who enjoys exploring the details of programmable systems and stretching their capabilities, as opposed to most users, who prefer to learn only the minimum necessary."

Emacs는 "programmable system"이고 Elisp을 통해서 "stretching their capabilities" 가 됩니다. 대부분의 사람들은 그렇게 하지 않지만요(most users, who prefer to learn only the minimum necessary.) "해커"들이나 그런 것 좋아하고 자랑하죠. 이것이 꼭 좋다는 것은 아닙니다. 왜냐하면 일하다보면 곁길로 빠져서 돌아오지 않는 경우가 있기 때문이죠. 같이 일하는 사람중에 이런 사람들이 있어서 자주 원래 해야 할일을 이야기 해줘야 합니다(하지만, 정말 똑똑한 사람들이라 같이 일하면 재미있어요!)

http://en.wikipedia.org/wiki/Hacker_(hobbyist):
In home computing, a hacker is a person who heavily modifies the software or hardware of their computer system. It includes building, rebuilding, modifying and creating software (software cracking, demo scene) and electronic hardware (hardware hacking, modding) either to make it better, faster, give added features or to make it do something it was never intended to do.

또, Emacs는 위에서 지적한 대로 마구 자기 하고픈 대로 Elisp으로 프로그래밍 해버려서 개개인의 요구에 맞게 make it better, faster, give added features or to make it do something it was never intended to do 되어 골치아픈 라이브러리가 있을 수 있습니다.

요즘은 해커와 파워유저의 구분도 잘 못하는 사람들이 많아서 참 뭐가뭔지 모르겠네요. 해커가 해커를 보면 존경스러울 수도 있지만, 일반인이 보면 똘아이일수도 있는 겁니다. Emacs 쓴다고 다 해커가 아니라 위에 나열된 일들을 해야 해커라고 볼 수 있는 겁니다. 그냥 잘 쓰는 사람은 파워유저라고 하는 겁니다. 일반인들이 "그사람 해커야" 할 경우 대부분은 파워유저를 칭하는 경우가 많습니다. 해커가 하는 행위가 뭔지 이해하는 사람만이 해커를 알아볼 수 있는 거예요.

구조적으로 뜯어보기 힘들게 된 시스템은 상대적으로 해커 프렌들리 하지 않은 시스템 들이고, 만일 프렌들리 한 대체 시스템이 있다면 구태여 그런 시스템을 해킹해볼 이유가 없는 거예요. 즉, Emacs가 이미 해킹 프렌들리 한데 굳이 Vi를 해킹해볼 이유가 없다는 겁니다. 마찬가지 이유로 Linux가 있는데, 굳이 Mac이나 Windows를 해킹해볼 메리트가 없는 겁니다.

guybrush1의 이미지

명확하지 않았나본데, 저기서 무슨 말인지 모르겠다는 말은, 진짜 모르겠다는게 아니라 비꼬는 말입니다.

Emacs만 stretchable 한 시스템/에디터가 아닙니다. Eclipse에도 수많은 extension/plugin들이 있고, 많은 researcher들이 Eclipse를 이용해서
수많은 툴들을 만들고 있습니다. (제가 봤을땐 Emacs만큼 stretchable합니다)
Vim은 stretchable하다고 보기에는 약간 무리가 있기는 하지요. 뭐, 여기서 뭐가 낫네 비슷하네 하려고 쓴건 아니고, 처음 글에서 Emacs 광신도들에게서 종종 보이는 우월감(?) 이 보여서 좀 우스워서 썼네요.

그리고 저랑은 해커의 정의가 좀 다르군요. 저는 툴을 좀더 편하게 쓰거나 (Elisp등으로 코딩을 좀 해서) 다른 방식으로 이용하거나 하는것이 오히려 그냥 파워 유저라고 봅니다.
그렇게 툴을 좀 고치거나 하는것을 (간단한) 해킹이라고 부를수는 있겠지만, 그런 사람들은 제가봤을때 해커는 아닙니다. (최소한 그런것만 보고 해커라고 부를수는 없습니다)

해커는 그냥 뭘 뜯어보기를 좋아한다고 해커가 아니라, underlying 시스템에 대해서 꿰뚫고 있고 또 그 위에서 시스템을 디자인할 수 있어야 해커라고 부를 수 있습니다.
예를들면 Soft updates 를 디자인하고 구현한 McKusick이나, 최근에 JVM에 InvokeDynamic을 추가한 John Rose정도면 해커라고 부를만하지요.

무슨 elisp 코드 좀 짜서 편하게 쓴다고 해커라... 허.. CLOS 디자인을 좀 바꿔서 쓰는거면 모를까...

oppor의 이미지

결국 또 플레임이 되어버리네요.ㅋ

이맥스 관련글에 플레임이 없으면 좀 어색하다고 느낄 정도...

johan의 이미지

해커의 정의를 멋대로 바꾸건 말건 상관할 바는 아니지만, 다른 사람들과 소통하려면 최소한 그 정의는 명확히 알아야 합니다.

위의 글을 쭉 읽어보면 Emacs를 사용한다고 우월감을 갖거나 한다는 이야기는 없고, 그렇게 느꼈다면 자격지심이겠죠.

이미 이야기 했듯이 Vi나 Eclipse는 Emacs에 비해 메리트가 덜 한 겁니다. 그래도 해킹하는 사람 있겠지만, Emacs의 Gnus, Eliza, 등등과 같이 "순수한 즐거움"을 갖는 해킹은 아무래도 어려운 것이죠. 마치 Emacs는 Lego 블럭이 주어졌다면, Eclipse에서는 콘크리트 블럭, 시멘트, 삽, ... 등등이 주어진 것이고, Vi는 건물이 주어진 것과 같은 느낌이라고나 할까요?

CLOS 이야기가 나왔는데, CLOS는 MOP으로 구현되어서 OOP 해킹하기 좋은 구조입니다.

Common Lisp은 C++, Java, Python, Ruby 등등보다 해커 프렌들리 하기 때문에 여러가지 프로그래밍 언어 관련 해킹을 해볼수 있고 다양한 실험을 해볼 수 있습니다. 하지만 95%이상의 프로그래머들은 사용해보기는 커녕 알고 싶지도 않은 그런 시스템이예요. Emacs와 유사한 면이 있는 거죠.
프로그래밍 언어 해커라면 반드시 한번쯤 사용해봐야 할 시스템이지만, 대개의 경우 "이미 네가 원하는 언어가 있는데, 그게 A다. 왜 그 A를 쓰지 사서 고생을 하느냐"는 말을 듣게 됩니다. 해커는 개의치 않고 자신이 원하는 대로 할 것이고 (재미있기 때문에, 내부가 어떻게 작동하는지 알아내고 싶기 때문에, 새로운 자신의 아이디어로 프로그래밍 언어를 확장해보고 싶기 때문에) 일반인은 새로운 A를 배우게 됩니다. 그 A의 파워유저가 되는 순간, A의 마음에 안드는 부분을 고치고 싶어하지만 이미 그부분이 개선된 새로운 언어 B를 배우게 되고, ...

주어진 시스템을 스스로 뜯어서 바꿔보려고 하면 해커, 주어진 시스템을 매뉴얼대로 잘 사용하면 파워유저, 시스템이 뜯어서 바꿔보기 쉽게 되어있으면 해커 프렌들리 시스템, Emacs를 매뉴얼 대로 잘 사용하면 Emacs 파워유저, Emacs를 Elisp을 이용해서 자기 마음대로 바꾸면 Emacs 해커, 자기 마음대로 바꿔서 배포했는데 많은 사람들에게 도움이 되었으면 Emacs 수퍼 해커, 추종자들이 몰려들면 Emacs Guru, Emacs 구조를 통째로 바꿔버릴 수 있는 정도의 해킹이 가능하면 Emacs Wizard.
그렇지만 일반인이 보면 Z 에디터 사용하면 되는데 구닥다리 에디터를 쓰면서 지지고 볶는 똘아이들. 이렇게 원소나열식이면 좀 더 이해가 될지 모르겠네요.

Emacs가 Vi나 Eclipse보다 낫다 아니다, 혹은 해커가 파워유저보다 낫다 아니다의 문제가 아니라, 어떤 시스템이 해커에게 더 프렌들리하다 아니다의 이야기인 겁니다.
생각해보세요. 에디터의 경우에는 개발자들이 유저입장이 되는데, 그 유저들중 소수는 단순 유저입장에서 만족못하고 (스스로에게나 시스템에게 원래 의도와는 다른) 해킹을 시작하는 거예요. 이런 경우 당연히 해킹하기 좋은 구조를 갖는 시스템이 그렇지 않은 시스템보다 해커들 입맛에 맞는 겁니다. 이미 언급했지만, 실무에서 이게 꼭 바람직 한 것만은 아닙니다 (곁길로 가서 돌아오지 않는 경우가 왕왕 있어서).

해커는 어디 멀리 있고 무슨 거창한 시스템을 만든 사람만 해커가 아닙니다. 대부분의 사람들에게는 크고 작은 (혹은 숨어있는) 해킹 기질이 있는데, 문제는 그것을 추구할 시간, 돈, 추진력 등이 있느냐 없느냐 하는 거죠.

시스템을 한눈에 꿰뚫어 보기위해 얼마나 많은 소소하고 보잘것 없는 해킹을 해보았을까 상상해 보세요. 최소한 최초 몇번의 해킹은 대단한 아이디어가 아니라 그냥 순수 재미로, 명예나 돈이나 권력은 전혀 게의치 않고 스스로를 위해서 시작했을 겁니다. 마치 지금 여기 게시판 어딘가에 돌아다니는 무슨 구글 서치로 문장 만들기 같은 장난감 아이디어처럼.

guybrush1의 이미지

해커의 정의를 제멋대로 바꾼게 아니라, johan님이 생각하는 해커랑 제가 생각하는 해커가 다를 뿐입니다. (그리고 제 주위에 있는 많은 사람들도 제 정의에 가깝게 생각합니다)

Emacs를 사용한다고 우월감을 갖는다는 말을 했다는게 아니라, 그런 우월감이 글에서 나타난다는 말입니다. 그딴거에 자격지심같은거 없습니다.
저는 CMUCL, SBCL 을 사용하면서 (길지는 않지만) 1년 가까이 개발해 봤고(CLOS도 당연히 썼고), 그동안에는 계속 Emacs를 썼네요.

뭐가 낫네, 정의가 뭐네 그런게 중요한게 아니라, 문제가 뭐냐하면, Emacs/Lisp을 사용하는 적지 않은 사람들이 다른 시스템에 대해서 잘 알지도 못하고 충분히 써 보지도 않은 상태에서 제멋대로 어떤 툴이 어떠하네 저쩨서 안좋네 라고 한다는 겁니다. 언급한 Python이나 Ruby도 제대로 사용해보거나 해킹해 보려고 한 적은 있나요? Python과 Ruby는 highly reflective하기 때문에, 여러가지 아이디어를 실험해보기도 쉽고, "프로그래밍 언어 관련 해킹"을 해 보기도 쉽습니다. Python이나 Ruby 둘다 언어에 어떤 기능을 추가하려고 할 때 C로 구현하기 전에 Python과 Ruby로 각각 (쉽게) 구현해서 실험해본 다음에 C로 구현을 합니다. 특히 PyPy는 Python으로 구현이 되어 있어서, 조금만 실력이 있는 개발자라면 쉽게 아이디어를 테스트해볼 수 있습니다.

해커 프랜들리 하냐 안하냐도 상당히 애매한 겁니다. 예를 들어서 continuation을 Common Lisp에 구현하려면 lisp으로 깔짝거리거나 하는걸로는 불가능한데, 그럼 continuation 구현에 대해서 Common Lisp은 해커 프렌들리 한가요? 저는 프로그램의 소스가 오픈되어 있고, 라이센스가 까다롭지 않다면 누구나 해킹할 수 있고 그렇다면 해커 프렌들리 하다고 봅니다. 그리고 계속 '원래 의도와 다르게 (바꾸거나 프로그래밍해서)' 쓰는걸 해킹이라고 하는데, 확장언어가 구현되어 있다는 자체가 그렇게 프로그래밍 해서 툴을 입맛에 바꿔서 쓰라는 "의도"입니다. Vim에 script나, Eclipse의 확장 API, Firefox의 plugin API나 다 그런거고요.

저는 그리고 해킹이랑 해커를 따로 사용했습니다. 글좀 제대로 보세요. "최초 몇번의 해킹은 대단한 아이디어가 아니라 그냥 순수 재미로, 명예나 돈이나 권력은 전혀 게의치 않고 스스로를 위해서 시작했을 겁니다" 라고 하셨는데, 최초 몇번 해킹했다고 해서 그사람을 해커라고 보기는 어렵습니다. 그 사람이 해킹을 계속 해서 시스템을 보는 안목이 생긴다면 해커라고 불러도 좋겠지요.

참고로 저는 Emacs/Lisp 자체는 매우 좋아하는 편입니다. 개발자라면 Lisp(/Emacs), Smalltalk - 혹은 Self(/IDE), Prolog 는 한번쯤 꼭 배워야 한다고 봅니다.
다만 Emacs/Lisp쓰는 몇몇 사람들의 태도에 문제가 있다고 봅니다.

johan의 이미지

> 해커의 정의를 제멋대로 바꾼게 아니라, johan님이 생각하는 해커랑 제가 생각하는
> 해커가 다를 뿐입니다. (그리고 제 주위에 있는 많은 사람들도 제 정의에 가깝게 생각합니다)

Jargon file 정의 말고 자기들끼리 쓰는 정의대로 생각한다면 그렇게 생각하는 사람끼리 이야기를 주고 받으세요. 괜히 제대로 알고 있는 사람들 한테 이상한 사이비 같은 이야기 강요하지 말고.

Driving 하는 사람 -> driver
Diving 하는 사람 -> diver
Swimming 하는 사람 -> Swimmer
Playing 하는 사람 -> Player
Boxing 하는 사람 -> Boxer
Hacking 하는 사람 -> ???

> Emacs를 사용한다고 우월감을 갖는다는 말을 했다는게 아니라, 그런 우월감이 글에서
> 타난다는 말입니다. 그딴거에 자격지심같은거 없습니다.

자신이 그렇기 때문에 그렇게 느낄 뿐이겠죠. 해커나 해킹이 꼭 대단해야 할 필요는 없는 거예요. Makezine 보면 대부분이 생활 속 해킹이고 그런 이들이야 말로 진짜 해커입니다. 다시 말하지만, 해커나 해킹이 꼭 대단할 필요가 없어요.

> 저는 CMUCL, SBCL 을 사용하면서 (길지는 않지만) 1년 가까이 개발해 봤고
> (CLOS도 당연히 썼고), 그동안에는 계속 Emacs를 썼네요.

그러시군요. 저는 Emacs 최소한 20년 정도, CL 15년 정도 써봤습니다. 매우 똑똑한 사람 아닌 다음에야 1년 정도 갖고 CL의 진수를 말하기엔 택도 없죠. 최소한 5년 intensive하게 써본다면 모를까.

> 뭐가 낫네, 정의가 뭐네 그런게 중요한게 아니라,

토론이나 자기 주장에 있어서 정의가 서로 다른데 뭔 할말이 있겠습니까? 특히 이미 잘 알려진 정의 이외의 정의를 주장하려 한다면, 신뢰할 수 있는 정확한 출처를 대보세요.]

> 문제가 뭐냐하면, Emacs/Lisp을 사용하는 적지 않은 사람들이 다른 시스템에 대해서 잘 알지
> 도 못하고 충분히 써 보지도 않은 상태에서 제멋대로 어떤 툴이 어떠하네 저쩨서 안좋네 라
> 고 한다는 겁니다.

그래서 15-20년 사용해본 제가 충분히 Emacs나 Lisp을 사용해 보지 않은 상태라는 건가요? 재미있는 발상이군요. 그러시는 본인은 얼마나 충분히 사용해 보셨나요?
믿거나 말거나 대부분의 문제는 다른 사람에게 있는 것이 아니라 스스로에게 있답니다. 남에게서 답을 찾으려고 하지말고, 스스로에게서 답을 찾아보세요. 즉, 자기자신을 "해킹"해 보세요. 많은 발전이 있을 겁니다.

> 언급한 Python이나 Ruby도 제대로 사용해보거나 해킹해 보려고 한 적은 있나요?

다행히도 사용해보지 않았습니다. 동료중에 전향한 Python 해커가 있어서 충분히 이야기는 들었습니다. Ruby는 조금 사용해 보았는데, 유저로써는 편할 수 있겠지만, 해킹하기에는 불편하더군요. 이미 저같이 닳고 닳은(?) 사람에게 "순수한 재미"를 느끼게 해주기엔 부족한 프로그래밍 언어였답니다. (저와 달리 신선한 사람들에게는 메리트가 있을 겁니다)

> 해커 프랜들리 하냐 안하냐도 상당히 애매한 겁니다.

일단 Programmable 하면 해커 프렌들리 한 겁니다. 블랙박스 하나 달랑 있고 아무 것도 손댈 수 없는 시스템은 그렇지 않겠죠. 거기에 얼마나 introspective 하냐가 추가될 수 있습니다. 소스코드가 있다면 뭐가 어렵겠습니까? 소스코드 없이 프로그래밍 언어를 확장해 본 적이 있습니까? 소스코드 없이 프로그래밍 언어의 버그를 고쳐본 적이 있습니까? 프로그래밍 언어의 경우라면 그런 것이 가능한 시스템일 수록 해커 프렌들리 한 겁니다.

횡설수설 하고 있는 것 스스로 느끼죠? 여기서 그만 해야 추해지지 않습니다. 제대로 다시 충분히 알게 된 후 이견이 있으면 새로운 글타래를 달아보세요. 답글할 가치가 있으면 그때 다시 보기로 하죠.

madman93의 이미지

제 개인적으로는 johan 님의 생각에 전적으로 동감합니다.
---------------------------------------------
git init
git add .
git commit -am "project init"
---------------------------------------------

---------------------------------------------
git init
git add .
git commit -am "project init"
---------------------------------------------

theswlee의 이미지


이 글을 쭉 보고 나니 Emacs를 써 보고 해커가 되고 싶긴 하는데...

> 그래서 Emacs는 대부분의 사람들에게는 맞지 않는 개발환경임에 틀림없습니다 - 소수를 위한 개발환경이고 그 특별한 소수가 존재하는 한 계속 발전할 개발환경입니다.

이 부분이 너무 걸리네요 -0-;;
가벼운 마음으로 시작해도 괜찮은 개발환경인지...

---------------------------------------------------------------------------
문장은 거기에 쓰이는 언어의 선택으로 결정된다.
평소에 쓰이지 않는 말이나 동료들끼리만 통하는 표현은 배가 암초를 피하는 것처럼 피해야 한다.


---------------------------------------------------------------------------

문장은 거기에 쓰이는 언어의 선택으로 결정된다.
평소에 쓰이지 않는 말이나 동료들끼리만 통하는 표현은 배가 암초를 피하는 것처럼 피해야 한다.

JuEUS-U의 이미지

저도 저 문장이 계속 거슬렸는데, '특별한 소수'는 절대로 아닙니다 - _-)
Emacs도 본질적으로는 VS나 Eclipse 같은 한낱 IDE에 불과합니다.
따라서 Emacs를 쓰는게 해커가 되는 길도 아니며, 꼭히 자부심 가질일도 아닙니다. (애정은 가질수 있겠죠.)

theswlee의 이미지


아 제가 괜한 고민을 한 것 같네요~
대체 어떤 녀석인지 한번 겪어봐야겠습니다.

---------------------------------------------------------------------------

문장은 거기에 쓰이는 언어의 선택으로 결정된다.
평소에 쓰이지 않는 말이나 동료들끼리만 통하는 표현은 배가 암초를 피하는 것처럼 피해야 한다.


---------------------------------------------------------------------------

문장은 거기에 쓰이는 언어의 선택으로 결정된다.
평소에 쓰이지 않는 말이나 동료들끼리만 통하는 표현은 배가 암초를 피하는 것처럼 피해야 한다.

guybrush1의 이미지

글을 조각내서 답변하는것은 전체 문맥에서의 의미에 대한 답을 못하기때문에 별로 좋아하지는 않지만, 먼저 그렇게 하셨으니까
저도 그렇게 하지요.

>> 해커의 정의를 제멋대로 바꾼게 아니라, johan님이 생각하는 해커랑 제가 생각하는
>> 해커가 다를 뿐입니다. (그리고 제 주위에 있는 많은 사람들도 제 정의에 가깝게 생각합니다)

>Jargon file 정의 말고 자기들끼리 쓰는 정의대로 생각한다면 그렇게 생각하는 사람끼리 이야기를 주고 받으세요. 괜히 제대로 알고 있는 사람들 한테 이상한 사이비 같은 이야기 강요하지 말고.

글쎼요, 해킹 한두가지 했다고 해커로 생각한다면 그렇게 생각하세요. 그렇게 생각할 수도 있겠네요.
C로 hello world 짜고 C 프로그래머라고 생각하는거나, Lisp REPR에서 간단한 계산 하나 한 다음에 Lisp Programmer라고 생각하는거랑 비슷하다고 보지만...

>> Emacs를 사용한다고 우월감을 갖는다는 말을 했다는게 아니라, 그런 우월감이 글에서
>> 타난다는 말입니다. 그딴거에 자격지심같은거 없습니다.

>자신이 그렇기 때문에 그렇게 느낄 뿐이겠죠.

뭐 아니라고 하는데 계속 그렇게 말한다면야....

>해커나 해킹이 꼭 대단해야 할 필요는 없는 거예요. Makezine 보면 대부분이 생활 속 해킹이고 그런 이들이야 말로 진짜 해커입니다. 다시 말하지만, 해커나 해킹이 꼭 대단할 필요가 없어요.

여기에는 어느정도는 동의합니다만 시스템에 대한 안목이 있어야 해커라고 부를만하다는 생각에는 큰 변함은 없네요.

>> 저는 CMUCL, SBCL 을 사용하면서 (길지는 않지만) 1년 가까이 개발해 봤고
>> (CLOS도 당연히 썼고), 그동안에는 계속 Emacs를 썼네요.

> 그러시군요. 저는 Emacs 최소한 20년 정도, CL 15년 정도 써봤습니다. 매우 똑똑한 사람 아닌 다음에야 1년 정도 갖고 CL의 진수를 말하기엔 택도 없죠. 최소한 5년 intensive하게 써본다면 모를까.

왜 저 문장을 썼는지 파악을 못하시는군요. 제가 CL의 진수를 뭐 잘 알고 있다는 것을 주장하려는게 아니라(오히려 길지 않게 썼다고 명확히 밝혔고), CL에 어느정도 경험이 있는 상태에서 이야기한다는걸 알려주려는 겁니다. 아래 말씀하신것처럼 Python, Ruby 등등 다른 언어/시스템을 별로 잘 알지도 못하면서 함부로 말하는게 아니라...
그리고 생각하시는것보다는 제가 더 CL에 대해서 알고 있다고 생각합니다. 뭐, AMOP 내용정도는 잘 파악하고 있습니다.

>> 뭐가 낫네, 정의가 뭐네 그런게 중요한게 아니라,

>토론이나 자기 주장에 있어서 정의가 서로 다른데 뭔 할말이 있겠습니까? 특히 이미 잘 알려진 정의 이외의 정의를 주장하려 한다면, 신뢰할 수 있는 정확한 출처를 대보세요.]

Wikipedia를 출처로 대는걸 별로 좋아하지는 않지만, 먼저 wikipedia를 썼으니... http://en.wikipedia.org/wiki/Hacker_%28computing%29 저기서 두번째 bullet point가 제가 생각하는 해커의 정의입니다. 세 번째가 johan님이 말씀하시는 hobbyist로서의 정의인데, 뭐 그 정의가 좋으면 그거 쓰세요. 첨에도 언급했듯이, 생각이 다르다는것을 말씀드린것 뿐입니다.

>> 문제가 뭐냐하면, Emacs/Lisp을 사용하는 적지 않은 사람들이 다른 시스템에 대해서 잘 알지
>> 도 못하고 충분히 써 보지도 않은 상태에서 제멋대로 어떤 툴이 어떠하네 저쩨서 안좋네 라
>> 고 한다는 겁니다.

>그래서 15-20년 사용해본 제가 충분히 Emacs나 Lisp을 사용해 보지 않은 상태라는 건가요? 재미있는 발상이군요. 그러시는 본인은 얼마나 충분히 사용해 보셨나요?
>믿거나 말거나 대부분의 문제는 다른 사람에게 있는 것이 아니라 스스로에게 있답니다. 남에게서 답을 찾으려고 하지말고, 스스로에게서 답을 찾아보세요. 즉, 자기자신을 "해
>해 보세요. 많은 발전이 있을 겁니다.

진짜 이해를 잘 못하시거나, 글을 읽는데 성의가 없으시군요. 저말은 Emacs/Lisp을 잘 알지 못하거나 충분히 써 보지 않았다는게 아니라, "다른 시스템"들을 많이 써보지 않았다는 말입니다.

>> 언급한 Python이나 Ruby도 제대로 사용해보거나 해킹해 보려고 한 적은 있나요?

>다행히도 사용해보지 않았습니다. 동료중에 전향한 Python 해커가 있어서 충분히 이야기는 들었습니다. Ruby는 조금 사용해 보았는데, 유저로써는 편할 수 있겠지만, 해킹하기에는 불편하더군요. 이미 저같이 닳고 닳은(?) 사람에게 "순수한 재미"를 느끼게 해주기엔 부족한 프로그래밍 언어였답니다. (저와 달리 신선한 사람들에게는 메리트가 있을 겁니다)

이런데서 오만함이 드러난다는 겁니다. 저같으면 누군가에게 듣고만 (혹은 짧은 경험으로만) 뭔가를 판단하지는 않겠습니다. 그리고 그 전향했다는 분, johan님의 정의로 "해커"라는거지요?

>> 해커 프랜들리 하냐 안하냐도 상당히 애매한 겁니다.

> 일단 Programmable 하면 해커 프렌들리 한 겁니다. 블랙박스 하나 달랑 있고 아무 것도 손댈 수 없는 시스템은 그렇지 않겠죠. 거기에 얼마나 introspective 하냐가 추가될 수 있습니다. 소스코드가 있다면 뭐가 어렵겠습니까? 소스코드 없이 프로그래밍 언어를 확장해 본 적이 있습니까? 소스코드 없이 프로그래밍 언어의 버그를 고쳐본 적이 있습니까? 프로그래밍 언어의 경우라면 그런 것이 가능한 시스템일 수록 해커 프렌들리 한 겁니다.

일단 답은 예, 아니오 이지만, 컴파일러 일을 조금이라도 해 봤다면 그런게 그렇게 대단해 보이지는 않습니다.
그래서, garbage collector에 버그가 있으면 CL에서는 소스코드 없이 버그를 고칠 수 있습니까?

> 횡설수설 하고 있는 것 스스로 느끼죠? 여기서 그만 해야 추해지지 않습니다. 제대로 다시 충분히 알게 된 후 이견이 있으면 새로운 글타래를 달아보세요. 답글할 가치가 있으면 그때 다시 보기로 하죠.

제가 봤을때는 별로 그렇게 생각하지 않습니다만, 뭐 좋을대로 생각하세요. johan님의 답글도 별로 읽을 가치가 있지는 않군요.

hanuljyw의 이미지

저는 guybrush1 님의 말에~ 전적으로 동감합니다.
johan 님은 이해도 자기맘대로 대충 이해하시고, 말투도 자신감에서 나오는 막말일수도 있겠지만 (제가 보기엔 그냥 허새로 느껴지네요 @ @;;)
남은 1년을 경험해도~ 짧은 경험이니 말할자격이 없고, 본인은 경험하지도 않고, 남의 이야기만 듣고 또는 잠깐 해보고 본인말이 답인듯한 오만함이 느껴집니다.
나이도 지긋하신듯 한데, 말투에서도 너무 고지식한 본인 지식만이 옳고, 남의 말에는 전혀 귀를 기울이지 않는 좋지않은 성격의 소유자이신듯한 느낌이드네요.

madman93의 이미지

^.^

---------------------------------------------
git init
git add .
git commit -am "project init"
---------------------------------------------

handrake의 이미지

한번 Terminus 글꼴 써보는 것은 어떤가요? 가독성이 좋아서 전 아주 만족 중입니다.

gurugio의 이미지

감사합니다. 폰트 설치하느라 잠깐 애먹었지만
설치하고나니 가독성이 정말 좋습니다.

----
섬기며 사랑하면 더 행복해집니다.
몸에 좋은 칼슘이 듬뿍담긴 OS 프로젝트 - 칼슘OS http://asmlove.co.kr/wiki/wiki.php/gurugio

M.W.Park의 이미지

svn은 그냥 M-x svn-status 하시면 대충 감이 오실겁니다.

몇가지 지금 떠오르는 것(많이 쓰는 것)만 써보자면... 파일 리스트에서
= 멋진 diff 화면이 뜹니다.
* m 모든 변경된 파일 선택
c 선택된 파일(들) commit. (commit log 쓰는 버퍼가 열림. 로그 작성후 C-c C-c 하면 실제로 commit됨)

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

withtw의 이미지

이맥스 최고.
VS2005쓰는데 타이핑 하다보면 이맥스와 비교되서 답답한게 한두번이 아님.
특히 책갈피 지정해 두고 이리저리 이동할때 작업 능률이 심하게 저하.
그래서 타이핑이 좀 많아진다 싶으면 단축키로 이맥스 전환해서 작업.
VS2005환경 자체를 이맥스로 옮기지 못한게 매번 아쉬움.

klenui의 이미지

예전에 vs2005와 결합을 시도해본적이 있습니다. 지금은 리눅스 환경에서 작업하기 때문에 더이상 사용하지 않습니다만..

정보 공유차원에서 적어보면, cl.exe는 PATH, LIB, INCLUDE만 잡혀 있으면 잘 동작합니다. sln파일이나 vcproj파일은 vcbuild라는 프로그램으로 빌드가능하고 xml코드로 되어 있어서 직접 수작업 수정이 가능합니다. resource는 vc2005안에 cui용 resource compiler가 있으니 그걸 쓰면 되구요.. 요컨대 순수 emacs환경에서 vs2005 개발 가능합니다. cdb붙여서 디버깅도 되지요.. 노가다가 필요해서 그렇지..
한가지 의아한건 오픈소스의 방대한 개발범위로 볼때 제가 못찾은 건지.. 이런 프로젝트를 본적이 없다는 겁니다.

withtw의 이미지

VS2005의 인텔리센스 기능도 가능할까요?

klenui의 이미지

저는 개인적으로 cscope이상을 안쓰고 인텔리센스 대신 자동완성기능(M-/)만으로 만족하며 살고 있어서 잘모르겠습니다만..

cedet 패키지의 smart completion이 같은 거라는데, cedet 설치하다 귀찮아서 포기한 저로서는 역시나 잘 모르겠습니다. 괜찮으시면 써보시고 코멘트 부탁드릴께요..

http://cedet.sourceforge.net/

hwiorb의 이미지

cedet를 1번 써봤는데...
(계속 설치를 실패하다가..)
느리더군요.

그리고, cedet 설치는 이분 글을 참고하시면 될겁니다.
http://kldp.org/book/export/html/99132

nil.

hwiorb의 이미지

프로젝트를 하면서, 곁작업으로 투자하는 시간보다,
차라리 불편함을 감수하는게 나을것이다 라고 생각하지 않을까 싶네요.

간혹 생각이 드는거지만, vs 시리즈에 이맥스 바인딩이 생길정도로 사용하는 사람들이 많다면,
이런 프로젝트가 지금쯤 3~4개 정도 나와서, 베타과정을 충분히 거쳤을텐데, 그다지 얘깃거리가 없는걸 보면... 뭐..

nil.

widgie의 이미지

VS에도 emacs 키 바인딩 있을텐데요

달리나음의 이미지

계속 없는 걸 쓰게되어 포기하였습니다.

litdream의 이미지

혹시 저처럼, 왼쪽 Ctrl 키를 CapsLock 과 바꾸지 않고 Emacs 사용하시는분 계신가요? 이맥스 쓴지 3년정도 되었습니다.

처음에는 다들 그렇듯이, Ctrl 때문에 왼쪽 새끼손가락이 아퍼서, CapsLock 과 바꾸어 썼습니다. 그러고는 처음에는 좀 괜찮다가, 바뀐 위치의 Ctrl 을 사용해도 새끼손가락이 또 아프더군요. 손가락 관절이 약한건지, 뭐 다른 요인이 있겠지만, 결국 다시 Ctrl 은 원상복귀 되고, 대신 새끼손가락을 쭈욱 펴고 ctrl 을 누르는 방법으로 적응했습니다.

다른 키보드에서 쓰기도 수월하고, 나름 괜찮더군요.
손모양은 좀 이상하네요.

삽질의 대마왕...

삽질의 대마왕...

siabard의 이미지

저는 이제 2년 조금 되어서 이제 단축키 좀 적응해가는 단계입니다.

Caps lock 을 쓰면 희안하게 엄지손가락을 많이 쓰게되는데.. 엄지손가락이 좀 아퍼서..
그냥 Ctrl 키만 쓰고 있습니다..

익숙해지면 별 생각 안나더군요.. 인간의 적응력이란.. 대단합니다.

--
새로움을 느끼기에 삶은 즐겁다..
모험가 아돌 크리스틴을 꿈꾸며..
Sia..

새로움을 느끼기에 삶은 즐겁다..
모험가 아돌 크리스틴을 꿈꾸며..
Sia..

areios의 이미지

저는 Ctrl 키를 손바닥으로 누릅니다.;

게임 할때도 그렇고 코딩할 때도 그런데 제가 이상한건가요?;

sephiron의 이미지

원래 자리의 ctrl의 높이를 키우고 위치를 조금 조정하면 쓸만한 레이아웃이 하나 더 나올 수도 있을 것 같습니다.

snowall의 이미지

안타깝지만 노트북 키보드에서는 그렇게 할 수가 없지요.ㅜ_ㅜ

--------------------------
피할 수 있을때 즐겨라!
http://snowall.tistory.com

피할 수 있을때 즐겨라! http://melotopia.net/b

stypr의 이미지

.

isty2e의 이미지

hhk를 쓰거나 바인딩이 돼 있을 때는 a 왼쪽에 컨트롤이 있어서 새끼손가락으로 누르지만, 보통 다른 컴퓨터를 쓸 때는 새끼손가락이 붙어 있는 관절부로 누르지요.

obbaya의 이미지

폴아웃이나 플레인 스케이프 토너먼트 같은 게임을 동경하지만

조금 플레이를 하다보면 결국 디아블로로 돌아가버리는 경우랄까요...

라이트지만 HHK를 구입하고 이번에야말로 이맥스를 내 것으로 만들겟노라 시작했지만

결국은 vi xxx.cpp......

어딘가에 꾹 박혀있는 이맥스에 대한 로망을 이제는 버려야겠다고 다짐한 어제였습니다...

진입장벽을 넘는데 실패한 것이 아니라

이맥스를 사용하기 위해서는 선천적인 능력이 필요하다고... 난 그게 없다고...

결론을 내버렸네요.

스스로 vi를 사용하기 위해 태어난 사람이라 노래 불러보지만... 어딘가 아련해지는 ㅜ.ㅜ

klenui의 이미지

일본에서 충동구매한 "Emacs 사전"이라는 책이 설명이 잘되어 있는 것 같은데.. 아직 번역서가 없는 것 같네요..

http://www.amazon.co.jp/Emacs-%E8%BE%9E%E5%85%B8-DESKTOP-REFERENCE-%E4%BD%90%E8%97%A4/dp/4798110604/ref=sr_1_3?ie=UTF8&s=books&qid=1258425427&sr=8-3

혹시 이책 번역서 나왔는지 알고 계신분 있나요..?

gurugio의 이미지


emacs에서 잘 쓰고 있는 기능을 소개합니다.

VIM도 같은 기능이 있다는걸 알지만
왠지 2%불편해서 잘 활용을 못했던 것들이었습니다.
emacs가 무조건 우월하다는게 아니라 다른 분들 참고하시라고 기록을 남깁니다.
저도 VIM만 좋다고 생각했다가 리습공부하면서 어쩔수 없이 써보게됬다가 만족하게 되었습니다.

1. 버퍼 창 열기
vim에서는 창을 하나 더 열면 그 창을 분할할수는 있어도 백그라운드?로 숨기는 것을
못했습니다.(기능은 있겠지만 제가 몰랐습니다.) 그런데 emacs는 새로 파일을 열면
이전 파일은 백그라운드로 숨겨지고, 나중에 다시 열수 있고, 여러개의 파일을
동시에 편집할때 좀더 편리하게 쓰고 있습니다.

2. svn-status
vim에서는 터미널을 하나 더 열어서 svn 명령어로 썼다면 지금은 svn-status를 실행하고
emacs안에서 diff뜨기, 업데이트 등 GUI가 있는 것처럼 쓰고 있습니다.
저는 소스를 고칠때마다 diff를 떠서 리뷰를 올려야하는데 정말 편리하게 쓰고 있습니다.
emacs에서 diff를 떠서 확인하고 파일로 저장하기까지가 편리합니다.

3. compile
vim에서는 제가 설정을 잘 못해서 빌드후 결과 화면이 보기 불편했습니다.
세로로 2개 분할해서 편집하다가 빌드하면 결과 화면이 한쪽 화면의
아래에 작게 나타나서 너무 화면이 작았습니다. emacs에서는 새롭게 창이 분할되고
창도 크게 열려서 좋네요.

4. global
cscope를 이용한 태깅은 vim이 더 편리하다고 생각했는데
global을 설치하니까 비슷해졌습니다.

현재는 테스트 서버에 접속해서 작업할때는 emacs가 없는 경우가 많아서
vim을 쓰는데 emacs+ftp를 이용하는 방법이 있다던데 그걸 한번 써봐야겠습니다.

----
섬기며 사랑하면 더 행복해집니다.
몸에 좋은 칼슘이 듬뿍담긴 OS 프로젝트 - 칼슘OS http://asmlove.co.kr/wiki/wiki.php/gurugio

youlsa의 이미지

emacs+ftp는 tramp인지 ange인지 하는걸로 구현이 되어 있는데요,
사용방법은 간단합니다. 파일 여는 명령(ctrl-x ctrl-f) 한 다음에

/youlsa@hahaha.hohoho.com:

이렇게만 치면 디폴트로 정해진 프로토콜(보통 scp, ssh) 써서 해당 호스트의 홈디렉토리를 dired 창으로 열어줍니다.

/ftp:youlsa@hahaha.hohoho.com:/home/youlsa/work/test/a.c

이런 식으로 프로토콜이나 디렉토리명 또는 파일명을 명시해줘도 되구요... 프로토콜은 ssh, scp, ftp, telnet 같은게 가능하고요.
일단 연 다음에는 거의 로컬 파일과 다름 없이 사용이 가능합니다.

=-=-=-=-=-=-=-=-=
http://youlsa.com

=-=-=-=-=-=-=-=-=
http://youlsa.com

auditory의 이미지


저도 vi에서 emacs로 갈아타는 중이긴 합니다만,

emacs는 "통합" 환경에서 강점이,
vi는 개별 파일의 편집에서 강점이 있는것 같습니다.
(개인적인 선호이니 반박은 사절.. ^^)

간단한 파일을 보는 것은 아직도 습관적으로 vi filename을 하게되서.
vi를 emacs로 alias 시킬까도 생각 중입니다.

vi기능 중 emacs에서 제일 아쉬운 기능은 . 이더군요..

@ 아시겠지만 버퍼창열기는 탭이라는 이름으로 오래전부터 vi에서도 디폴트로 지원해 왔습니다.
저는 탭간 이동이 좀 불편하고, 같은 파일이 다른 탭에서 다시 열리는 점이 불만이었는데,
이런것도 찾아보면 해결 할 수 있었으리라 봅니다.

dl3zp3의 이미지

Emacs에서 .에 가장 가까운 기능은 C-x z와 C-u같습니다.

사용 예:

C-d C-x z z z

C-u C-d

C-u C-u C-d

C-u 6 C-d

kiwon의 이미지

언급하신 것도 좋지만, 전 키보드 매크로를 사용합니다. 매크로라는 성질이 그렇듯 행동이 명백해서 좋아요.
키보드 매크로 시작: C-(
<반복하고 싶은 작업>
키보드 매크로 종료: C-)
C-x e e e e e ........... (반복하기)

esrevinu의 이미지

viper-mode + vimpulse 가 해답입니다.^^
키 방식은 vim이 더 좋아서 포기 못하겠더군요.
그래서 emacs에서 vimpulse를 설정해서 씁니다.
http://www.emacswiki.org/emacs/vimpulse.el
최신 버젼은 많이 좋아져서 거의 vim과 똑같습니다.
설정 방법은 vimpulse.el 안에 있습니다.
추가: 설정 중에서 (setq vimpulse-experimental nil) 주석처리하는 게
좋을 것 같습니다. 이것 때문에 뭐가 잘 안 되었는데 기억이 안 나네요.

vim 쓰시다가 emacs로 전향하시는 분은 이걸 쓰시는 것이
좋을 것 같습니다. emacs 자체 키도 그대로 쓸 수 있으니까
완전 emacs로 옮기는 중간에 쓸 수도 있고 vim 키가
더 낫다고 느끼면 계속 쓰는 것도 좋을 것 같습니다.

동작 반복하는 것과 취소하는 것이 vim처럼 됩니다.

areios의 이미지

혹시 국내 Emacs 관련 서적 괜찮은거 없을까요?

온/오프라인 서점을 다 뒤져봤는데 절판되거나 원서밖에 못찾겠네요.

꼭 하나쯤 소장하고 싶은데 추천하시는 책이 있으시거나 중고로 파실 수 있으신분 계신가요?^-^

참고로 Emacs로 C++개발 방법이 소개되어있었으면 좋겠습니다~

leeted의 이미지

emacs에 흥미를 갖느니 좀더 본질적인 문제를 고민하라고 충고하겠지만.
그냥 멋있어보여서 시작했고, 현재도 쓰고 있음.

lifthrasiir의 이미지

더 좋은·나은 편집기에 관심을 가지는 건 키보드에 관심을 가지는 것과 똑같은 행동이라고 생각합니다. 좋든 싫든 하루 종일 키보드에 손을 대고 있는 시간은 충분히 길고, 마찬가지로 편집기를 쓰는 시간도 충분히 기니까요. 그 관심이 flamewar까지 가지 않는 한 자신이 매우 오랜 시간 사용하는 것에 대해 좀 더 개선해 보려고 하는 행동 자체는 전혀 문제가 없다고 봅니다.