소스 편집기의 단축키는?

mr.lee의 이미지

콘솔에서의 대표적인 소스 편집기로 emacs 와 vim 이 있는데.. 에디팅 단축키로는 둘 중에 어떤것이 더 편하고 효율적이라고 생각하시는지요? (전체기능이 아닌 편집관련 단축키 부분만)

콘트롤키를 capslock 으로 대체한다던지 하는 키맵핑을 사용하는것까지 고려해서 말이지요.

전 vim이 더 효율적인것 같다고 느끼고 있긴 합니다만.. emacs를 좀 더 많이 써보면 또 생각이 달라질지도 모르죠.

preisner의 이미지

오호~~
올만에 올라온 VIM & emacs 입니다.
검색해 보시면 글이 있을 겁니다.
vi & emacs는
Linux & Windows,
gnome & KDE 처럼 아주 치열한 논쟁이 발생합니다. :lol:

쉽게 말씀드려서
여기서 피해야 할 질문이라는 거죠.
검색을 해보시는게 좋지 않을까 합니다...

avelose의 이미지

불을 지펴 볼까요.
막강 VIM VIM최고~~

'현실은 수학으로 표현할 수 없다.'
'수학은 거짓의 학문이다.'
'난 수학이 정말 싫다.'

zeon의 이미지

SaNha wrote:
콘솔에서의 대표적인 소스 편집기로 emacs 와 vim 이 있는데.. 에디팅 단축키로는 둘 중에 어떤것이 더 편하고 효율적이라고 생각하시는지요? (전체기능이 아닌 편집관련 단축키 부분만)

콘트롤키를 capslock 으로 대체한다던지 하는 키맵핑을 사용하는것까지 고려해서 말이지요.

전 vim이 더 효율적인것 같다고 느끼고 있긴 합니다만.. emacs를 좀 더 많이 써보면 또 생각이 달라질지도 모르죠.

느낌일 뿐입니다.
뭐든 익숙한게 최고.......이지만

그런 의미로 이번 기회에 완전히 emacs로 전향해 보심이 어떨지요?
emacs없는 리눅스는 안꼬 없는 띤빵 느낌이 들지도.. :twisted:

여친이 길르는 용..

khris의 이미지

kate(KDE기본 편집기) 최고... :roll:

───────────────────────
yaourt -S gothick elegant
khris'log

SoftOn의 이미지

익숙한게 짱~

barbarianmonk의 이미지

파이어 폭스에서

검색한답시고 control - s orz..

이멕스는 중독입니다.. 조심하시길...

nahu5의 이미지

이맥스는 편집기 그 이상입니다...

진정한 편집기는 역시 Vi.............m
~
~
~
~
~
~
~
:wq

다크슈테펜의 이미지

nahu5 wrote:
이맥스는 편집기 그 이상입니다...

진정한 편집기는 역시 Vi.............m
~
~
~
~
~
~
~
:wq


Vi도 편집기 그 이상입니다...
진정한 편집기는 역시 pico...........

^x

인생이란게 다 그런게 아니겠어요....? 뭘(?)
http://schutepen.egloos.com

kyano의 이미지

오래전부터 내려오는 이야기가 있습니다...

이맥스 안쓰면 야만인이라고...

이맥스가 지존입니다... :twisted:
날씨도 추워지는데 불을 활활지펴보아요~

일단 명령어모드와 편집모드가 따로 존재하지
않는다는 것에서 vi(m)과 emacs를 둘 다 처음 접하는
사용자에게는 더 편리하지 않을까 합니다...

--
Have you ever heard about Debian GNU/Linux?

harace의 이미지

저는 VIM, emacs 둘 다 사용합니다. 저같은 분들 꽤 될껍니다.
그런데 emacs... 한번 제대로 맛들이면 담배처럼 끊기 어려워요 :oops:

끝으로 저도 불지르는데 한 몫하기위해....
;;
;;
;;
;;
;;
;;
;; emacs 최고!!!! :twisted:

바라미의 이미지

이맥스가 더 접하기 힘들어 보여요.
일단 설치하기부터 겁나게 뭘 뭘 많이 깔고 그러길래.. 엄두가 못나서 설치 못하고 있습니다 .....

prolinko의 이미지

한글 자료가 vim에 비해서 부족하다는 점만 빼고는 (그래도 찾아보면 있을만한 것은 다 있음. 영어자료는 널렸음), emacs가 vim에 비해서 특별이 번거롭거나 어려운 점은 없는 것 같습니다. 다만 이럴땐 어떻게 해야하지 하는 질문에 대한 답을 쉽게 얻기가 힘들어서 금방 포기하는 것 같습니다. emacs를 정도대로 익히면 그리 오래 걸리지 않아서 다른 도구들 보다도 충분히 효율적으로 활용할 수 있게 됩니다.

제가 권해 드리고 싶은 것은 emacs를 처음 시작할 때 기초적인 편집 기능을 익히는 것도 중요하지만, 풍부한 자체 내장 도움말 기능(info)을 활용하는 방법을 확실히 익혀놓으면 언제라도 필요한 기능을 찾아 볼수 있어서, 금방 사용을 포기하지 않고 꾸준이 사용할 수 있게 됩니다. 30분만 투자하면 기본 사용법과 도움말 사용법은 충분히 익힐 수 있습니다. emace 매뉴얼 만 찾아봐도 왠만한 필요사항은 목차에서 쉽게 찾을 수 있는데, 이 manual이 자체 도움말 내에 info형태로 내장되어 있습니다.

yglee의 이미지

윈도우에서는 vim이 emacs보다 한글지원이 더 잘됩니다.

윈도우에서 vim은 특별한 설정없이도 한글이 잘써지는데 emacs 윈도우 버전은 당췌 한글 설정을 하는법을 모르겠습니다. OTL

그래서 vim...

monpetit의 이미지

