, 리그 오브 레전드의 등장 챔피언에 대한 내용은
바이(리그 오브 레전드)
문서
참고하십시오.| ㅤ ㅤ ㅤ ㅤㅤ 텍스트 에디터 (문서 편집기) | ||
|
{{{#!wiki style="margin:0 -10px -5px; min-width:300px; min-height:calc(1.5em + 5px); word-break:keep-all" {{{#!folding [ 펼치기 · 접기 ] {{{#!wiki style="margin:-6px -1px -11px" |
<colbgcolor=#887b7e> Windows용 | 메모장 · 워드패드 · EmEditor · Notepad++ · EditPlus |
| 크로스 플랫폼 | Visual Studio Code · Sublime Text · Atom · Brackets | |
| 기타 운영체제용 | vi · vim · BBEdit · Emacs | |
| 이 외 에디터는 문서 편집기 문서 참고 | }}}}}}}}} | |
| vi | |
| 개발자 | 빌 조이 |
| 최초 릴리스 | 1976년 |
| 개발 언어 | C |
| 운영 체제 | BSD |
| 언어 | 영어 |
| 라이선스 | BSD 라이선스 |
| 웹 사이트 | http://ex-vi.sourceforge.net/ |
1. 개요
vi는 빌 조이가 1976년도에 만든 UNIX 계열 운영체제에서 주로 쓰이는 유서 깊은 오픈 소스 문서 편집기이다. "Visual editor"라는 뜻이다. 요즘 대다수의 유닉스와 리눅스 배포판에서 터미널에 vi를 치면 vim의 vi 호환모드가 뜨도록 하여 요즘에 리눅스나 유닉스를 배운 사람들은 vim이 vi인 줄 아는 경우도 있다. vim은 vi와 호환되기는 하지만 개발자부터 시작해서 완전히 다른 물건이다. 원칙적으로 텍스트 모드에서 작동하도록 만들어졌기 때문에 어떠한 플랫폼용 버전을 사용해도 기본적으로 모든 GUI가 텍스트 문자로 이루어져 있다. 내부 창 구분이나 구역 분할 등등.2. 역사
vim은 어디서 왔나2.1. vi 이전
옛날 옛적에는 텍스트를 편집할 때 라인 에디터(ed)라는 물건을 썼는데, 요즘에는 텍스트 에디터가 당연히 WYSIWYG이지만 라인 에디터는 "어디부터 어디까지 보여줘라"를 명령해야 보여주고 편집이 가능해지는 등 아주 골치 아프고 쓰기 불편한 물건이었다. 이는 당시 콘솔 환경이 모니터가 아니라 텔레타이프라는 일종의 프린터를 쓰는 경우가 있었고[1], 통신 속도가 1,000 bps도 안 되는 극저속이었기 때문에 1초에 한 화면 분량의 텍스트도 다 전송할 수 없었기 때문이다.'편집할 줄을 선택하고, 그 줄의 내용을 바꾼다' 를 반복하는 방식의 에디터는 MS-DOS 시절에도 EDLIN이라는 이름으로 들어가 있었고, PC통신에도 회원 간 편지 보내기 기능의 기본 에디터로 들어가 있는 경우가 많았다. ed가 POSIX 표준으로 지정되어 있기 때문에 오늘날 유닉스 호환 컴퓨터에도 깔려는 있다.
2.2. vi 개발
하지만 1줄씩만 보면서 코딩을 하는 건 귀찮은 일이었고, 결국, BSD 유닉스를 만들던 버클리 대학에서 빌 조이라는 전설적인 프로그래머가 ed에 '비주얼 모드'를 코딩해서 플러그인으로 만들어 넣었다고 알려져 있다.[2] 빌 조이는 후에 자바와 솔라리스 등으로 유명한 썬의 공동창업자가 된다. vi가 등장하면서 텍스트 편집이 매우 편해졌고, 라인 편집기에 플러그인으로 들어가 있던 vi가 아주 인기가 좋자 아예 별도의 프로그램으로 만들어졌다.당시엔 Emacs가 유료였던 시절이고, BSD에 기본으로 설치된 에디터가 ed와 vi뿐이었기 때문에 선풍적인 인기를 끌게 된다.
2.3. vim의 개발
vi는 ed에서 파생되어 자유 소프트웨어가 아니었기 때문에 AT&T의 라이선스 없이는 코드 수정이 불가능했다. 따라서 vi를 오픈소스화한 여러 vi의 복제판들이 등장했는데, 그중 하나가 vim이었다. vim은 1991년 네덜란드의 브람 몰레나르(Bram Moolenaar)가 개발했으며 vi와의 호환성을 우선으로 하였다. vim은 "vi imitation"이라는 뜻이었지만 얼마후 "vi improved"로 바뀌었다.오늘날에는 대부분 환경에서 vi를 입력해도 자동으로 vim으로 연결되기 때문에 일반적으로 vi라고 하면 오리지널 vi뿐 아니라 vim을 포함하는 경우가 대부분이다.
3. 이용
진입장벽이 높고 복잡한 모드라는 직관성을 다소 희생하는 수단을 취하는 대신 텍스트를 조작하는 기능에 치중하여 다른 편집기에 비하여 매우 간단한 키 입력으로 텍스트를 조작하는 것이 가능해졌다. 게다가 당시 컴퓨터 화면에는 지금의 모니터처럼 다양하고 직관적인 그래픽적 표시를 할 수가 없었으므로 화면에 일일이 시각적으로 표시해 주지 않을 바에야 최대한 짧고 간결한 명령 조작 체계를 도입하는 것이 합리적이었다.과거 편집기의 주된 사용 용도는 C 프로그래밍이었다. 프로그래밍의 특성상 한 번에 타이핑하기보다는 조금씩 변경, 추가를 하는 일이 많다. 이렇다 보니 당시에는 '라인 편집기' 개념이 중요했다. 라인 편집기는 편집할 줄과 편집 방식을 지정-> 방식에 따라 편집->다시 돌아와서 다음 번 편집할 줄과 편집 방식을 지정의 순환을 거치며 작동한다.
vi는 라인 편집기 개념에 기반하고 있어 GUI에 익숙한 사용자들에게는 접하기 힘들고 생소하다. 초보자들이 vi를 처음 보고 가장 당황하는 것은 실행을 시켰는데 키보드가 먹히질 않는다는 점이다. 당황해서 막 누르다 보면 또 어느 순간 입력이 되기 시작한다. vi에는 일반 모드, 입력 모드, 명령 모드의 세 가지 모드가 존재하기 때문인데, 그걸 모르고 초심자가 vi로 뭔가 하려고 손댔다가 입력은 안 되지, 삭제도 안 되지, 갑자기 모드가 바뀌어서 입력이 되지, Esc 눌러도 종료는 안 되지... 이런 상황 때문에 봉변을 당하는 경우가 많다.
vi의 해괴한(?) 기능 키 선정 역시 당시의 키보드 구조를 보면 납득이 가는데, 아래의 그림을 보면 알 수 있겠지만 많이 쓰는 Esc, Ctrl 키는 지금과 달리 아주 가까운 곳에 있고 방향키는 애초에 키보드에 없어서 다른 키에 매핑하고 있는 것을 알 수 있다. 물론 지금 와서 완전한 구형 키배치를 쓰는 키보드는 해피해킹과 같은 덕후용(?) 특수 생산품을 제외하고는 거의 없긴 하지만, 사람 버릇이 된 단축키라는 것이 어디 그리 쉽게 옮겨가던가. (FPS에서 마우스와 키보드를 동시에 쓰기 위해 방향을 WASD로 옮겨서 쓰는 것이 관습인 것처럼) 커서를 이동하는 것만 봐도 위, 아래, 왼쪽, 오른쪽으로 이동하는 키는 각각 K, J, H, L이고, 입력 모드에서는 Alt+(K, J, H, L)이다. 처음에는 생소하겠지만 익숙해지면 손가락이 화살표 쪽으로 갈 일이 없다는 점에서 꽤나 높은 편의성을 가져다 준다.[3]
Emacs와 비교하면, 명령 입력을 위해서는 거의 항상 양손이 키보드 위에 있어야 하는 Emacs에 비해 vi에서의 편집은 한 손만으로도 웬만한 것들은 가능하다. 그리고 한 번 여기에 맛들이면 항시 양손을 사용해야 하거나 마우스를 건드려야 하는 편집기에는 기능이고 뭐고를 떠나서 자연스레 거부반응이 늘어나게 된다.
초심자들에게는 리눅스에서는 nano를, FreeBSD에서는 ee를 권한다. 혹은 리눅스 이용자라면 대부분 배포판에 vimtutor라는 튜토리얼이 깔려 있으니 이를 사용해서 하라는 대로 해보면 어느 정도 중요한 기능들을 익힐 수 있다.
심지어 vi의 키맵을 bash에서도 쓸 수 있다. `set -o vi`라고 치면 Esc 키로 일반 모드로 들어가는 등 vi에서 쓰던 키맵을 거의 그대로 쓸 수 있다.[4] 지금 편집 모드인지 일반 모드인지 바로 알기 어렵고 선택 기능이 먹히지 않는다는 (즉 비주얼 모드가 없다는) 불편함이 있긴 하지만[5] 엄청 긴 스크립트 짜는 것도 아닌 한 줄 짜리 bash 작업을 위한 것이라고 생각하면 오히려 차고 넘치는 기능일 것이다. (심지어 yank(복사)-put도 먹힌다!) zsh에서도 같은 방식으로 사용 가능하다.
vim 8.0부터는 터미널 에뮬레이팅도 지원한다. :term이라고 입력해 보자. Ctrl+W를 위시로 한 다양한 단축키들을 이용하면 vim 내부의 터미널 내용을 편리하게 스크롤 할 수 있고 복사해서 가져 올 수도 있으며 반대로 vim 버퍼에 있던 내용을 vim 터미널 에뮬레이터에 Ctrl+V 하는 것마냥 붙여넣는 것도 가능하다.
중증 vi 중독자는 Windows에서도 편하다고 vi를 깔아서 쓴다. 실제로 Windows용이 따로 있다. 실행하면 유닉스나 리눅스에서와 똑같이 윈도우 창에 텍스트 화면만 달랑 나온다. 당연히 현재 Windows는 GUI로 쓰는 것이 일반화되어 있기 때문에, GUI 환경에서 쓰기 쉬운 버전도 있다. 리눅스에서 작성된 텍스트를 읽는데 유용하게 쓸 수 있다. 윈도우에선 일반 편집기와 같은 모드가 기본이나 설정파일을 수정하면 오리지널 모드로 변경 가능하다.
다만 상당수의 vi 사용은 리눅스에서 이루어지기 때문에, vi를 가르친다면 아예 PuTTY 같은 것을 깔아 리눅스 서버를 연결하고, 그 서버의 vi를 열어 가르치는 경우가 대부분이다. 이 경우 흔히 필수 설정을 좀 만져주지만, 거기에 자동 완성 같은 건 없다. 다른 편집기와 너무나도 다른 부분들[6]을 만져주는 정도니 크게 기대는 하지 말자.
4. 특징
편집 자체를 따로 하나의 모드로 구성하여 키 조작을 크게 단순화시킨 것이 특징이다. 일반 편집기에서는 입력모드와 편집모드가 구분이 되어있지 않기 때문에, 텍스트 입력에 쓰이는 알파벳이나 숫자 키 자체를 기능키로 사용하지는 못한다. 덕분에 편집 시에는 손가락이 거의 항상 shift, ctrl, alt 쪽에 붙어 있어야 하는데, vi에서는 그냥 단타나 연타로 끝난다. 예를 들어, 커서 움직임은 hjkl, 한 글자 지우기는 그냥 x, 한 줄 전체 지우기(컷)는 dd, 한 줄 전체 복사는 yy, 붙여넣기는 p 식이라, 기본적인 수준의 편집은 그냥 hjkl로 움직이고 지우고 복붙하고 하면서 커피 마시면서 한 손으로도 가능하다.두 번째는 함수형 명령들이다. 함수형 명령이란 예를 들어 f(x,y) 가 있다면 f x y를 순서대로 입력하는 방식이다. 쉽게 예를 들면, d라는 명령은 이것만으로는 아무것도 일어나지 않는다. 위의 예에서 f와 같은 함수라 인자를 받아야 작동한다. 물론 아무 인자나 받는 것은 아니고 '커서 이동'에 관한 명령을 인자로 받는다. 즉, 우측으로 한 칸 이동하는 명령인 l을 인자로 주어 dl을 순서대로 입력하면 우측 한 글자가 지워지고, 줄의 맨 처음으로 커서를 보내는 ^(혹은 0)과 조합하여 d^를 순서대로 입력하면 해당 위치에서 줄 첫부분까지가 모두 지워지는 식이다.
이것이 가장 많이 쓰이는 부분이 바로 수+명령인데, vi 에서 수는 뒤에 오는 인자를 받아 그 수만큼 반복 실행하는 함수로 볼 수 있다. 즉, 문자 하나를 지우는 x라는 명령과 수 50을 조합하여 50x를 입력하면 50글자가 지워지는 식이다.
함수의 인자로 다른 함수를 지정하는 것도 역시 가능하다. 즉, 5dk라는 명령은 5라는 함수, d라는 함수 그리고 k라는 커서 이동 인자로 구성되어 5(d(k)) 라는 함수로 볼 수 있다. 즉, d(k)라는 함수를 5번 반복하는 명령이 된다. k가 커서를 한 줄 위로 올리는 것이고, dk는 윗줄을 지우는 명령이 되기때문에 위로 5dk 는 위로 5줄을 삭제하는 명령 정도로 볼 수 있다.
이런 식으로 매우 간편하게 입력 가능한 편집 명령에 더해서 그것을 함수형으로 조합하여 타수를 더욱 절약하는 것이 가능하기 때문에, 그것에 특화된 기능이 따로 제공되지 않는 복잡한 작업일수록 vi에서 타수는 훨씬 줄어든다.
물론 vi/Vim 에디터 자체는 상당히 오래되었고, 레거시 유지용, 혹은 터미널 접속용 으로 사용되는것이 대부분이다. 아무리 플러그인이 많다고 해도 기본적인 에디터만 제공하기 때문. 하지만 조작방식 자체는 결코 구식이고 비효율적이라고 할 수 없기 때문에 많은 IDE 들의 플러그인으로도 존재한다. 그렇기 때문에 vi/Vim 그 자체보단 조작방식만 좋아하는 사람들은 IDE 에 vi/Vim 을 올려서 쓰는 경향이 있다.
하지만 제일 중요한건, vi/Vim 은 단순한 도구, 에디터일 뿐이며 이걸 사용 할 줄 안다고 코드 퀄리티가 높아지는 것은 아니다. 때문에 아무것도 모르는 상태에서 vi/Vim 이랑 씨름하는것은 대부분의 경우 추천되지 않는다. 우선은 개발 그 자체에 익숙해진 뒤 필요해질때 배우는 것이 이상적이다.[7]
5. 장점
숙달되면 아주 편하고 강력한 편집기가 되는데, 커서 이동을 비롯하여 대부분의 편집 명령어가 키보드 중심에 몰려있고, 모드를 이용하여 키 조합을 하지 않아도 되는 경우가 많기 때문에 같은 작업을 해도 타 편집기에 비해 손동작이나 타수가 크게 줄어든다. 텍스트 편집에 한정해서는 어떤 물건과 비교해도 크게 꿇릴 일이 없다. 즉, 단축키 등을 모두 습득하면 아주 빠르고 능률적으로 작업을 할 수 있다. 특히 중요한 점은, 어떤 유닉스나 리눅스 시스템에 가도 vim (vi Improved)는 기본적으로 깔려 있다는 것. POSIX에 포함된 사항이다. # 그 결과, vi의 키 조합은 유닉스의 상징과도 비슷한 존재가 되어 오늘날 웹브라우저, 파일 매니저 및 기타 등등 유닉스용 프로그램 상당수는 에디터가 아니라 할지라도 기본적인 vi의 키맵을 지원하는 경우가 많다.vi가 어렵다는 인식이 있지만 그래도 Emacs에 비하면 훨씬 심플하다. vi가 다양한 빌트인 함수를 이용하는 것이라면, emacs의 경우에는 아예 함수를 바닥부터 직접 만들어서 쓰는 편집기라 보면 간단하다. 덕분에 Emacs는 단순 편집기의 영역을 넘어 뉴스리더, 웹서핑, 메일 클라이언트, 파일매니저 등등등을 다 수행이 가능하고(vim으로도 가능하다.) 그만큼 제대로 사용하기가 엄청나게 어렵다.
예를 들어 문서의 특정 문구나 구간을 반복작업하거나 일명 '노가다 편집'을 해야 할 경우, vi의 입력기능을 사용하면 매우 단축시켜서 작업을 수행할 수 있다. 명령어를 외울 때도 자주 쓰는 명령어조차 키 조합을 추가로 조합해서 사용하는 경우가 잦은 Emacs에 반해 vi에서는 그냥 영문 단타로 끝나는 경우가 많아 금방 손에 익게 된다. 물론 강력한 사용을 위해서는 정규표현식도 습득할 필요가 있지만, 이것은 굳이 vi가 아니더라도 유닉스 환경이나 프로그래밍에서 모르면 안 되는 것에 속하고, 굳이 모르더라도 매크로 기능으로 대부분 대체가 가능하다. 말 그대로 키 스트로크를 레코딩해서 원하는 횟수만큼 자동 반복을 시키는 기능이다. 정규표현식의 경우 더 편리하긴 하지만, 사소한 오타에 왕창 잘못되는 경우가 많아(undo 기능이 있으니 큰 문제는 아니다.), 직접 눈으로 중간과정을 보면서 컨트롤이 가능한 매크로 기능을 더 애용하는 사람도 많다. 즉 기본적인 커서 이동, 모드 전환, kill/yank/put, 버퍼/창 관리에 더해 정규표현식과 매크로만 어느 정도 알아도 기본적인 사용에는 거의 문제가 없으며, 텍스트 편집 시 훨씬 적어지는 키보드 타수를 느낄 수 있다.
이것이 처음 나온 1976년 당시에는 사진과 같이 키보드에 화살표 키가 따로 배정되지 않았다. 일반 모드에서의 hjkl 키는 이 화살표 키를 대신하는 키들. vim에서는 화살표 키를 사용해도 된다.
Caps Lock 키와 LCtrl키를 뒤바꾸는 것도 아주 좋다.
세상에 공개되고 많은 시간이 흐른 만큼, 커뮤니티가 크고, 관련 노하우를 쉽게 검색할 수 있다. 커스터마이징이 쉽다는 점, 그리고 많은 사용자들이 사랑한다는 점이 만나 유용한 플러그인들이 굉장히 많이 개발되었고, 또 지금도 개발되고 있다. 관련 플러그인들은 공식 홈페이지의 스크립트 페이지나 Awesome 페이지에서 쉽게 접할 수 있다.
프로그래머를 위한 다양한 플러그인들이 존재하는데, 특히 YouCompleteMe를 추가하고, 각 개발 언어에 따른 세팅을 하고 나면 IDE와 동급이거나 그 이상의 편리함을 자랑한다.
굳이 Vi/Vim 오리지널 뿐만 아니라도 수많은 IDE 들은 Vi/Vim 의 키맵을 사용가능하다. 이는, IDE 마다 단축키를 따로 기억하지 않아도 된다는 장점도 같이 가져온다. 만약 본인이 사용하는 플랫폼, IDE 가 너무 다양하여서 단축키 설정이 곤란하다면 전부 Vi/Vim 플러그인을 사용한다면 단축키가 통일되게 된다.
6. 단점
|
|
|
"전 지금 거의 2년째 vi를 사용하고 있어요. 어떻게 나가는지를 모르거든요." |
- 프로그램 자체의 단점
- 조작의 어려움은 차치하고서라도, vi/Vim 은 POSIX 기본 에디터 역할 까지만 해 준다. IDE 혹은 현대식 에디터들을 사용 할 수 있는 환경이라면 vi/Vim 은 아무리 플러그인을 붙여도 강력한 자본하에서 개발한 도구들보다 기능이 많을 수는 없다. 이러한 특징 때문에 vi/Vim 그 자체는 터미널 연결/ 레거시 유지/ 설정파일 변경의 용도로 한정되는 경우가 많다. 플러그인을 다 일일이 설치하는 수고를 한다고 치더라도, 그 노력이면 VScode나 sublime text 와 같은 에디터에 Vim 플러그인을 사용하는것이 훨씬 빠르게 환경 설정이 완료 될 것이다.
- 정규 표현식이나 GVIM 자체 렌더링 속도가 빠르지 않다. 요즘 컴퓨터에서 아주 문제될 정도는 아니지만 심한 경우에는 버벅거리는 경우가 있는데 주로 IDE처럼 변수명 하이라이팅을 하면 이런 일이 생긴다. 해결 방법은 하이라이팅을 끄든지, 참고 쓰든지, 다른 에디터로 갈아 타든지.
- 한글을 사용하는 사용자라면 입력 모드에서 ESC를 눌러 일반 모드로 전환 시 한글 입력 모드를 영어 입력 모드로 변환해야 하는 번거로움이 있다. vim 자체에서 해결하는 방법도 있지만, pc 환경에 따라 해결이 안 되는 경우도 많다. 이 경우 ESC를 누를 시 자동으로 영어 입력 모드로 변환이 가능한 fcitx나 UIM 같은 입력기를 사용하는 것이 좋다. fcitx의 경우 felis vim 플러그인을 사용하면 되고, UIM일 경우 ESC를 누를 시 자동으로 영어 입력 모드로 변환해 주는 입력기 자체 기능을 사용하면 된다. vim을 주로 사용하는 사용자라면 ibus를 사용하지 않는 것이 정신건강에 이롭다. 사실 ibus는 다른 프로그램과도 호환성이 좋지 않다. 일례로, JetBrains 사의 IDE들은 ibus 입력기가 감지되면 경고를 내뿜는다!
- 조작방식의 단점
- 초심자가 익숙해지기까지의 과정이 험난하다. 까놓고 말하면 불편하다. 숙달되면 편하고 강력하다지만 일단 숙달이 필요하다는 것 자체가 불편하다는 가장 큰 증거다. 이미 vi에 익숙한 사람들은 넉넉잡아 하루 '정도'면 기본적인 조작은 습득 가능하다고 하는 등 이런 장벽을 과소평가하는 경향이 있는데 그건 바둑 기본 규칙 대여섯가지 알려줘 놓고 이제 바둑을 '둘 수 있다'고 말하는 것과 다르지 않다. vi의 강력함은 수많은 명령어와 이들의 조합/연계에서 오는데, 이것을 하루이틀만에 배우고 써먹는 것은 불가능하다. 그리고 그 단계에 이르기 전까진 vi는 그 어떤 면에서도 메모장보다 메리트가 없다.
-
vi의 키맵은 오늘날의
사용자 경험을 전혀 따르지 않는다. 예를 들어
Ctrl CV로 복사와 붙여넣기를 하는 것은
사실상 표준이지만, vi는 Copy-Paste 단축키의 표준화 이전에 만들어졌기 때문에 Y(yank)와 P(put)를 사용하는 등, 아예 사용하는 약자의 단어 자체가 다르다.[9][10] 화살표 대신 hjkl을 쓰고 Del 대신 x 같은 명령어를 쓰는 것도 익숙해지면 타이핑 기본 자세에서 커서를 움직일 수 있고 키보드 구석까지 손을 안 가져가도 되는 획기적인 배열이겠지만, 배우는 입장에선
WASD 같이 직관적인 방향이 있는 것도 아닌 그냥 평면에 화살표 그려놓은 것일 뿐이다. 무엇보다 인간은 새 것을 배우는데 인색하다. 보통 사람들은 십중팔구는 "우왕, 열심히 hjkl 키를 익혀서 더 편하게 써야지!"라는 반응이 아니라 "요즘 버전은 화살표도 지원하잖아? 걍 화살표 쓸게." 같은 반응을 보인다. hjkl을 제외하면 의미 위주의 키배치라 누르기 편하지도않다. ctrl+b, f처럼.. hjkl도 wasd나 ijkl에 비해 누르기 힘들고 익숙해지기 힘든편이다.
-
현재 키보드 배치에서는 vi에서 가장 중요한 키인 Esc가 왼쪽 위 구석에 박혀있기 때문에 vi의 장점인 손이 많이 안 움직여도 된다는 사실도 반감되었다. vi가 타겟으로 했던 키보드에서는 현재의 Tab 위치에 Esc가 위치해 있었다. 보통은 Caps Lock과 Ctrl 위치를 바꿔 쓰는 경우가 많은데, vi의 경우는 위와 같은 이유 때문에 추가적으로 Tab과 ESC 위치를 바꾸는 것도 권장된다. 아니면 Ctrl보다 Esc를 vim에서 압도적으로 많이 쓰는 걸 생각해서 Ctrl은 그냥 냅두고 Caps Lock에 Esc를 맵핑하든가 할 수도 있다. 사실 Ctrl+[가 Esc와 똑같은 기능을 수행하므로 불가능하지는 않으나,
vim 좀 쓴다는 사람들 중에도 모르는 사람이 많다. 또, vi에 익숙하다고 해도 유닉스 터미널에서 프로그래밍 하는 게 아닌 한 다른 일 하기 위해 결국
마우스에는 손이 가야 한다는 점도 있다.
- vi가 매우 강력한 편집기능과 모드 스위칭 구조를 가지고 있다는 것은 곧 vi가 편집에 집중한 '에디터' 이지, 순수하게 '입력'을 받는 것을 지원하는 기능을 목적으로 만들어진 것이 아니라는 것이다. 프로그램 시작 모드부터가 이미 존재하는 파일을 '편집' 하면서 시작하는 것을 전제하고 만들어져 있기 때문에, vi는 데이터 혹은 소스 코드를 반복적인 노력 없이 빠르게 편집하는 것이 목적이지, 순수한 작문과 같은 문서 작성을 주로 할 것을 기대하고 만들어지지 않았다. 이 점에서 아예 입력하기 위한 공란만을 제공하는 다른 기초적 에디터들은 편집모드라는 고급기능을 제공하지 않기 때문에 더 단순하고 기능이 적지만, 역설적으로 더 직관적으로 접근해서 순수한 '타이핑 입력도구' 용으로도 의미가 있는 반면 vi는 기본 설계가 어느 정도 그러한 사용자에게서 멀어진 채로 만들어져 있다.
- 현실적인 이슈
- 빠른 코딩을 도와준다는 장점도 상황에 따라서 다를 수 있다. 개발이라는 것은 소스코드 타이핑만 해서 끝나는 것이 아니기 때문이다. 디버깅은 물론이고 고객상대를 해야 할 때도 있다. 이 모든 개발주기 과정에서 과연 소스코드 타이핑이 본인 작업에서 긴 시간을 차지하는 것인지 생각 해 볼 필요가 있다. 그 작업시간중에 타이핑 시간이 길지 않다면 시간들여 VIM의 모든 사용법을 연습할 필요는 없을것이다.
- Vim 과 그 조작방식은 적응하면 매우 효율적인건 맞으나, 어디까지나 개발을 도와주는 개발환경이지, 할줄 모르는 일을 할 수 있게 만들어주는 마법의 도구는 아니다. 본인이 vi/Vim 을 배우는것에 회의감이 든다면 본인에게만큼은 vi/Vim 은 비효율적인게 맞으며, Vim 사용할 시간에 다른일을 하는것이 좋을 수도 있다.
- 유의미한 프로젝트 성과가 있는 사람들한테 vi/Vim 조작방식을 제시한다면 꽤 많은 사람들은 "와 내가 필요하던 커맨드가 다있네!" 라는 느낌을 받을 것이다. 이런상황에서는 vi/Vim 조작방식을 배우는데 얼마 걸리지 않을 것이다. 하지만 이제 막 프로그래밍 문법 배우는 사람이라면 "내가 왜 이걸 써? 더 좋은거 많은데" 라는 느낌을 받는 경우가 많을 것이다. 초심자가 vi/Vim 키맵을 배우는데 동기부여 받기는 힘들다.
숙련된 프로그래머가 사용할 경우 일반적인 편집기보다 빠르게 소스 코드를 편집할 수 있긴 하나, 그렇다고 현대의 개발업계에서 생산성을 극적으로 올려 준다고 보기는 힘들다. 예를 들어 윈도우즈 프로그램을 vi와 WinAPI를 써서 개발하는 것보다 그냥 VS와 MFC로 개발하는 것이 더 빠를 것이며, Visual Studio, IntelliJ IDEA, 이클립스 등 강력한 IDE에서 언어에 특화된 여러 기능들을 제공하기 때문에 그런 기능을 이용하지 않는다면 구질구질하게 암기해서 타이핑 할 것을 내장된 단축키 조합만으로도 코딩, 리팩터링 작업을 할 수도 있다. vi가 텍스트 편집에 이점이 있더라도 좋은 프레임워크와 클릭 몇 번으로 많은 타이핑 작업을 대체할 수 있는 IDE를 사용하는 것보다 생산성이 높다고 할 수는 없다. 게다가 최근의 IDE의 경우, 인텔리센스 및 스마트 리팩토링 기능이 워낙 강력해서 평범하게 입력하는 것 만으로도 상당한 정보를 자동완성해주거나 코드를 꼬이지 않게 자동으로 수정해 주는 기능이 매우 뛰어나 vim의 '매크로화된 단축 입력'의 빛이 많이 바랬다. 심지어 최신 Visual Studio의 경우 딥러닝 인공지능이 현재 입력하고 있는 코드를 보고 '아마 앞으로 이런 동작을 하는 이런이런 코드를 입력할 것 같다' 라고 자동완성 제안으로 코딩을 대신해주는 등 어마어마한 수준의 기능들이 IDE에 추가되는 실정이다.
물론 vi와 육중한 IDE의 기능은 서로 충돌하는 것이 아니다. vi의 핵심은 키맵이고, IDE의 핵심은 특정 언어에 특화된 여러가지 편의 기능들이다. 즉, 다양한 편의 기능을 갖고 있는 IDE에 vi의 키맵을 올려 사용한다거나 혹은 vi에서 편집하고 IDE로 불러와서 원하는 기능을 적용하는 식으로 얼마든지 절충이 가능하다. 단순한 비호가 아니고, vi와 IDE를 동시에 사용하는 프로그래머도 적지 않으며, 실제로 많이 쓰는 IDE&편집기에는 vi 플러그인이 있는 경우가 많다. 그 예는 아래 번외편을 참조.
반대로, 전세계 vim 덕후들이 만들어 놓은 vim 플러그인을 붙이고 설정 파일 커스터마이징하면 텍스트 편집기 수준을 넘은 강력한 자동 완성 기능을 포함한 일종의 IDE로 만들어 놓을 수 있다.
7. 매뉴얼
다음은 vi에서 주로 사용하는 3가지 모드.- 입력 모드: 일반 모드에서 i(현 커서 위치에서 입력모드), a(현 커서 한 칸 뒤에서 입력모드), o(한 줄 추가 후 입력모드)등을 입력했을 때 자동으로 들어가는 모드로, 이 상태에서만 텍스트 입력이 가능하다.
- 일반 모드: 화살표 이동이나 특정 문자 수정/삭제 및 편집에 쓰이는 대부분의 명령어가 여기서 실행된다. 이 모드가 기본 모드이다.
- 명령 모드: 시스템과 관련된 부분을 담당하는 모드. 일반 모드에서 :(콜론)을 누르면 된다. 다음 명령을 사용할 수 있으며, 뒤에 느낌표를 붙이면 강제 명령으로 실행된다. 입력한 명령어는 하단 버퍼에서 볼 수 있다. 기본적인 것만 알아보면,
- w: 파일을 저장한다.
- q: vi를 종료한다. 파일을 변경하고 저장하지 않은 채 이 명령어를 사용하하면 종료가 되지 않고, 이때 강제 종료를 원하면 !를 붙여 q!를 입력하면 된다. 화면 분할을 해서 여러 개에 동시에 명령을 입력하고 싶다면 all 혹은 a를 추가하면 된다. 즉, 여러 파일을 동시에 닫아버리고 싶을 때는 qall (혹은 qa, 이하 all은 a로 축약 가능), 다수의 파일을 저장하지 않고 강제종료 하려면 qall!, 그리고 다 저장하고 종료하려면 wqall을 입력하는 식이다.
- wq: 파일을 저장하고 vi를 종료한다. 마찬가지로 강제 적용[11]은 !를 붙여 wq!로 쓴다.[12]
일단 처음 사용할 때는 대부분 기존에 있는 파일을 수정하는 경우일 것이다. vi는 리눅스를 처음 접할 때 거의 백이면 백 필수적으로 접하게 되고, 리눅스의 각종 설정 변경은 설정이 담겨 있는 텍스트 파일을 직접 수정하는 일이 많기 때문이다. 이 경우는 많은 명령어를 기억할 필요 없이 위에 있는 설명만으로도 충분히 사용 가능하다. 요즘 리눅스 배포판에 기본으로 들어 있는 vi는 입력 모드가 일반적인 텍스트 에디터와 거의 비슷하게 작동한다. 커서도 화살표 키로 이동 가능하다.
vim에서는 wq 대용으로 x 명령어가 있다. :x 의 경우 변동 사항이 없으면 그냥 종료한다. 반면 :wq는 항상 저장하고 종료한다. :x와 달리 :X는 파일 암호화에 사용되는 명령이므로 절대로 혼동하지 않도록 하자.
스크립트를 통한 확장 기능을 사용할 수 있다. vim 사이트에서 하나씩 받아서 적용할 수도 있으나, vundle이란 확장 기능을 통해 플러그인 설치 자동화를 할 수 있다. http://wiki.kldp.org/wiki.php/VimEditor 에서 vundle 관련 내용을 참조.
- 기본적인 사용키 일람 : #
- 더 자세한 매뉴얼은 여기 : # 매뉴얼 한글번역(v7.4 기준)
- 윈도우용 최신 버전은 여기 : #
- vim 플러그인들을 정리해 놓은 곳 : #
- 보기 드물게 vim을 활용하여 웹개발을 학습하는 곳, vim 튜토리얼도 제공한다 : #
8. 관련 프로그램
8.1. IDE 및 에디터 플러그인
| Visual Studio | VsVim |
| Xcode | Xvim |
| Eclipse | Vrapper |
| IntelliJ IDEA / Android Studio | IdeaVim |
| Atom | vim-mode-plus |
| Visual Studio Code | VSCodeVim |
| NetBeans / JBuilder | jVi |
| Jupyter notebook | jupyter-vim-binding |
| Sublime Text | vintage |
| Emacs | Viper Mode Evil |
| Qt Creator | FakeVim |
8.2. 웹 브라우저 플러그인
브라우저에 vim의 키 매핑을 적용해서 웹서핑을 즐기는 것도 가능하다. 마우스나 트랙패드의 필요성이 사라지거나 최소화된다. 특히 포인팅스틱이 탑재된 키보드와 같이 사용하면 매우 최적화된 웹서핑을 할 수 있다. 키보드 정중앙에 위치한 포인팅스틱과 키보드 아래의 버튼들이 마우스 역할을 대신하고, 그럼으로써 키보드에서 손이 떠나지 않고 웹서핑을 할 수 있기 때문이다.하지만 어디까지나 브라우저 확장기능이기 때문에, 확장기능 제한이 걸린 페이지에서는 동작하지 않을 가능성이 매우 크다.
| Firefox | Vimium - FF[13], Vim Vixen[14] |
| Chrome, Chromium | cVim, Vimium |
| Microsoft Edge | Vimium C[15]] |
| Opera | VimOperate[16] |
| Safari | Vimari |
[1]
예컨대 셸에 디렉토리의 파일과 디렉토리를 모두 보여주는 유닉스/리눅스 명령인 ls를 치면 모니터가 아니라 연결된 프린터를 통해 종이에 해당 명령의 결과가 표시되는 식이었다. 물론 이때 프린터는 구식 카드단말기의 '찌지직~'하며 영수증을 뽑아내는 서멀 프린터처럼 도트 형태의 프린터라 매우 느렸다. 거의 초당 2줄 정도를 인쇄한다고 생각하면 쉽다.
[2]
할 일 없는 주말에 만들었다는 설도 있으나 나중에 인터뷰에서 진짜 주말에 잠깐 해서 만든건 아니라고 이야기했다.
[3]
쿼티 키보드 상에서 나타나는 HJKL 순서로 놓으면 ←↓↑→이 되는데 이는
댄스 댄스 레볼루션의 화살표 순서와 일치한다. 단순한 우연인지 아니면 DDR 제작진들이 HJKL 순서를 참고했는지는 알려지지 않았다.
[4]
다만 이런 세팅 없이도 Emacs의 키맵은 처음부터 쓸 수 있긴 하다.
[5]
선택을 쓴다고 v를 누르면 (혹은 입력 모드에서 Ctrl+X-Ctrl+E를 누르면) 소위 커맨드 라인 편집 모드(command line editing mode)라고 해서 미리 지정된 편집기에서 쓰고 있던 명령 라인을 수정할 수 있다. 명령어가 너무 길어지면 나름 쓸만한 물건이다. 다만 기본으로 지정된 편집기가 쓰던 것과 다를 수 있다. 예를 들어 우분투에선 무려 nano가 기본으로 지정되어 있다. $VISUAL이나 $EDITOR를 바꿔서 원하는 걸로 바꾸자. 다만 zsh에서는 안 먹히는 듯.
[6]
지 혼자 들여쓰기의 간격이 2배(8칸)라든가
[7]
일부 대학이나 교육기관에서 교수나 강사가 저지르는 가장 큰 실수중 하나라고 볼 수 있는데, 리눅스를 겨우 버츄얼 머신에서 설치한 교육생에게 대충 기능설명 후 바로 터미널과 vi부터 꺼내 윈도우나 맥보다도 너무나도 다른 에디팅 환경에 놀라 리눅스 포기자로 만들어 버린다.
[8]
취소선이 쳐져있지만 실제로 진성 vi 유저는 이것을 최강의 장점으로 친다. 사용법만 익히면 이만하게 손이 덜움직이는 에디터도 없다는 뜻이다. 세벌식 자판기와 비슷한 부분.
[9]
당장 MS-DOS 시절의 도스 에디터만 하더라도 복사를 Ctrl+Ins, 붙여넣기를 Shift+Ins로 사용했다. 도스 시절
아래아 한글도 마찬가지. Ctrl+C,V가 보편화된 것은 윈도우 시절에 들어선 이후이다.
[10]
물론 터미널에서 Ctrl C를 누르면 중지
인터럽트가 나가기 때문에 vi에만 한정된 문제는 아니다.
[11]
읽기전용 파일을 수정 후 저장할 때라든지.
[12]
wq!는 ZZ(shift 누른 상태로 z키 연타), q!는 ZQ로 대신할 수 있는데, 이쪽은 엔터를 칠 필요 없이 입력하는 즉시 실행된다. 익숙해지면 매우 편하다!
[13]
아래 Vimium의 파이어폭스 포팅 버전.
[14]
파이어폭스 57 이상 버전과 호환된다.
[15]
개발자가
하나의 중국을 지지한다. [[https://github.com/gdh1995/vimium-c?tab=readme-ov-file#declaration-for-applicable-regions|#]
[16]
404에러와 함께 플러그인이 설치되지 않을 경우 크롬 플러그인을 사용가능해주는 오페라 플러그인(
Install Chrome Extensions)을 설치한 다음,
Vimium을 설치하면 된다. 자세한 사항은
https://superuser.com/questions/406210/what-is-the-closest-pentadactyl-vimperator-clone-for-opera 참고하기 바란다.