이 글은 2024년 7월 25일 제 이전 블로그에 올렸던 글입니다.
https://codenested.blogspot.com/2024/07/lite-xl-5.html

---

고대 중국에 나를 날마다 새롭게 한다는 뜻인 일신우일신(日新又日新)이라는 고사가 있습니다. 이 말을 가슴에 안고, 저는 종종 개발 환경에 변화를 추구하곤 합니다.

한동안 저는 Vim으로 대표되는 "modal editing" 환경에 좀 회의적이었습니다. 아니 왜 내가 삽입/일반/비주얼로 모드를 바꾸는데 신경을 써야 돼? 모드를 변경할 필요 없이 모든 작업을 수행할 수 있다면 모드 변경에 사용되는 시간과 써야 되는 신경을 절약할 수 있지 않을까?...... 뭐 이런 거죠.

이런 생각 아래, 저는 제 소중한 Vim을 대체할만한 무언가를 찾았고, 그 와중에 Lite-XL을 찾았습니다. 지금은 Vim으로 돌아온 상태입니다만, Lua로 개발된 이 에디터와의 5일동안의 기억은 꽤나 신선해서, 이를 기록으로 남기는게 좋겠다는 생각이 들었습니다.

무지하게 작은 footprint

말 그대로입니다. Vim처럼 footprint가 엄청 작습니다. 사실 메모리 사용량 자체는 Vim보다 살짝 높은 수준이긴 하지만 요즘 나오는 IDE급으로 징하게 무거운 코드 에디터들에 비하면야 애교 수준이고, Vim보다 높다는 것도 이게 Lua 기반이라는걸 고려해보면 뭐 나쁘지 않죠.

하지만 이 이야기인즉슨, 바닐라 상태에서는 Vim처럼 정말 아무것도 없습니다(......). LSP라던가, 들여쓰기 가이드라던가, 선택된 문자열과 동일한 문자열을 하이라이트하는 등의 기능들을 모두 플러그인 형태로 따로 설치해야 됩니다.