gnoyel wrote:
윈도우에서는 vim이 emacs보다 한글지원이 더 잘됩니다.

윈도우에서 vim은 특별한 설정없이도 한글이 잘써지는데 emacs 윈도우 버전은 당췌 한글 설정을 하는법을 모르겠습니다. OTL

그래서 vim...


요새 나오는 win32용 emacs는 별다른 설정 없이도 한글 사용에 전혀 문제 없습니다. 보통 win32에서 emacs를 설치한 후 인터넷 뒤져서 유닉스용 .emacs로 설정하곤 하는데 그럴 필요 없습니다. 요새는 글꼴 설정도 알아서 적당한 걸로 해 줍니다.
http://ourcomments.org/Emacs/EmacsW32.html
바라미의 이미지

음.. 자꾸 이맥스다 최고다 하는데..
이맥스가 더 좋은 부분이 있을것이고, vim 이 더 좋은 부분이 있을것입니다.
이맥스라면 전문적인 문서편집을 하기에 아주 적합할 것입니다. 관련 기능도 아주 아주 많고요. 프로그래밍 IDE 역할까지 톡톡히 해내고 있습니다. 하지만 무겁지 않습니까?

반면에 vim 은 이맥스보다 쓰기는 불편하지만 그런데로 강력하고. 쓸만하고 왠만한 작업은 다 할수 있습니다. 그러나 이맥스보다는 못하겠죠. 할수는 있지만 엄청난 삽질이 필요하죠. 그렇지만 vim 은 가볍다는 장점이 있습니다. 아주 간단한 문서 편집하기 위애 이맥스를 쓰시겠습니까? vim 으로 하시겠습니까?

물론 vim 이 아주 간단한 것만 하라는것도 아니고 이맥스로 간단한 작업은 절대 하지말라는 것도 아니지만 서로 장단점이 있고 적용 분야가 있습니다.
윈도우에서 MS워드, 아래아 한글이 좋다고 워드 패드를 쓰지 말라는 법 있습니까? 오히려 어떤 부분은 워드패드가 더 편할 때도 있습니다. 단축키도 vim 의 단축키가 편한 사람도 있을것이고 이맥스가 더 편한 사람도 있을 것입니다.
둘다 모두 훌륭한 문서 편집기입니다.

정태영의 이미지

다크슈테펜 wrote:
Vi도 편집기 그 이상입니다...
진정한 편집기는 역시 pico...........

젠투를 stage1 부터 하드코어하게 깔려면 nano 에 잠시나마 의존해야 하는데... 역시 vim 에 찌든 사람으로써 nano 는 -_ㅜ

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

hanna의 이미지

윈도우 gvim 에서는 왜 CTRL + Y 가 안먹죠.. 이것땜에 휠을 돌려야 하니 정말 귀찮네요..

esrevinu의 이미지

vim에도 coding style 같은 거 지정할 수 있나요?
emacs에는 그런게 있어서 탭을 누르면 알아서 들여쓰기를 해 주던데... 그리고
.emacs에서 그 스타일을 바꿀 수 있잖아요.

그런데 vim은 그 스타일을 어떻게 바꿀 수 있는지가 궁금하네요.
사실 vim을 써왔는데 누군가의 압박으로 emacs를 잠시 사용했었습니다.
vim이 emacs의 그 스타일대로 코딩을 할 수 있게 해 주면 emacs를 안 써도 될
것 같다는 생각이 들어서요. 물론 최근에 본 indent라는 프로그램을 써도
되겠지만...

monpetit의 이미지

hanna wrote:
윈도우 gvim 에서는 왜 CTRL + Y 가 안먹죠.. 이것땜에 휠을 돌려야 하니 정말 귀찮네요..

전 잘 되는데요...
creativeidler의 이미지

이맥스 띄워놓고 안 내리는 사람들에겐 vi의 가벼움이 전혀 장점으로 보이지 않겠죠.

단축키의 편리함만 따진다면야 아무래도 vi가 좀 우세겠죠. 키 입력 회수는 이맥스보다 좀 적을 겁니다.

han002의 이미지

다크슈테펜 wrote:
nahu5 wrote:
이맥스는 편집기 그 이상입니다...

진정한 편집기는 역시 Vi.............m
~
~
~
~
~
~
~
:wq


Vi도 편집기 그 이상입니다...
진정한 편집기는 역시 pico...........

^x

단순히 에디트하는데는 역시 nano죠...

사실 첨 리눅스쓰면서 사용해본게 pico라 :shock:

..

ydongyol의 이미지

han002 wrote:
다크슈테펜 wrote:
nahu5 wrote:
이맥스는 편집기 그 이상입니다...

진정한 편집기는 역시 Vi.............m
~
~
~
~
~
~
~
:wq


Vi도 편집기 그 이상입니다...
진정한 편집기는 역시 pico...........

^x

단순히 에디트하는데는 역시 nano죠...

사실 첨 리눅스쓰면서 사용해본게 pico라 :shock:

진정한 편집기는 M$ 다다닷넷 2003 IDE....도도돌날라온다.. :shock:

--
Linux강국 KOREA
http://ydongyol.tistory.com/

eungkyu의 이미지

emacs의 특징

bash 대신 esh 쓰라고 꼬신다 그런데 bash가 더 좋다.
mutt 대신 mew 쓰라고 꼬신다 그런데 mutt가 더 좋다.
등등
자꾸 이맥스 내에서 놀라고 꼬시지만 대개 standalone 프로그램이 더 좋다.

꼬심에 당하고 나면 좋은 프로그램을 못쓰니 자꾸 불편해진다.
겨우 꼬심을 벗어나고 나니 에디터만 남았다.

근데 에디터는 vim이 더 좋자나!!!

기타 안좋은점

