Professional Vim Configuration
2012년 11월 19일 월요일
오전 8:01
 
참고로, 아래 화면은 참고로 NerdTree+Tagbar+SourceExplorer+Jellybeans color scheme을 적용한 화면입니다. 그럼 시작합니다.  

 
 

    • VI 소개

Vi는 1976년 Bill Joy가 line editor인 ed(Ken Thomson)의 불편함을 느껴 만든 것으로 한 줄씩만 편집 가능한 줄 단위 편집기(ed)가 아니라, 한 화면을 보면서 편집 가능하다는 뜻에서 비쥬얼 에디터(VIsual editor)라고 이름 짓게 되었다. 참고로 bill joy는 bourne shell과 다른 C기반의 syntax사용이 가능한 c shell을 만든 장본인이기도 하다.
당시에는 컴퓨터에 코드를 넣어놓고 그것을 몇 line씩 읽어와서 수정하거나 삭제 또는 추가하고, 또 다시 원하는 라인을 읽어와 해당 line에 대해서 수정/삭제/추가하면서 구동시켰다고 한다. Memory가 작은 시절 어쩌면 당연한 이야기일지는 몰라도 상당히 불편한 작업임에 틀림이 없었다. 이 시절의 line editor의 concept으로 만들어 진 것이 Linux 명령어인 sed 이다.
다음은 line editor인 ed의 실행 화면이다. 명령어 사이 사이로 txt를 볼 수 있다. 즉 대화식으로 원하는 것을 요청을 해야만 어떤 동작을 해준다. 즉 최근의 editor나 windows의 개념은 기본서비스(default)가 훌륭하다는 것이다. 단 그것에 대한 부가가치는 지불해야 한다.

run ed editor
read 1240 byte
Print #1~#5
 
   
 
 
 
 
Delete #3
Print #1~#5
 
 
 
   
 
Search "missing"

        
 
현재 vi라고 한다면 당연히 original VI가 아닌 1991년에 Bram Moolenaar 이 vi를 upgrade해서 만든 "VIM"을 말한다. Vi를 실행한다고 해도 실제로는 vim으로 symbolic link가 걸려있는 것을 확인할 수 있을 것이다(참고> ls -al `which vi`). 그러나 문제는 VIM(VI Improved)은 은 그 변종이 너무 많아, 사실 자신이 정확히 어떤 환경의 vim을 사용하고 있는지 알기 어렵다는 것이다. 물론 대개의 경우 알 필요도 없으나, 여기까지 읽은 당신은 vim을 IDE로 쓰고 싶은 사람일 것이므로... 일단 Mac VIM이나, GVIM, terminal VIM 등의 큰 category로는 분류가 가능하다. 그러나, 세부야 어떻게 되었던, 현재 사용하고 있는 것은 VI가 아닌 VIM을 사용하고 있다는 사실이다.
< GVIM >                                                                                                      < Mac VIM >

 
  보통 VI를 처음 사용하게 되는 사람들이 겪는 가장 불편한 점은 ESC key를 누르면mode 가 change되어 원하지 않게 입력이 되거나, 아무 입력도 안 되는 점이다. 마우스가 없던 시절 나온 editor이므로 GUI button이 아닌, key on/off에 의해 mode change가 되어야 하는 시절이라 ESC는 당시엔 매우 탁월한 선택이었다. 그러나 현재의 ESC key에 대한 느낌 역시 "왜 이렇게 만들었어?" 라는 불만 섞인 말이 자연스럽게 나오게 만든다. 하지만 VI를 만들던 당시 키보드를 살펴보면 원래 의도는 그것이 아니었음을 알 수 있다.
 

 