Vim에 .vimrc가 있다면, Lite-XL에는 .config/lite-xl/*이 있습니다. 이 디렉토리에 존재하는 Lua 스크립트를 이용하면 환경 설정이나 초기화 등을 쉽게 수행할 수 있습니다. 물론, 여러분이 저처럼 Lua를 모른다고 해도 큰 문제는 없습니다. 써있는 설명만 잘 따라하면 되더군요. 뭐...... 저같은 경우에는 혹시 놓치는게 없을까 싶어서 조심스럽게 읽어야 하긴 했지만, 그건 제 모국어가 영어가 아니라서 그럴 것 같습니다. ;)

반응속도는 최강

Lite-XL은 언제나 지연 없이 반응을 수행했습니다. 스크롤 애니메이션은 덤이고요. 파일간 검색부터 명령 팔레트에 이르기까지 "나 엄청 가볍다니까!"하고 외치는 듯한 느낌을 받았습니다. 쾌적하더군요.

LSP: 좋기도 하고 나쁘기도 하고

LSP 플러그인은 만족스럽습니다. 플러그인의 공식 github 레포지토리에서는 아직 플러그인이 완성되지 않았다고 하긴 합니다만 대부분의 주요 기능들은 잘 동작하는 상태고, 현 상황을 알려주는 오버레이 또한 친절하고, 뭔가 "끼어드는 듯한 느낌"이 없어서 좋았습니다(Vim LSP 플러그인이 띄우는 수많은 Virtual Text를 보셨다면 "끼어드는 듯한 느낌"이라는게 뭔지 이해가 되실겁니다). 오버로드 표시도 Lite-XL이 훨씬 뛰어나더군요.

하지만 심볼 검색 다이얼로그나 명령은 좀 헷갈리는 감이 있고, 몇몇 유틸리티들, 이를테면 심볼 타입 목록을 포함하는 심볼 검색 등은 빠져 있어서 좀 허했습니다. 물론 전체적으로는 괜찮은 편이라고 생각합니다. 이건 제가 새로운 인터페이스에 익숙해지기 위해 충분한 시간과 노력을 들이지 않아서, 그리고 제 업무방식을 Lite-XL에 맞게 바꾸지 않아서 혼란스럽게 느껴진 것일 수도 있거든요.

거의 모든 곳에 존재하는 단축키

이 에디터의 개발자들은 자신들의 오른손이 키보드와 마우스 사이를 왕복하는게 꽤나 거슬렸던 것 같습니다. 웬지 디자인이 마우스 사용을 최소화하기 위해서 노력하는 느낌이에요.

자주 사용하는 기능이라면 거기에는 어김없이 단축키가 설정되어 있습니다. 전 Lite-XL 개발자들이 자신들의 개발환경에서도 적극적으로 Lite-XL을 사용하고 있고, "속도광"일 것이라는 느낌을 받았습니다. 타이핑할때 절대로 시간을 허투루 소비하지 않겠다는 집착이 보인달까요.

다만 딱 한 가지, 윈도 분리에서는 좀 헷갈리긴 했습니다. Lite-XL이 + ijkl을 사용하는 반면, Vim은 Ctrl-W에 그 유명한 hjkl 조합을 사용하는 터라 방향을 헷갈리지 않을 수가 없었네요. :P

너무 큰 파일은 잘 못 다룹니다(feat. 4GB.txt)

흔하지는 않지만 전 가끔 몇 GB정도 되는 로그 파일들을 다뤄야 할 경우가 있습니다. Vim 9은 이 측면에서 매우 뛰어납니다. 몇 초 안에 모든 준비를 끝내지요.

동일한 파일을 Lite-XL에서 열려고 해보니 몇 분 정도의 시간을 기다려야 하고, 간혹 에디터가 버벅대기도 하더군요. 스크립트 언어에서 개발되어서 그렇다는 생각은 들지 않습니다. 멀리 갈 것 없이, Javascript로 만들어진 Visual Studio Code도 동일한 파일을 꽤 잘 다룰 수 있었거든요(뭐..... 메모리 사용량만 빼고요).

어쨌든, 전 이게 모든 분들에게 해당되는 사항은 아니라고 생각합니다. 굳이 매우 큰 텍스트 파일을 제어할 필요가 없다면 굳이 신경쓸 필요는 없으실 겁니다.

편집중 git checkout 금지 (응?)

Lite-XL로 몇몇 파일들을 열어놓은 상태에서 프로젝트에 git checkout을 실행해 몇몇 파일을 변경한 결과 에디터가 죽어버렸습니다(얼라리요). 그냥 운이 없었던 건지 버그인지는 모르겠지만, 하여간 뭐...... 그리 되었습니다.

작고 기민하지만 몇몇 부분에서는 아쉬운 에디터

대한민국에는 여자들은 열과 성을 다해서 식당 별점 및 리뷰를 쓰는 반면, 남자는 딱 두 가지 경우, 그러니까 "희생양은 나 혼자면 충분하다!"라고 할 정도로 개판(......)이거나, "이렇게 좋은 곳은 무조건 널리 알려야 한다!"라고 할 정도로 뛰어난 식당을 알게 된 경우에만 리뷰를 작성한다는 농담 아닌 농담이 있습니다.

Lite-XL의 경우에 대해서는, 이건 명백히 후자입니다. 특히나 Visual Studio Code를 대체할만한 가벼운 에디터를 찾는데, Vim의 미친듯한 낭떠러지급 학습곡선을 피하고 싶다면 강력히 추천합니다(참고: 전 Vim 사용자이긴 합니다만 Vim이 생산성을 최대화하는 유일한 길이라는 생각에는 적극 반대합니다. 목표를 달성하는데는 한가지의 길만 있는게 아니죠. 그런 측면에서 보면 VS Code는 매우 많은 사용자 환경과 경우의 수를 커버할 수 있는 폭넓은 환경을 제공합니다. C++만 봐도 MS의 Intellisense와 clang 중 하나를 선택해서 사용할 수 있는 경우는 흔치 않죠).

저의 경우는 몇몇 기능이 부족해서(특히 대용량 파일 제어부분이 뼈아팠습니다) Vim으로 돌아오긴 했습니다만, 여러분의 경우 만일 큰 파일을 제어할 일이 없으시다면 한 번 시도해보시는 것도 나쁘지 않을 것 같습니다.