1. 폰트 지정이 *아직까지도* xft 기반이 아니다. (윈도우용은 제외?)
2. 설정 바꿀때 메뉴상에서 되는거, 이상한 창에서 되는거, 설정 파일을 바꿔야 하는거 멋대로다
3. emacs내에서 설정을 바꾸면 자동으로 저장되는거, 안되는거 멋대로다
4. 설정 좀 건드리려고 lisp 알아야한다. 몰라도 대충 쓸 수 있다곤 하지만, 사실은 언제까지나 설정 동냥해야한다. (프로그램하는 에디터때문에 또 프로그래밍하기 싫다 -_-;;; )
5. 여러번 띄우기엔 무거워서 짜증나는데 frame 쓰기엔 더 짜증난다
6. 유니코드 지원이 미약하다.

좀 더 생각해보면 더 나오겠지만, 이정도가 제가 emacs를 안쓰게 된 이유입니다.

물론 emacs의 좋은점도 있습니다. 그것은 커서 이동, 지우기, 복사하기 등에 대한 키바인딩.

vi의 키바인딩은 보통 입력키와 겹치기 때문에 실제 vim을 사용할때는 큰 문제가 없지만, bash(readline?) command-line을 비롯해 평소 간단한 에디팅에까지 사용하기엔 약간 걸림돌이 있죠. 이럴때 emacs 키바인딩이 좋은거 같습니다.

그런데 그나마 home, end, page up, page down, ctrl + 화살표 등의 키바인딩에 비해 커다란 메리트가 없다는 것이 단점이랄까...

emacs를 써보려 했던 노력 끝에 얻어낸 결론입니다.
반론 환영합니다

불태워봅시다~

monpetit의 이미지

모두 틀린 말씀은 아니지만 몇 가지 지적하자면...

eungkyu wrote:
bash 대신 esh 쓰라고 꼬신다 그런데 bash가 더 좋다.
mutt 대신 mew 쓰라고 꼬신다 그런데 mutt가 더 좋다.
등등
자꾸 이맥스 내에서 놀라고 꼬시지만 대개 standalone 프로그램이 더 좋다.

그런 꼬심에 왜 넘어가십니까.
안 쓰면 그만이잖아요. 두살 먹은 어린애도 아닌데...
저도 emacs 쓰지만 esh, mew 안 씁니다. 저런 거 안 써도 아무도 뭐라 안 합니다.
전 메일 클라이언트 evolution 씁니다. emacs 안에서 안 나가려고 발버둥치지 않습니다.

eungkyu wrote:
근데 에디터는 vim이 더 좋자나!!!

근거를 들지 않은 얘기니 그냥 독백으로 처리하겠습니다. :)

eungkyu wrote:
2. 설정 바꿀때 메뉴상에서 되는거, 이상한 창에서 되는거, 설정 파일을 바꿔야 하는거 멋대로다

이건 차라리 부럽다고 해야 되는 거 아닌가요? 정 억울하면 설정파일만으로도 모든 걸 다 할 수 있습니다. 설정 파일에서는 안 되는데 메뉴상에서는 되는 건 하나도 없습니다.

eungkyu wrote:
3. emacs내에서 설정을 바꾸면 자동으로 저장되는거, 안되는거 멋대로다

자동으로 저장되는 설정의 예를 들어 주시겠습니까? 전 이제껏 emacs 쓰면서 설정 변경이 자동 저장 된 경우를 단 한 번도 겪어본 적이 없어서 말이죠.

eungkyu wrote:
4. 설정 좀 건드리려고 lisp 알아야한다. 몰라도 대충 쓸 수 있다곤 하지만, 사실은 언제까지나 설정 동냥해야한다. (프로그램하는 에디터때문에 또 프로그래밍하기 싫다 -_-;;; )

vim 설정도 문법을 알아야 됩니다. vimrc 설정할 땐 어디 설정 동냥 안 하고 창조적으로 할 수 있을까요...
예를 하나 들어 볼까요. 언뜻 보기엔 똑같은 설정 문법인 것 같은데 어떤 건 set 명령이 있고 어떤 건 없습니다. 또 어떨 땐 on/off를 쓰지만 어떨 땐 없이 쓰기도 합니다.
set tabstop=8
set ruler
colorscheme desert
syntax on

심지어 vim script를 본격적으로 쓰고자 할 땐 emacs나 vim이나 똑같습니다. 또 일반 설정과 스크립트의 수준 차이가 현격하게 나는 vim에 비해 오히려 일관되고 우아한 lisp문법을 가지고 있는 emacs가 더 좋다고 생각할 수도 있습니다.

eungkyu wrote:
6. 유니코드 지원이 미약하다.

맞습니다. emacs는 유니코드 지원이 미약합니다. 하지만 욕을 먹어야 할 정도인지는 한 번 생각해 볼 필요가 있습니다.
그래서 얼마나 불편하신가요. 혹시 '똠방각하' 같은 단어를 쓸 수 없어서 불편하신 건지... 그런 게 아니라면 별로 불편할 일이 없을 것 같은데요.
avelose의 이미지

역시 불타오르는 군요. 슬슬 몸에 오한이 들었는데 따뜻해서 좋군요.
그런데 확실히 이런 류의 논쟁은.. 쩝.

'현실은 수학으로 표현할 수 없다.'
'수학은 거짓의 학문이다.'
'난 수학이 정말 싫다.'

cjh의 이미지

http://tats.haun.org/mule-ucs/

mule-ucs 패키지를 설치하면 emacs의 유니코드 지원을 많이 보충해 줍니다. 가령 저같으면 mew에서 UTF-8메일 읽고쓰기에 별 지장이 없는데요.
입력기에서는 아직 지원이 미약한 편이지만...

--
익스펙토 페트로눔

rainmon의 이미지