참고로 emacs 역시 이러한 key pattern은 마찬가지인데 2회 이상의 CTRL(meta) key가 난무하는 emacs에 최적화 된 keyboard 역시 ctrl의 위치가 지금의 keyboard 형태는 아니었다고 한다. 현재까지도 VI와 Emacs진영 모두 황금위치에 배치된 caps-lock key를 어쩔 줄 몰라 난감해 하고 있다. 이런 이유로 VI user중에는 CAPS나 TAB key를 ESC로 설정하여 사용하는 사람도 있다. (http://vim.wikia.com/wiki/Avoid_the_escape_key)
요즘 처럼 다양한 OS가 일반적인 시대에 Linux와 mac 그리고 windows를 오가면 programing을 좀 해야겠다고 하면, vi로 수렴하게 된다. 물론 최근에는 다양한 고급기능을 갖춘eclipse로 수렴할 수도 있으나, 아직은 기본(performance, memory, management)에 충실치 못한 것이 사실이다. 그렇다고 vi가 쉬운 것도 아니다. 각 editor마다 넘어서야 하는 진입장벽이 있다는 것이다. 어째 튼 "vi를 notepad 가 아닌 notepad++정도로 좀 써야겠다"고 마음먹으면 이제 골치 아파진다. 아주~~
이는 vimrc 파일을 handling해야 하는데, 그 문법이 상상을 초월한다. 참고로 이런 문법은 Ansi-C문법과 유사하며, 최근의 script 언어가 그렇듯이 한꺼번에 실행하는 batch mode와 대화식의 interactive mode를 모두 제공한다. Batch mode는. vimrc와 대부분의 plug-in들이 동작하는 방식이며, interactive mode는: help functions 라고 치면, vimscript에서 사용할 수 있는 function을, :help map라고 치면 vim shortcut keyboard mapping을 보여주는 ... 뭐 이런 식이다.
VI를 처음 배우는 사람을 위해서 친절하게도 vimtutor라는 program이 있는데, 여기서는 따라 해보기로 step by step으로 vi를 배울 수 있는 program을 terminal형태로 지원한다. terminal 창에 vimtutor라고 쳐서 실행해보자.

 
 

    • Plugin 소개

위에서 editor 논쟁으로 발전될 것 같아, editor에서 대한 평을 가급적 줄였는데, Vi가 emacs나 eclipse에 필적 가능하다는 것은 단순히 빠른 성능으로 고유의 영역을 확보했기 때문은 아니다. vi가 vimscript(vimL)라는 mini language를 지원한 그 이후부터 그 기능이 기하급수적으로 확장되었으며, 이로써 현재 내로라하는 editor와 어깨를 나란히 할 수 있게 되었다. ViM.org 공식사이트에서 등록된plugin갯수을 확인해 볼 수 있는데, 현재 약 4000개 이상이 등록되어 있다. 개인적으로 이중에 100개 가량을 test해보았는데, 약 5%수준인 200/4000 정도만 가치 있는 결과물로 추측된다.

 
이로써 알 수 있는 교훈은 
하나로 완성된 결과물로서 packaging되어 제공되지 않는 open source의 수고로움이 대단히 소모적임을 알 수 있다. 참고로 Visual Studio 대비 완성도를 생각해보면서 어떤 개발 모델이 최고의 완성도를 가져오게 하는가? 라는 질문에 봉착하게 된다. 요새 Android가 그 해답을 제시하고 있다.
 
그럼 어떤 plugin들이 존재할까? 앞에서 말했지만 4000개 이상의 plugin이 존재하므로 "editor에서 상상할 수 있는 대부분의 기능들이 이미 개발되어 있다"고 할 수 있는데, Vim.org에서는 왼쪽 아래그림과 같이 분류되어 있다.
 

 
 
VIM Version 확인
이러한 plug-in을 설치하기 위해서는 먼저 해당 vi가 그 plug-in이 구동될 수 있는 환경인지 검사해야 한다. 본인 역시 초기에 이런 배경 지식이 없어, plugin를 설치하기 위해 몇 일이나 삽질한 경험이 있다. Vim version 확인은 ":version" 명령을 치면 compile된 환경이 나오는데, 여기서 GUI를 어느 정도 지원하는지... Ruby등의 추가 language를 지원하는지 검사해야 한다. 따라서 이 말은 사용자의 환경에 따라 vi의 기능도 달라질 수 있다는 것을 의미하는데, 참고로 주로 여기서는 cygwin vi와 linux teminal vi를 사용하였으며, GVIM이나 Mac VIM를 사용하지 않았으나 이 둘은 terminal version보다 지원 범위가 높으므로 그냥 사용해도 무방하겠다. (참고로, 또한 plug-in 개발자도 천차만별이어서 그런지, plug-in이 설치될 수 있는 최소 조건을 기록해놓는 사람이 있는가 반면, 대충~~그냥 배포 하는 사람들도 상당 히 많다는 것을 알게 되었다.)
 

 
 
Plugin 설치
plugin을 설치하기 위해서는 plugin을 보통 .vim dir아래 복사해서 넣으면 되는데, 간단히 zip을 풀면 아래 directory안으로 자동으로 들어가는 구조로 된다. 그러나 이런 방식도 zip/tar를 풀면 default로 새로운 dir가 추가로 생성된다든지, 기존의 다른 plug-in을 overwrite 한다든지 하는 이유 때문에, 제대로 설치 되지 못하는 경우가 많았다.
~/.vim (참고로 .vimrc와 .vim/는 HOME directory 아래 위치하며, .vim dir은 plugin을 보관하는 장소로 쓰인다.)
 
Vimball
그래서 vimball이라는 (VBA 확장자를 가진) 압축 파일로 packaging하여 제공하게 되었는데, 이는 vi로 xxx.vba를 연후 "source %"을 입력하면 vi가 자동으로 plugin을 해당 dir에 풀어주는 형식이었다. 그러나 위의 2방식 모두 plugin을 제거할 때는 마찬가지로 문제가 발생하게 되는데, 이는 어디로 무슨 파일이 들어갔는지, 이미 섞여버린 후여서 제거할 때 전혀 이력을 파악할 수 없다는 것이었다.
à 이 시기의 .vim dir 구조
~/.vim
├── autoload
├── colors
├── doc
├── ftplugin
├── indent
├── lib
├── plugin
└── syntax'
따라서 이런 불편함을 제거 하기 위해 아래와 같은 구조로 plugin dir를 Plugin마다 상호 독립화 하게 만든 것이 바로 pathogen이다.
 
~/.vim
├── autoload
├── bundle
├── Align
├── autoload
├── doc
└── plugin
├── FuzzyFinder
├── autoload
└── fuf
├── doc
└── plugin
├── The-NERD-Commenter
├── doc
└── plugin
├── The-NERD-tree
├── doc
├── nerdtree_plugin
└── plugin
└── ... 
└── doc
 
이제 pathogen으로 dir로 분리함으로 아주 쉽게 plugin을 관리할 수 있게 되었는데, 좀더 추가적인 need가 있었다. plugin을 검색하고/설치하고/제거하고/update하는 자동화된 process가 필요하였다. 이를 위해 vundle이 등장하게 된다. vundle은 마치 eclipse의 plugin을 설치하듯이 설치를 가능케 하는데, update와 history를 관리하기 위해서는 git source control system을 미리 설치해주어야 한다. (여기서도 git을 사용하니 미리 설치하길 바란다.). vundle의 install 방법은 https://github.com/tpope/vim-pathogen 여기에 있다. 
추가적으로 현재 github는 social-coding이라는 개발자의 coding community로 발전해 가고 있는데, 현재까지 개발된 VI plugin 모두 github에서 hosting하고 있다. 그럼 앞에서 plugin 설치/관리가 매우 쉬워졌음을 알게 되었는데, 그렇다면 어떤 plugin을 설치해야 할까? Vundle의 유일한 단점은 plugin에 대한 설명이 없다는 것인데...... 
그래서 http://www.vim.org/scripts/script_search_results.php 사이트의 설명과 각 고수들의 blog들을 찾아 다니면서 맛을 보는 일이 필요하다. 이 글을 작성하는 나 역시 일일이 다 나열할 수 없을 만큼 수많은 site를 돌아다녀서, 죄송하고 민망하게도 그 들의 노고를 이렇게 정리해놓는 것으로 대신하려고 한다.
 

    • VIM 설정 따라 하기

지금까지의 작업을 이제 하나씩 해보자. 
참고로. vimrc(보통 git으로 관리되는. vim의 상위 dir에. vimrc가 존재) 역시 git repository로 관리하면 편한데, 이는 여러 서버나 장소에 무관하게 동일한 설정으로 작업하기에 수월하기 때문이다. 아래 "따라 하기"를 보면 알겠지만 .vimrc를 .vim에 넣어서 관리하게 된다.

    • github.com에 연결된 git repository를 .vim dir에 생성 shell에서 > git clone git://github.com/av930/Android_VIM.git ~/.vim shell에서 > ln -fs ~/.vim/.vimrc ~/.vimrc
    • .vimrc에 설치해야 하는 plug-in과 HOME dir에 .vimrc link파일등 초기화 작업을 자동 실행한다.  vi가 열린 상태에서 > F1+z 누르면 설치가 시작된다.
    • vi 새로 시작한 후, 한글 명령어로 사용법 확인 후 vi 사용 시작 vi가 열린 상태에서 > F1

 
참고 (다음은 중요하지 않으니 pass해도 좋음)
1. 주기적으로 해줘야 하는 일
shell에서 > git pull origin #update하기, 최신 vim 수정을 받고 싶을경우
2. .vimrc을 열고 VIM 변수를 편집.(여러개의 configuration사용시)
#default dir인 ~/.vim 를 그대로 쓰겠다면 이 과정은 pass
#이는 .vimrc 파일 여러 개를 사용할 경우를 위해 설정해야 하는 값이다.
#VIMRC_PATH변수(root dir) VIM_PATH(.vim dir)를 .vimrc파일이 존재하는 곳으로 설정
 

    • Android 개발자 초기화

Android 개발자를 위해 조금 편의성을 제공한다. 물론 fugitive나 대부분의 plug-in들이 android 적용을 바탕으로 한 내용들이다. 그러나 요새 linux-kernel이나 기타 project도 동일하게 적용되므로 common한 사항이라 하겠다. 위에서 따라 하기에 이어 계속 따라 하면 된다. 참고로 이 과정은 반드시 초기화 과정이 끝난 상태이어야 하며, ctag가 install 되어 있어야 한다.

    • shell에서 > cd android-src # android full source의 root dir로 이동
    • vi가 열린 상태에서 > F12 + c #android용 ctag 생성
    • vi가 열린 상태에서 > F2 + c #android용 file jump용 filelist 생성

 

    • VIM 설정 update 하기

가끔 bug를 수정하거나, 신규 plugin을 설치하거나 key mapping을 재배열 하는 경우가 있는데, 그때 update를 통해서 기존 기능을 upgrade할 수 있다.

    • .vimrc update하기  shell에서 > git pull origin master
    • 새로 추가된 Plugin이 있으면 Update하기  vi가 열린 상태에서 > F7 u #BundleInstall!
    • 기존 것 중 삭제된 Plugin이 있으면 삭제하기 vi가 열린 상태에서 > F7 c #BundleClean!
    • 새로 추가된 Plugin의 manual index 생성  vi가 열린 상태에서 > F1 u

 

    • VIM key-mapping

F1을 누르면 한글 설명이 보이며, 바로 가기를 지원하기 위해 단축키 설명은 F# + hh 형태로 만들었다. (example로 F8 + hh등을 눌러보라.) . F1은 toggle로 동작하므로 설명 창을 닫을 때 역시 사용이 가능하다. 참고로 vi original help는: help로 참조 해볼 수 있다.

 
F1 : 설명과 도움말
F2 : ctrlp : file search
F3 : grep : string search
F4 : fugitive : git source control system integration
F5 : minibuffexpl : open file list 관리
F6 : zoomwin : window mangement
F7 : bundle : plugin management
F8 : nerdtree à directory browsing
F9 : tagvar : class layout manager
F10: source explorer : symbol look up
F11: ctag jump out : jump out from F12 view
F12: ctag jump in : jump to symbol
 
한글 설명이 깨져 보이는 현상이 있을 수 있는데, 이는 terminal program설정(shell 설정이 아님)에서 recv/trans coding을 UTF-8로 지정해주면 된다.
 

 
 

    • 마치며

GUI vim 대신 terminal을 사용한 것은 어떤 환경에서도 같은 동작을 보장하기 위함이다. 이런 기준으로 plug-in 선택도 하게 되었는데, Taglist 대신 Tagvar를 사용하고, Bufexpl 대신 minibufexpl을 사용한 것과 FuzzyFinder, Command-T대신에 CtrlP를 사용한 것은 이렇게 저렇게 사용해보고 변경 하게 되었다. Vim을 계속 설정해보면서 c/c++/java code completion 등의 욕심이 사라지지 않았지만, editor의 heavy해짐이 더 싫어진다. 각 언어에 따라 최적의 tool이 존재하니 만능 툴을 만든다면 최종적으로 OS가 되어 버릴 것 같아 이 정도에서 만족하기로 하였다.