에디터가 가끔 segfault로 인해 일주일에 한 번씩 크래시 발생함, 하지만 크게 신경 쓰지 않음, 단순히 다시 열면 됨이라는 식의 데이터 손실 접근 방식이 신기함, Helix에는 persistent undo가 없으니 다시 열어도 이전 상태로 돌아가지 않음
오랫동안 Vim/Neovim을 사용해왔고, 직접 커스텀 설정도 해보고 이미 만들어진 설정도 써봤으나, Vim을 정말 좋아함에도 Helix에서 따로 설정 작업 없이 바로 사용할 수 있는 부분이 매우 매력적임
그런데 Helix config 자체는 굉장히 원시적이라고 느껴서, 사실 Vim 첫 몇 년만 써봐도 Helix에서 얻는 환경을 복제할 수 있었을 것이라는 생각이 듬, 그리고 그렇게 해서 더 이상 설정 지옥이 없었음을 말하고 싶음
헬프 팝업이 가야 할 경로나 키바인드를 안내해줘서 너무 좋음, 평소에 "정의로 이동"이나 "레퍼런스로 이동" 같은 기능 자주 안 써서 단축키를 까먹기 쉬움, 이런 맥락 팝업이 널리 도입되면 좋겠고, 만약 입력을 망설일 때에만 똑똑하게 뜬다면 정말 유용하겠음
모든 앱에서 복잡한 키바인드를 쓸 때 맥락 도움말 팝업이 있으면 엄청나게 편할 것 같음, 특히 입력이 멈칠 때만 똑똑하게 보여주면 더욱 좋겠음
20년 간 Vim/Neovim을 써 왔지만, 최근 6개월 전에야 which-key라는 플러그인을 설치해서 매우 유용하게 쓰고 있음 which-key.nvim GitHub
Vim에서의 세팅 문제 맥락을 놓친 것 같음
주 언어 서버 세팅(예: "정의로 이동" 가능)을 제대로 구축하려고 계속 시도해봤는데, Vim이나 Neovim에서 쾌적한 환경을 만들기가 너무 어렵게 느껴졌음
Vim 세팅 복제에 동의하지만, Helix를 서버에 바로 설치해서 쓸 수 있다는 점이 매우 편리함
Vim 설정 및 관련 의존성 옮기는 번거로움이 없음, 개발 환경이 훨씬 포터블하게 느껴짐 (다만 복잡한 Vim 세팅만큼은 아니고 좀 더 기본적임)
헬프 팝업 기능에 100% 동의함, 이런 기능이 여러 곳에서 적용되면 매우 도움이 될 것임
특히 해당 아티클에서 관련 설명과 스크린샷을 보고 아주 강하게 이 기능을 갈망하게 됨
똑똑하게 timeout 등의 조건으로 팝업이 뜨면, 필요하지 않을 때는 방해받지 않고, 망설일 때만 자동으로 안내받을 수 있어서 훌륭함
Helix를 3년간 거의 매일 썼지만 segfault로 다운된 것은 손에 꼽을 정도로 드문 경험임, 거의 없는 일임
Helix에 푹 빠져서 모든 개발에 사용하고 있음
이전까지 neovim과 VS Code를 주로 썼는데, Helix가 특별한 장점을 채우고 있음
디자인이 아름다움 (디테일에 신경 많이 씀)
빠른 퍼포먼스 (느릴 거란 생각이 든 적 없음)
기본 키바인드가 몸에 착 달라붙는 인체공학적 설계
설치하자마자 설정 없이 바로 쓸 수 있음
neovim을 설정하거나 vim을 계속 쓰는 게 귀찮아서, VS Code와 nvim의 중간 지점이 필요했는데 Helix가 딱임
만약 vimscript 마스터였으면 고민이 달랐을 수 있으나 나는 아니기에 딱 좋음
Helix가 더 모듈식이거나 UNIX처럼 동작할 필요 없이 지금처럼만 가주면 좋겠음
이미 다양한 도구 Ecosystem이 존재하고, Claude Code와도 연동하여 쓸 수 있음(버퍼 리프레시로 새 편집 적용)
최고의 에디터 중 하나라서 매달 프로젝트 후원도 시작함
앞으로 발전을 바란다면, 에디터에서 이미지나 수식 렌더링이 되는 기능이 가장 아쉬움, 이 부분은 Kitty terminal 프로토콜이나 sixel같은 플러그인으로 구현되길 기대함
마크다운 파일로 노트/블로그 작업할 때 특히 유용하게 쓰고 싶음
Helix의 건승을 바람
Helix처럼 설치 직후 바로 쓸 수 있는 앱은 supply chain attack에 대한 걱정이 줄어들어서 매우 안심임
VSCode나 (neo)vim은 여러 군데에서 플러그인을 받아와야 해서 항상 불안했음
nvim과 vscode 사이 중간이 필요하다면, 그냥 vscode에 vim 플러그인 써도 되지 않느냐는 의문이 있음
나는 helix도 좋아하지만 nvim도 포기할 건 아님
lua 개발자는 아니지만, LLM이 nvim 설정을 하거나 수정하는 데 큰 도움을 줌
helix로 오게 된 가장 큰 계기는 LSP/린트 설정이 너무 잘 되어있다는 점임
“vimscript 마스터”라는 표현 대신 사실 neovim은 Lua를 써야 하지 않느냐는 의견
neovim에서 helix로 몇 주 동안 옮겨 보려고 했으나, 필수적인 기능이 아직 구현되어 있지 않아서 기록함
파일 트리 브라우저 기능: 플러그인 시스템의 일환으로 도입 거절, 아직 미구현 PR #5768
이 외에 감수할 만한 사소한 것들도 있었음, 1~2년 후 다시 도전해볼 생각임
나는 homebrew로 HEAD에서 자주 빌드하여 Helix 사용 중인데, Julia가 크래시가 잦다고 한 것에 놀람
HEAD에서 이미 머지된 기능에 대해 몇 가지 공유함 —
저장 시 코드 액션: 저장 시 훅으로 해결 가능(Go에는 적용), 하지만 다른 언어에는 적용 어려울 수 있음
퍼지 서치: 아주 오래전부터 내장되었고, 최근 리워크로 크게 개선됨
자동 버퍼 업데이트: 수시로 에디터를 백그라운드로 두는 경우가 많아 꼭 필요한 기능임
파일 트리: HEAD에서는 Space+e/E로 계층적 탐색기 가능, 비교적 최근 추가됨
링크된 파일 탐색기는 중단됐지만, vim-telescope 스타일의 탐색기가 올해 초에 Helix에 머지됨
이미 내장된 퍼지서치 기반 파일픽커가 있기에 일반 파일 탐색기가 추가적인 유틸리티를 많이 제공하지는 않음
나도 neovim에서 helix로 옮기려 했으나, 수십 년간 익숙해진 vim 명령어 근육 기억 때문에 작은 실수들이 쌓여서 금방 포기했음
Helix용 vim 키바인드 플러그인도 썼지만 부분적으로만 맞아서 더 실망감이 컸음
외부 프로그램(templ, sqlc 등)이 파일을 수정할 때 Helix가 자동으로 파일을 감지해 재로드하지 않는 점이 아쉬움
숙련된 Helix 유저는 어떻게 해결하고 있는지 궁금함
Helix를 쓰게 된 동기는 주로 언어 서버(LSP) 세팅 과정에서 옴
Vim/Neovim에서 쾌적하게 언어 서버 세팅하는 게 너무 일이 되어버려서 Helix로 옮기게 됨
하지만 지난 5년간 Neovim엔 배터리 포함처럼 모든 게 갖춰진 배포판이 생겨서 아주 쉽게 세팅할 수 있게 됨
많은 개발자들이 에디터 디버깅에 시간을 쓰고 싶어하지 않는 건 동의함, 그렇기에 JetBrains가 인기 있는 이유라 생각함
단, 20년 Neovim 사용자가 LSP 환경을 제대로 구축 못 해봤다는 부분은 좀 납득이 어렵고, 작성자의 솔직한 경험인지 의심이 드는 부분임
Vim에서 10년 넘게 써도 LSP 세팅을 한 번도 안 한 사례가 있음
결국 그마저도 전체 IDE를 쓰는 게 더 편해서 설치와 세팅에 늘 망설임이 있었음
나도 20년 넘게 vim → neovim을 사용해왔으나 LSP가 깨지고 단축키도 같이 안 먹히면 뭔가 원인 찾고 싶지 않아지는 심리 장벽이 큼
작성자의 사례가 공감됨
놀라움, og나 neovim에서 LSP 세팅에 힘들지 않았음
나도 설정은 최소화해서 barebones로 쓰는 편인데 어렵지 않았고, Lua가 vimscript보다 훨씬 인체공학적이라 느낌
ALE 같은 툴을 계속 쓰게 되는 이유임
Helix 사용하는 것도 행복하길 바라는 마음임
완전히 이상하게 느껴짐, 네오빔의 LSP 내장된 지 두 해 넘었지 않았느냐는 질문
중견 기업들이 vscode 툴링으로 표준화하는 현상이 눈에 띔
다른 에디터도 쓸 수는 있지만, 거의 모든 디버깅, 설정이 vscode 중심이라 사용을 권장하는 분위기
Neovim+treesitter+LSP 세팅도 이미 아주 부드럽게 잘 되고 있음, 과거엔 힘들었어도 요즘은 큰 이슈 아님
Helix로 가는 동기가 LSP 때문이라면 의문, 혹시 작성자가 LSP에 불만이 맞는지 모르겠음
Helix의 noun-verb(객체-동작) 모델은 처음엔 신선했으나, 써보니 verb-noun(동작-객체)이 훨씬 잘 맞음
noun-verb 방식의 단점 중 하나가 반복 명령(.)이 불가능함
Vim에서는 dd.., dap.. 등 반복 동작이 가능한데, noun-verb 모델은 이게 어려움
더욱 근본적으로 키 수가 부족해지는 문제가 있음
너무 많은 기본 조작에 Alt 키를 써야 하고, vim처럼 normal/visual/insert 모드가 없고 visual/insert만 있음
motion/객체 구분까지도 명확하지 않아서 키 맵핑 난이도가 올라가고 키 모자람 현상이 생김
verb-noun 방식은 사고방식까지 바꿔줌
실제로 코드를 작성할 때 필요한 사고와도 더 잘 맞는 느낌임
nvim의 최근 최고의 변화는 mini.nvim임
echasnovski가 만든 플러그인 모음집으로, 다양한 필요와 일관성·문서화를 충족시켜줌
nvim 0.12(nightly)부터 내장 플러그인 매니저(vim.pack)로 mini.nvim과 lspconfig만 설치하면 충분함
lsp 같은 “고급” 에디터 도구를 아예 포기하는 게 얼마나 자유로운 경험인지 감탄을 멈출 수 없음
neovim에서 플러그인, 자동완성, 심지어 문법 하이라이트도 없이 사용 중
이런 방식을 통한 자기 규율이 더 좋은 코드를 쓰게 만든다고 느낌
모두에게 맞는 건 아니겠지만 꼭 한번 해볼 것을 추천함
플러그인 없이나 자동완성 없이도 살겠다는데 문법 하이라이트까지 끄는 건 괜한 고생 아닌가 싶은 의견임
아직 나도 완전히 전환하진 않았지만, Emacs에서 자동완성이 1년째 고장인데 별로 아쉽지 않음
코드 액션이나 goto definition도 쓰지 않고, 실시간 에러만 가끔 있지만 컴파일러가 워낙 빨라서 크게 의미가 없음
LSP를 꺼버리고 싶은 마음, 20년 전보다 LSP가 내 프로그래밍 실력을 대단히 끌어올려 준 건 아니라는 생각
문법 하이라이트 관련해서는, 알록달록한 테마가 오히려 집중을 깨고 의미도 없다고 생각함
단일색 혹은 2색 위주 테마를 선호하고, 변수명·함수명 색 구분조차 필요 없다고 느낌
Mitchell Hashimoto가 이 방법으로 업무를 잘한다고 듣고, 최신 툴링 없이도 충분히 생산적일 수 있다는 확신을 얻게 됨
다만 모든 걸 기억해야 하니 피로도가 누적되지 않는지, 또는 이 방식이 실제로 더 좋은 코드를 만드는지에 대한 의문이 있음
나도 그 어떤 보조 도구 없이 코딩하지만, 문법 하이라이트만은 항상 켜둠
색상은 코드에서 실수나 에러를 눈에 더 잘 띄게 하고, 코드 탐색도 빠르게 해주는 한 차원 더 많은 정보임
개인 프로젝트에서는 이런 미니멀 세팅을 도입함
너무 극단적으로 까지는 안 하고, 문법 하이라이트와 LSP를 통한 문법 오류 피드백까지만 유지함
오토컴플릿이나 문서 자동 링크는 사용하지 않음
Helix 배우고 싶다면, nic-revs가 만든 Helix 문서 리뉴얼 버전을 추천함 helix-editor.vercel.app
공식 문서보다 훨씬 보기 편하고, 팁/트릭도 많아서 효율적인 편집법이나 키바인드 등 Helix의 단점(터미널 내장 없는 점 등)을 완화할 수 있음
Hacker News 의견
오랫동안 Vim/Neovim을 사용해왔고, 직접 커스텀 설정도 해보고 이미 만들어진 설정도 써봤으나, Vim을 정말 좋아함에도 Helix에서 따로 설정 작업 없이 바로 사용할 수 있는 부분이 매우 매력적임
그런데 Helix config 자체는 굉장히 원시적이라고 느껴서, 사실 Vim 첫 몇 년만 써봐도 Helix에서 얻는 환경을 복제할 수 있었을 것이라는 생각이 듬, 그리고 그렇게 해서 더 이상 설정 지옥이 없었음을 말하고 싶음
헬프 팝업이 가야 할 경로나 키바인드를 안내해줘서 너무 좋음, 평소에 "정의로 이동"이나 "레퍼런스로 이동" 같은 기능 자주 안 써서 단축키를 까먹기 쉬움, 이런 맥락 팝업이 널리 도입되면 좋겠고, 만약 입력을 망설일 때에만 똑똑하게 뜬다면 정말 유용하겠음
20년 간 Vim/Neovim을 써 왔지만, 최근 6개월 전에야 which-key라는 플러그인을 설치해서 매우 유용하게 쓰고 있음
which-key.nvim GitHub
주 언어 서버 세팅(예: "정의로 이동" 가능)을 제대로 구축하려고 계속 시도해봤는데, Vim이나 Neovim에서 쾌적한 환경을 만들기가 너무 어렵게 느껴졌음
Vim 설정 및 관련 의존성 옮기는 번거로움이 없음, 개발 환경이 훨씬 포터블하게 느껴짐 (다만 복잡한 Vim 세팅만큼은 아니고 좀 더 기본적임)
특히 해당 아티클에서 관련 설명과 스크린샷을 보고 아주 강하게 이 기능을 갈망하게 됨
똑똑하게 timeout 등의 조건으로 팝업이 뜨면, 필요하지 않을 때는 방해받지 않고, 망설일 때만 자동으로 안내받을 수 있어서 훌륭함
이전까지 neovim과 VS Code를 주로 썼는데, Helix가 특별한 장점을 채우고 있음
neovim을 설정하거나 vim을 계속 쓰는 게 귀찮아서, VS Code와 nvim의 중간 지점이 필요했는데 Helix가 딱임
만약 vimscript 마스터였으면 고민이 달랐을 수 있으나 나는 아니기에 딱 좋음
Helix가 더 모듈식이거나 UNIX처럼 동작할 필요 없이 지금처럼만 가주면 좋겠음
이미 다양한 도구 Ecosystem이 존재하고, Claude Code와도 연동하여 쓸 수 있음(버퍼 리프레시로 새 편집 적용)
최고의 에디터 중 하나라서 매달 프로젝트 후원도 시작함
앞으로 발전을 바란다면, 에디터에서 이미지나 수식 렌더링이 되는 기능이 가장 아쉬움, 이 부분은 Kitty terminal 프로토콜이나 sixel같은 플러그인으로 구현되길 기대함
마크다운 파일로 노트/블로그 작업할 때 특히 유용하게 쓰고 싶음
Helix의 건승을 바람
VSCode나 (neo)vim은 여러 군데에서 플러그인을 받아와야 해서 항상 불안했음
lua 개발자는 아니지만, LLM이 nvim 설정을 하거나 수정하는 데 큰 도움을 줌
helix로 오게 된 가장 큰 계기는 LSP/린트 설정이 너무 잘 되어있다는 점임
HEAD에서 이미 머지된 기능에 대해 몇 가지 공유함 —
이미 내장된 퍼지서치 기반 파일픽커가 있기에 일반 파일 탐색기가 추가적인 유틸리티를 많이 제공하지는 않음
Helix용 vim 키바인드 플러그인도 썼지만 부분적으로만 맞아서 더 실망감이 컸음
숙련된 Helix 유저는 어떻게 해결하고 있는지 궁금함
Vim/Neovim에서 쾌적하게 언어 서버 세팅하는 게 너무 일이 되어버려서 Helix로 옮기게 됨
하지만 지난 5년간 Neovim엔 배터리 포함처럼 모든 게 갖춰진 배포판이 생겨서 아주 쉽게 세팅할 수 있게 됨
많은 개발자들이 에디터 디버깅에 시간을 쓰고 싶어하지 않는 건 동의함, 그렇기에 JetBrains가 인기 있는 이유라 생각함
단, 20년 Neovim 사용자가 LSP 환경을 제대로 구축 못 해봤다는 부분은 좀 납득이 어렵고, 작성자의 솔직한 경험인지 의심이 드는 부분임
결국 그마저도 전체 IDE를 쓰는 게 더 편해서 설치와 세팅에 늘 망설임이 있었음
작성자의 사례가 공감됨
나도 설정은 최소화해서 barebones로 쓰는 편인데 어렵지 않았고, Lua가 vimscript보다 훨씬 인체공학적이라 느낌
ALE 같은 툴을 계속 쓰게 되는 이유임
Helix 사용하는 것도 행복하길 바라는 마음임
다른 에디터도 쓸 수는 있지만, 거의 모든 디버깅, 설정이 vscode 중심이라 사용을 권장하는 분위기
Neovim+treesitter+LSP 세팅도 이미 아주 부드럽게 잘 되고 있음, 과거엔 힘들었어도 요즘은 큰 이슈 아님
Helix로 가는 동기가 LSP 때문이라면 의문, 혹시 작성자가 LSP에 불만이 맞는지 모르겠음
noun-verb 방식의 단점 중 하나가 반복 명령(
.)이 불가능함Vim에서는
dd..,dap..등 반복 동작이 가능한데, noun-verb 모델은 이게 어려움더욱 근본적으로 키 수가 부족해지는 문제가 있음
너무 많은 기본 조작에 Alt 키를 써야 하고, vim처럼 normal/visual/insert 모드가 없고 visual/insert만 있음
motion/객체 구분까지도 명확하지 않아서 키 맵핑 난이도가 올라가고 키 모자람 현상이 생김
실제로 코드를 작성할 때 필요한 사고와도 더 잘 맞는 느낌임
echasnovski가 만든 플러그인 모음집으로, 다양한 필요와 일관성·문서화를 충족시켜줌
nvim 0.12(nightly)부터 내장 플러그인 매니저(vim.pack)로 mini.nvim과 lspconfig만 설치하면 충분함
mini.nvim 공식 사이트
mini.nvim GitHub 저장소
neovim에서 플러그인, 자동완성, 심지어 문법 하이라이트도 없이 사용 중
이런 방식을 통한 자기 규율이 더 좋은 코드를 쓰게 만든다고 느낌
모두에게 맞는 건 아니겠지만 꼭 한번 해볼 것을 추천함
코드 액션이나 goto definition도 쓰지 않고, 실시간 에러만 가끔 있지만 컴파일러가 워낙 빨라서 크게 의미가 없음
LSP를 꺼버리고 싶은 마음, 20년 전보다 LSP가 내 프로그래밍 실력을 대단히 끌어올려 준 건 아니라는 생각
문법 하이라이트 관련해서는, 알록달록한 테마가 오히려 집중을 깨고 의미도 없다고 생각함
단일색 혹은 2색 위주 테마를 선호하고, 변수명·함수명 색 구분조차 필요 없다고 느낌
다만 모든 걸 기억해야 하니 피로도가 누적되지 않는지, 또는 이 방식이 실제로 더 좋은 코드를 만드는지에 대한 의문이 있음
색상은 코드에서 실수나 에러를 눈에 더 잘 띄게 하고, 코드 탐색도 빠르게 해주는 한 차원 더 많은 정보임
너무 극단적으로 까지는 안 하고, 문법 하이라이트와 LSP를 통한 문법 오류 피드백까지만 유지함
오토컴플릿이나 문서 자동 링크는 사용하지 않음
helix-editor.vercel.app
공식 문서보다 훨씬 보기 편하고, 팁/트릭도 많아서 효율적인 편집법이나 키바인드 등 Helix의 단점(터미널 내장 없는 점 등)을 완화할 수 있음
오랜 vim 유저라면 kickstart(특히 모듈식 포크 kickstart-modular.nvim)를 추천함
kickstart.nvim
아주 미니멀한 시작점이라 훌륭함
다만 덩치가 커서 난 fold marker로 구간을 접어가며 관리를 더 쉽게 만듦