아래 동영상을 보시죠.
아발론이라고 하는 오픈소스 진영의 XUL과 유사한 개발방식을 소개해주고 있습니다.
그런데 보시면 emacs 편집기로 xml 작성, C# 코드 작성, 빌드, 쉘 사용까지..

이 동영상을 보고 emacs를 쓰는 사람들이 실제로(-_-)
존재한다는것을 믿게 되었습니다.

http://msdn.microsoft.com/msdntv/episodes/en/20031028lhorndb/ChrisA-DonB_300K.asx

yui의 이미지

cjh wrote:
http://tats.haun.org/mule-ucs/

mule-ucs 패키지를 설치하면 emacs의 유니코드 지원을 많이 보충해 줍니다. 가령 저같으면 mew에서 UTF-8메일 읽고쓰기에 별 지장이 없는데요.
입력기에서는 아직 지원이 미약한 편이지만...

가끔, 아니 자주 아래와 같이 나오면서 저장이 되지 않습니다.

-uuu:**-F1  테스트파일             (Fundamental)--L3--All-----------------------
These default coding systems were tried:
  utf-8-unix mule-utf-8
However, none of them safely encodes the target text.

Select one of the following safe coding systems:
  raw-text emacs-mule no-conversion


-uuK:%%-F1  *Warning*         (Help View)--L1--All------------------------------
Select coding system (default raw-text):

하지만 Ctrl+g Ctrl+x+s Ctrl + g Ctrl+x+s 를 몇번 반복하다보면 파일 저장에 성공합니다. 깨지지 않고 정상적으로 저장되구요.

왜 그럴까요? GNU Emacs 21.4.1 입니다. mule-ucs도 설치되어 있습니다.

pool007의 이미지

저는 vim 사용자이구요. vim은 나름대로 꽤 쓴다고 생각합니다..
그리고 최근에 tutorial 을 보면서 emacs의 기초 사용법을 배워보기도 했습니다..

음.. 그런데, 아무리 생각해도 말이죠..
앞서서 emacs를 사용한 avalon개발 동영상에서도 드러나듯이
모든 것을 다 타이핑하면서 해결하는 기존의 텍스트 에디터는
정말 한계가 있다고 생각이 드네요.

IDE라는 것이 - 최근의 운영체제가 그렇듯이 - 갈수록 헤비해지고
기능이 다양해지고 있죠. Visual Studio가 그렇고, Eclipse가 그렇고
기타의 GUI기반의 에디터들이 그렇죠.

쉽게 드래그 엔 드롭하고, 클래스 다이어그램을 원클릭으로 눌러서 보며
다양한 리팩토링(extract method, rename, generate setter/getter 등)도
요즘엔 안되는게 이상한 세상이죠.. 더구나 이런 기능들의 편리함은
굳이 말 할 필요도 없는 듯..

제가 동의하기 힘든건 이겁니다.

흔히들 vim은 텍스트 에디터, emacs는 IDE라고 이야기를 하곤 하던데
제가 보기에는 IDE라는 개념자체가 바뀌었다고 생각해요. 여러가지 설정이
가능하고 (인덴테이션, 컴파일), 간단한 태그 룩업이 되고 (ctags와의 연동)
그런것이 유연하게 된다고 해서 IDE가 되는 시대는 지났다는 생각이
드는군요... 그리고 디버깅하면서 소스보는 정도 외에는 - 사실 그것도
좀 불편하지만 gdb안에서도 다 해결이 되죠 - vim과 차이도 별로
없고요.

emacs도 확실히 좋은툴이지만, 그리고 과거에는 분명 어떤 영역을 구축해
나갔겠지만, 지금은 정말 대단한 IDE는 아니라고 생각이 드는군요. 이건
물론 vim도 마찬가지구요...

음.. 그리고 단축키의 경우는..
사실 저는 vim의 단축키를 항상 잊어버리거든요.
항상 새로운 단축키를 점점 더 알게되고.
새로운 설정도 점점더 알게되고.
인간이면 한계가 다 있는것 같아요..
특별히 한쪽이 키가 쉽다거나 라는 생각은 안드는군요.
다만 저로선 emacs가 익숙하지 않지만, 뭐 그것은 경험에 따른 개인차겠죠.

--
Passion is like genius; a miracle.

creativeidler의 이미지

동감. 전 사실 I/O에 CPU를 많이 쓰면 두 세배쯤 I/O가 빨라진다해도 CPU 덜 쓰고 I/O 느린 OS를 쓸 것 같네요.

rainmon의 이미지

pool007 wrote:
저는 vim 사용자이구요. vim은 나름대로 꽤 쓴다고 생각합니다..
그리고 최근에 tutorial 을 보면서 emacs의 기초 사용법을 배워보기도 했습니다..

음.. 그런데, 아무리 생각해도 말이죠..
앞서서 emacs를 사용한 avalon개발 동영상에서도 드러나듯이
모든 것을 다 타이핑하면서 해결하는 기존의 텍스트 에디터는
정말 한계가 있다고 생각이 드네요.

IDE라는 것이 - 최근의 운영체제가 그렇듯이 - 갈수록 헤비해지고
기능이 다양해지고 있죠. Visual Studio가 그렇고, Eclipse가 그렇고
기타의 GUI기반의 에디터들이 그렇죠.

쉽게 드래그 엔 드롭하고, 클래스 다이어그램을 원클릭으로 눌러서 보며
다양한 리팩토링(extract method, rename, generate setter/getter 등)도
요즘엔 안되는게 이상한 세상이죠.. 더구나 이런 기능들의 편리함은
굳이 말 할 필요도 없는 듯..

제가 동의하기 힘든건 이겁니다.

흔히들 vim은 텍스트 에디터, emacs는 IDE라고 이야기를 하곤 하던데
제가 보기에는 IDE라는 개념자체가 바뀌었다고 생각해요. 여러가지 설정이
가능하고 (인덴테이션, 컴파일), 간단한 태그 룩업이 되고 (ctags와의 연동)
그런것이 유연하게 된다고 해서 IDE가 되는 시대는 지났다는 생각이
드는군요... 그리고 디버깅하면서 소스보는 정도 외에는 - 사실 그것도
좀 불편하지만 gdb안에서도 다 해결이 되죠 - vim과 차이도 별로
없고요.

emacs도 확실히 좋은툴이지만, 그리고 과거에는 분명 어떤 영역을 구축해
나갔겠지만, 지금은 정말 대단한 IDE는 아니라고 생각이 드는군요. 이건
물론 vim도 마찬가지구요...

음.. 그리고 단축키의 경우는..
사실 저는 vim의 단축키를 항상 잊어버리거든요.
항상 새로운 단축키를 점점 더 알게되고.
새로운 설정도 점점더 알게되고.
인간이면 한계가 다 있는것 같아요..
특별히 한쪽이 키가 쉽다거나 라는 생각은 안드는군요.
다만 저로선 emacs가 익숙하지 않지만, 뭐 그것은 경험에 따른 개인차겠죠.

특정언어에 특화되어있는것이 VS.NET이고 써본적은 없지만 Eclipse도 역시 Java IDE라고 생각됩니다.
뭐.. 다른 언어도 잘 된다고 하시면 VS.NET 에서도 에드온만 설치하면 Eclipse보다 못하겠지만 가능합니다만
아래에서 애기하는 기능들은 지원되지 못하거나 제대로 안되겠지요.
툴들이 제공하는 다이어그램 생성, 리버스엔지니어링, 솔루션및 프로젝트 관리기능들이 제 경험으론 완벽하지 않고
버그가 있어서 실무에선 손도 안대는 기능도 많습니다.
소스단위의 편집을 할때도 엄청 무거운 IDE를 열어서 솔루션을 열어야 하고
고정된 틀에 프로젝트를 맞추고 따라가줘야 하는데 항상 입맛대로 그런 툴들을 설정할순 없습니다.
당장 하나 예를 들어도 VS.NET의 솔루션을 구성할때 여러 프로젝트를 생성하면
물리적인 디렉토리에 각각의 프로젝트들이 여기저기 생성되서 관리가 안됩니다.
이런저런 문제를 해결하기 위한 꽁수가 있지만 정석은 아닙니다.
다음 버전에선 문제가 해결되었다고 합니다만 이미 3년전부터 이런 문제가 불거졌었지요.
제가 make나 배치파일만 잘 짤수 있다면 여러 프로젝트들을 효율적으로 빌드할 수 있었을텐데라는 생각도 했었고요.
버전이 바뀌면 쓰지도 않는 기능들때문에 더 번잡스럽기도 하고..

buffmail의 이미지

Quote:
음.. 그런데, 아무리 생각해도 말이죠..
앞서서 emacs를 사용한 avalon개발 동영상에서도 드러나듯이
모든 것을 다 타이핑하면서 해결하는 기존의 텍스트 에디터는
정말 한계가 있다고 생각이 드네요.

IDE라는 것이 - 최근의 운영체제가 그렇듯이 - 갈수록 헤비해지고
기능이 다양해지고 있죠. Visual Studio가 그렇고, Eclipse가 그렇고
기타의 GUI기반의 에디터들이 그렇죠.

음..주제랑은 약간 거리가 있는 것 같은데... ^^

저도 콘솔 기반 편집기만으로의 개발은 분명히 한계가 있다고 생각합니다.
개발이라는 것이 문서편집만 하는 것이 아니라, dialog 등을 구성하고
여러 문서 사이를 브라우징 하고 하는 등등 GUI 가 훨씬 걸맞는 작업이
분명히 있지요...

하지만, Visual Studio 등은, IDE답게 기능들의 통합은 잘 되어 있지만,
에디터의 본연의 기능인 편집 그 자체만으로 봤을 땐, 아직 원시적이라고
생각합니다. 심하게 말하자면 syntax highlighting, 자동 완성 등 몇몇
기능이 추가된 notepad 일 뿐이라고 생각합니다.

10년 차 된 프로그래머라도, 소스를 짤 때는 무의미하게 화살표 버튼이나
스페이스를 몇 번씩 눌러대거나, 단조롭게 휠을 긁어야지요.. 물론
직관적이고 초기에 학습이 쉬운 점은 인정하지만, 최소한 프로그래머를
위한 툴이라면은 좀 더 논리적으로 문서 편집이 가능하도록 할 수 있는
특별한 키바인딩 옵션 정도라도 제공할 수는 없었을까요? 그 학습이
부담스러운 사람들에게는 끌 수도 있게끔 말이죠.. 물론 VS 에는
plugin 기능이 있지만, 에디터 쪽의 API는 아예 공개해 놓지 않았는지,
vim 에서 나온 VS 플러그인 을 써 보면 별도의 프로그램으로 떠서
Visual Studio 와 따로 놉니다.

저로서도 vim 이나 emacs 를 일반인에게는 그다지 권하고 싶지 않지만,
문서편집이 업인 사람들 특히 프로그래머에게 있어서는 훌륭한
유산이라고 생각하는데, IDE 에서는 이런 류 편집기들의 인터페이스를
즐길 수가 없어 안타깝네요....

eungkyu의 이미지

예상대로 (?) 격렬하게 반응이 나오는군요 ;;

저 개인적으론 앞에 적은 것을 포함한 여러가지 이유로 이맥스를 안쓰고 있지만, 뭐 이맥스도 쓰지 못할 환경은 아니라는 데에는 동의합니다.

monpetit wrote:
모두 틀린 말씀은 아니지만 몇 가지 지적하자면...

eungkyu wrote:
bash 대신 esh 쓰라고 꼬신다 그런데 bash가 더 좋다.
mutt 대신 mew 쓰라고 꼬신다 그런데 mutt가 더 좋다.
등등
자꾸 이맥스 내에서 놀라고 꼬시지만 대개 standalone 프로그램이 더 좋다.

그런 꼬심에 왜 넘어가십니까.
안 쓰면 그만이잖아요. 두살 먹은 어린애도 아닌데...
저도 emacs 쓰지만 esh, mew 안 씁니다. 저런 거 안 써도 아무도 뭐라 안 합니다.
전 메일 클라이언트 evolution 씁니다. emacs 안에서 안 나가려고 발버둥치지 않습니다.

그쵸. 안 써도 아무도 뭐라 안그럽니다. 그치만 저같은 경운 여기저기서 좋다고 꼬시면 쉽게 ~_~ 넘어가는 편이라서 그랬습니다.
열심히 따라해서 써봐도 새로 익혀야 하는 기능, 유지해야하는 설정만 늘어나고 정작 효율은 특별히 늘어나지 않는걸 왜 자꾸 쓰면 좋다고 하는지...

저도 이제 나이도 먹을만큼 먹었으니 안쓰도록 하겠습니다. 아니, 지금은 이맥스 자체를 안쓰니 상관할 필요는 없지만...

monpetit wrote:
eungkyu wrote:
근데 에디터는 vim이 더 좋자나!!!

근거를 들지 않은 얘기니 그냥 독백으로 처리하겠습니다. :)

이맥스가 이러이러해서 좋다는 얘기도 안하셨으니, 비긴 걸로 합시다 :)

monpetit wrote:
eungkyu wrote:
2. 설정 바꿀때 메뉴상에서 되는거, 이상한 창에서 되는거, 설정 파일을 바꿔야 하는거 멋대로다

이건 차라리 부럽다고 해야 되는 거 아닌가요? 정 억울하면 설정파일만으로도 모든 걸 다 할 수 있습니다. 설정 파일에서는 안 되는데 메뉴상에서는 되는 건 하나도 없습니다.

eungkyu wrote:
3. emacs내에서 설정을 바꾸면 자동으로 저장되는거, 안되는거 멋대로다

자동으로 저장되는 설정의 예를 들어 주시겠습니까? 전 이제껏 emacs 쓰면서 설정 변경이 자동 저장 된 경우를 단 한 번도 겪어본 적이 없어서 말이죠.

eungkyu wrote:
4. 설정 좀 건드리려고 lisp 알아야한다. 몰라도 대충 쓸 수 있다곤 하지만, 사실은 언제까지나 설정 동냥해야한다. (프로그램하는 에디터때문에 또 프로그래밍하기 싫다 -_-;;; )

vim 설정도 문법을 알아야 됩니다. vimrc 설정할 땐 어디 설정 동냥 안 하고 창조적으로 할 수 있을까요...
예를 하나 들어 볼까요. 언뜻 보기엔 똑같은 설정 문법인 것 같은데 어떤 건 set 명령이 있고 어떤 건 없습니다. 또 어떨 땐 on/off를 쓰지만 어떨 땐 없이 쓰기도 합니다.
set tabstop=8
set ruler
colorscheme desert
syntax on

심지어 vim script를 본격적으로 쓰고자 할 땐 emacs나 vim이나 똑같습니다. 또 일반 설정과 스크립트의 수준 차이가 현격하게 나는 vim에 비해 오히려 일관되고 우아한 lisp문법을 가지고 있는 emacs가 더 좋다고 생각할 수도 있습니다.

설정 파일에 대해선 확실히 오버한 면이 많네요. 그나저나 예전에 이맥스의 메뉴중에 현재 현재 설정을 저장하는 것을 본 거 같은데, 오래되서 잘 기억이 안나네요. 확인할려고 다시 깔기도 귀찮으니 없었던 얘기로 하는게 좋겠습니다. ^^

다만 제 기억에 새로운 컴퓨터 설정을 할 때 vim은 스스로 만족하는 부분까지 설정을 금방 만들 수 있었지만, 이맥스의 경우는 항상 설정찾아 삼만리를 한 기억이 많아서 생긴 푸념으로 이해해 주시면 감사하겠습니다. 제가 이맥스에 덜 익숙해서 생긴 일이기도 하지만, 기본적으로 만족할 만한 환경을 만들기까지 고쳐야할 설정의 양이 이맥스가 훨씬 많았던 기억은 확실하네요.

특히 이맥스 하나만을 위해서 x core font로 한글폰트 설정하고 수많은 시행착오를 거친 기억은 좀 끔찍합니다. 이맥스를 지우고 나니 어찌나 가슴이 후련하던지... (다시보니 이건 이맥스 설정 문제는 아니군요. X에서의 한글 폰트 설정 문제니)

monpetit wrote:
eungkyu wrote:
6. 유니코드 지원이 미약하다.

맞습니다. emacs는 유니코드 지원이 미약합니다. 하지만 욕을 먹어야 할 정도인지는 한 번 생각해 볼 필요가 있습니다.
그래서 얼마나 불편하신가요. 혹시 'ㅤㄸㅗㅁ방각하' 같은 단어를 쓸 수 없어서 불편하신 건지... 그런 게 아니라면 별로 불편할 일이 없을 것 같은데요.

제 컴을 비롯해서 주위에 UTF-8 인코딩을 기본 로케일로 사용하는 기계가 몇 있기 때문에 저에겐 꽤나 중요한 일입니다. 물론 mule-ucs도 알고는 있고 사용도 해봤습니다. 이맥스 시작부터 무지하게 느리게 만들더군요. ㅡㅜ

저 개인적인 프로그래밍 스타일이 vim, gcc, gdb, subversion (or cvs), 등등의 툴을 bash 쉘을 ide삼아 _-_ 활용하는 편이기 때문에 이맥스는 잘 손에 안맞는 듯 합니다.

죠커의 이미지

pool007 wrote:
저는 vim 사용자이구요. vim은 나름대로 꽤 쓴다고 생각합니다..
그리고 최근에 tutorial 을 보면서 emacs의 기초 사용법을 배워보기도 했습니다..

음.. 그런데, 아무리 생각해도 말이죠..
앞서서 emacs를 사용한 avalon개발 동영상에서도 드러나듯이
모든 것을 다 타이핑하면서 해결하는 기존의 텍스트 에디터는
정말 한계가 있다고 생각이 드네요.

IDE라는 것이 - 최근의 운영체제가 그렇듯이 - 갈수록 헤비해지고
기능이 다양해지고 있죠. Visual Studio가 그렇고, Eclipse가 그렇고
기타의 GUI기반의 에디터들이 그렇죠.

쉽게 드래그 엔 드롭하고, 클래스 다이어그램을 원클릭으로 눌러서 보며
다양한 리팩토링(extract method, rename, generate setter/getter 등)도
요즘엔 안되는게 이상한 세상이죠.. 더구나 이런 기능들의 편리함은
굳이 말 할 필요도 없는 듯..

제가 동의하기 힘든건 이겁니다.

흔히들 vim은 텍스트 에디터, emacs는 IDE라고 이야기를 하곤 하던데
제가 보기에는 IDE라는 개념자체가 바뀌었다고 생각해요. 여러가지 설정이
가능하고 (인덴테이션, 컴파일), 간단한 태그 룩업이 되고 (ctags와의 연동)
그런것이 유연하게 된다고 해서 IDE가 되는 시대는 지났다는 생각이
드는군요... 그리고 디버깅하면서 소스보는 정도 외에는 - 사실 그것도
좀 불편하지만 gdb안에서도 다 해결이 되죠 - vim과 차이도 별로
없고요.

emacs도 확실히 좋은툴이지만, 그리고 과거에는 분명 어떤 영역을 구축해
나갔겠지만, 지금은 정말 대단한 IDE는 아니라고 생각이 드는군요. 이건
물론 vim도 마찬가지구요...

음.. 그리고 단축키의 경우는..
사실 저는 vim의 단축키를 항상 잊어버리거든요.
항상 새로운 단축키를 점점 더 알게되고.
새로운 설정도 점점더 알게되고.
인간이면 한계가 다 있는것 같아요..
특별히 한쪽이 키가 쉽다거나 라는 생각은 안드는군요.
다만 저로선 emacs가 익숙하지 않지만, 뭐 그것은 경험에 따른 개인차겠죠.

경험적으로 괄호를 다루는데 가장 훌륭한 도구는 Emacs이더군요. Don Box도 나름대로의 장점을 찾았기 때문에 Visual Studio를 쓰지 않는 것이겠지요. 내가 알고 있기로는 .net팀에선 Emcas와 Visual SlickEdit가 강세라고 알고 있습니다.

monpetit의 이미지

오해를 줄이고자 사족을 붙이자면...

eungkyu wrote:
예상대로 (?) 격렬하게 반응이 나오는군요 ;;

저 개인적으론 앞에 적은 것을 포함한 여러가지 이유로 이맥스를 안쓰고 있지만, 뭐 이맥스도 쓰지 못할 환경은 아니라는 데에는 동의합니다.


전 vim 진영의 공격에 발끈한 emacs 추종자가 아닙니다. 오히려 emacs보다 훨씬 더 많이 vim을 사용합니다. :)
제가 댓글을 달았던 이유는 emacs가 얼마나 멋진가를 얘기하고자 함이 아니라, emacs가 이러저러한 이유로 불편하다고 한 글이 마치 notepad를 사용하는 사용자가 vim이 얼마나 불편한지를 얘기하는 것과 같지 않나 해서입니다. Ctrl-C, Ctrl-V도 안 되고, 글꼴 설정 변경도 저장이 안 되고 등등... 익숙하지 않은 사람에게는 vim도 얼마나 불편하겠습니까.

eungkyu wrote:
열심히 따라해서 써봐도 새로 익혀야 하는 기능, 유지해야하는 설정만 늘어나고 정작 효율은 특별히 늘어나지 않는걸 왜 자꾸 쓰면 좋다고 하는지...

제가 이해하는 대부분의 emacs용 응용 프로그램은 사용하면 좋다고 적극 추천하기 보다는 이런 것도 있다고 소개하는 수준이었습니다만...
즉 편집기에서 이런 것도 된다는 뜻이겠죠. 다른 편집기는 못하는 걸 emacs는 할 수 있다 정도랄까요.
사실 한 우물만 파는 전문 애플리케이션에 비해 emacs용 응용 프로그램이 뭐 그리 강점이 있겠습니다. 저도 mutt가 훨씬 좋다고 생각하고 예전엔 그걸 사용했습니다.
emacs용 프로그램을 언급할 땐, emacs는 이 정도로 hackable하다는 뉘앙스도 포함되어 있다고 봅니다.

eungkyu wrote:
이맥스가 이러이러해서 좋다는 얘기도 안하셨으니, 비긴 걸로 합시다 :)

위에서도 말한 바와 같이 전 emacs가 좋다고 주장하려 했던 의도가 아니었습니다.

eungkyu wrote:
그나저나 예전에 이맥스의 메뉴중에 현재 현재 설정을 저장하는 것을 본 거 같은데, 오래되서 잘 기억이 안나네요.

있습니다. 메뉴에서 현재 설정을 저장할 수 있죠. 다만 사용자가 원하지 않는 자동 저장은 없습니다.

eungkyu wrote:
제 컴을 비롯해서 주위에 UTF-8 인코딩을 기본 로케일로 사용하는 기계가 몇 있기 때문에 저에겐 꽤나 중요한 일입니다. 물론 mule-ucs도 알고는 있고 사용도 해봤습니다. 이맥스 시작부터 무지하게 느리게 만들더군요.

저 역시 utf-8 인코딩을 기본 로케일로 사용하고 있습니다. 하지만 별로 프로그래밍 하는데 어려움은 없더군요.
여기서 전제로 하는 것은 제가 사용하는 emacs의 버전은 22.0.50이라는 점인데요... 버전 22부터는 mule-ucs 없이도 utf-8을 지원합니다. 속도도 그리 느리지 않구요. 물론 vim에 비할 바는 아닙니다만... :)

제가 emacs를 사용하는 데에는 결정적으로 vim이 Lisp/Scheme 구문 들여쓰기를 이해하지 못한다는 점이 가장 큽니다. 이 부분만큼은 어쩔 수가 없네요. 다른 편집기를 사용할 수 없습니다. 물론 요즘은 eclipse용 plug-in이 있지만요...

alee의 이미지

말로만 논쟁을 계속 하는 대신에 vim 초고수와 emacs 초고수를 한 10명씩 데려다 놓고 소스코드 빨리 편집하기 시합을 개최해보는건 어떨까요? 둘만 하기 심심하면 Visual Studio 같은 것들 초고수들도 함께 끼워 주고요. 키보드에서 불꽃 튀는 대결이 되지 않을까요? 물론 농담입니다. :twisted: 그런데 과연 누가 이길까요?

jachin의 이미지

alee wrote:
말로만 논쟁을 계속 하는 대신에 vim 초고수와 emacs 초고수를 한 10명씩 데려다 놓고 소스코드 빨리 편집하기 시합을 개최해보는건 어떨까요? 둘만 하기 심심하면 Visual Studio 같은 것들 초고수들도 함께 끼워 주고요. 키보드에서 불꽃 튀는 대결이 되지 않을까요? 물론 농담입니다. :twisted: 그런데 과연 누가 이길까요?
저도 낄래요! +_+g 전 Vim 쪽에... ㅋㅋㅋ
lordmiss의 이미지

alee wrote:
말로만 논쟁을 계속 하는 대신에 vim 초고수와 emacs 초고수를 한 10명씩 데려다 놓고 소스코드 빨리 편집하기 시합을 개최해보는건 어떨까요? 둘만 하기 심심하면 Visual Studio 같은 것들 초고수들도 함께 끼워 주고요. 키보드에서 불꽃 튀는 대결이 되지 않을까요? 물론 농담입니다. :twisted: 그런데 과연 누가 이길까요?

과제를 몇 개 내주고, 각 에디터 진영의 대표자가 나와서 동일한 과제를 수행하는데 걸리는 시간을 측정하면 되겠군요. KLDP배 에디터 한국시리즈쯤이 되겠는걸요... 심판이야 kldp 운영진 분들이 하시면 되니까... 이런 대회라면 웹으로 해도 충분히 가능성이 있을 것 같은데 말이죠... 오프로 해야 하나?

농담 말구 진짜로 해 봐도 재밌을 것 같습니다... (저는 EditPlus 사용자에게 응원을... 컥)

alee의 이미지

lordmiss wrote:
alee wrote:
말로만 논쟁을 계속 하는 대신에 vim 초고수와 emacs 초고수를 한 10명씩 데려다 놓고 소스코드 빨리 편집하기 시합을 개최해보는건 어떨까요? 둘만 하기 심심하면 Visual Studio 같은 것들 초고수들도 함께 끼워 주고요. 키보드에서 불꽃 튀는 대결이 되지 않을까요? 물론 농담입니다. :twisted: 그런데 과연 누가 이길까요?

과제를 몇 개 내주고, 각 에디터 진영의 대표자가 나와서 동일한 과제를 수행하는데 걸리는 시간을 측정하면 되겠군요. KLDP배 에디터 한국시리즈쯤이 되겠는걸요... 심판이야 kldp 운영진 분들이 하시면 되니까... 이런 대회라면 웹으로 해도 충분히 가능성이 있을 것 같은데 말이죠... 오프로 해야 하나?

농담 말구 진짜로 해 봐도 재밌을 것 같습니다... (저는 EditPlus 사용자에게 응원을... 컥)

웹으로는 아무래도 공정성에 문제가 있지 않을까요? 게다가 진짜 초 고수들의 키보드 위에서 불꽃튀는 손놀림을 직접 보는 재미가 사라지잖아요. :)

khris의 이미지

alee wrote:
웹으로는 아무래도 공정성에 문제가 있지 않을까요? 게다가 진짜 초 고수들의 키보드 위에서 불꽃튀는 손놀림을 직접 보는 재미가 사라지잖아요. :)

코드 페스트에... :D

───────────────────────
yaourt -S gothick elegant
khris'log

죠커의 이미지

lordmiss wrote:
alee wrote:
말로만 논쟁을 계속 하는 대신에 vim 초고수와 emacs 초고수를 한 10명씩 데려다 놓고 소스코드 빨리 편집하기 시합을 개최해보는건 어떨까요? 둘만 하기 심심하면 Visual Studio 같은 것들 초고수들도 함께 끼워 주고요. 키보드에서 불꽃 튀는 대결이 되지 않을까요? 물론 농담입니다. :twisted: 그런데 과연 누가 이길까요?

과제를 몇 개 내주고, 각 에디터 진영의 대표자가 나와서 동일한 과제를 수행하는데 걸리는 시간을 측정하면 되겠군요. KLDP배 에디터 한국시리즈쯤이 되겠는걸요... 심판이야 kldp 운영진 분들이 하시면 되니까... 이런 대회라면 웹으로 해도 충분히 가능성이 있을 것 같은데 말이죠... 오프로 해야 하나?

농담 말구 진짜로 해 봐도 재밌을 것 같습니다... (저는 EditPlus 사용자에게 응원을... 컥)

Lisp이나 Scheme으로 된 과제를 합시다. :twisted: