▲

Helix Editor 25.07

 (helix-editor.com)
1P by GN⁺ 19시간전 | ★ favorite | 댓글 1개
  • Helix 25.07은 핵심 컴포넌트의 대체와 다수의 신규 기능 추가를 포함함
  • 파일 탐색기, LSP 문서 색상 표시, 커맨드 모드 개선 등 사용성과 워크플로우가 크게 향상됨
  • 문법 하이라이트와 쿼리 최적화를 위해 신규 crate인 Tree-house가 도입됨
  • Tree-house는 인젝션 및 로컬 처리 능력과 성능, 유지보수성을 대폭 강화함
  • 향후 더 넓은 멀티랭귀지 경험 및 속도 개선 기반이 마련됨

Helix 25.07 주요 업데이트

Helix 25.07 릴리스는 오랫동안 기다려온 핵심 기능 교체와 다양한 신규 기능 추가로 구성됨. 이번 버전에서는 195명의 기여자가 참여함. Helix는 여러 선택, LSP, Tree-sitter, 실험적 DAP 지원을 갖춘 모달 텍스트 에디터임.

신규 주요 기능

파일 탐색기

  • 25.07에 <space>e로 사용할 수 있는 파일 탐색기 기능이 추가됨
  • 이 탐색기는 telescope과 유사한 UI를 제공함
  • 디렉터리 내 계층형 구조 탐색이 쉽고, 대규모 프로젝트 탐색 시 더 정밀한 제어가 가능함

LSP 문서 색상 표시

  • 이제 Helix는 LSP 서버에 문서 색상 정보를 요청하여 RGB 컬러 범위를 inline으로 보여줌
  • 예를 들어 tailwindcss-language-server, vscode-css-language-server 등에서 색상을 받아 코드 내에서 바로 색상 박스를 시각적으로 확인함

커맨드 모드(:) 기능 개선

  • 명령어 파싱 및 자동완성 코드 전면 재작성으로 버그가 수정되고 사용성이 높아짐
  • :write 계열 커맨드에 --no-format 플래그 등 플래그 지원 추가됨
  • 커맨드 내 변수/값 확장(%{variable_name}, %sh{명령어} 등) 기능과 자동완성 도입
  • 복잡한 입력 값 처리를 위해 확장성 있는 파서 구조로 변경되어 향후 커맨드 확장이 쉬워짐

Tree-house: Tree-sitter 통합 새 구조

Tree-sitter란

  • Tree-sitter는 빠르고 에러에 강한 파서를 생성·활용하는 프레임워크임
  • 문법 DSL로 파서 규칙을 작성하고, 에디터/툴 내에서 구문 트리를 생성 및 활용함
  • 예시로, GitHub의 코드 탐색·하이라이트, 코드 서버의 spell-check, diff 툴 등에서 사용됨
  • Tree-sitter 쿼리는 서브트리 패턴 매칭 및 구문 노드 캡처에 활용됨

Helix의 기존 Tree-sitter 연동과 문제점

  • Helix 초기에는 공식 Rust 바인딩(tree-sitter crate)과 tree-sitter-highlight 하이라이터를 이용
  • tree-sitter-highlight는 비증분적으로, 문서 전체를 항상 다시 파싱해야 하여 성능 저하 및 리소스 낭비 문제 발생
  • Helix는 이를 개선하려 자체 하이라이터 포크했으나, 점점 복잡화되어 유지보수가 어려워짐

Tree-house의 도입과 이점

  • Tree-house는 분리된 파싱/쿼리 구조, 깨끗한 코드, 기존의 고질적 버그 종결, 미래지향적 구조(병렬 파싱 등)에 중점을 둠
  • 핵심 강점은 인젝션(Injection) 의 강인한 처리임

인젝션(Injection): 복수 언어/레이어 지원

  • 인젝션은 예를 들어 Markdown 내 Rust 코드 블록이 등장할 때, 해당 범위만 Rust로 따로 파싱하는 방식임
  • 복잡한 케이스(예: Rust 주석 내 Markdown, 그 내부 코드 블록 내 Rust 등)도 트리 구조로 레이어를 관리하여 정확히 지원함

증분적 인젝션

  • 변경이 실제로 발생한 레이어만 빠르게 재파싱, 쿼리 실행하여 최소 작업 단위만 사용함
  • 매우 큰 리스트 또는 중첩 구조의 마크다운 문서에서 효율성 극대화됨

로컬 변수 하이라이트(lcals)

  • 함수 내 파라미터 등 로컬 변수를 선언과 참조 범위(스코프)에서 정확히 하이라이트함
  • 기존에는 정의가 뷰 밖에 있을 경우 하이라이트가 사라지던 고질적 문제를 Tree-house에서 해결함

전역화된 인젝션 지원

  • Syntax 타입에서 인젝션 레이어 탐색 및 조회가 로그(logarithmic) 시간에 가능함
  • TreeCursor, QueryIter 등 API로 전체 인젝션 레이어 적용이 가능해짐
  • HTML <script> 내 코드, Markdown 코드 블록 등 언어 경계 간 일관된 동작 구현 기반이 마련됨

마무리

  • Helix 25.07은 파일 탐색기, 색상 인레이, 커맨드 모드/파서 개선 등 사용성 혁신과 더불어 Tree-house 기반 신규 구조 도입으로 차세대 텍스트 에디터의 후보로 부상함
  • 상세 업데이트 내용은 changelog 참고 가능
  • 커뮤니티/기여 참여는 Matrix, GitHub 저장소를 통해 진행 가능
▲
GN⁺ 19시간전  [-]
Hacker News 의견

  • Helix는 정말 훌륭함, 파일 선택기, 구문 강조, 린팅 등 많은 기능이 플러그인 설치나 복잡한 설정 없이 바로 제공됨, 반면 vim이나 neovim은 기본적으로 많은 설정이 필요함, 사용하고 싶지만 주요 단점은 키 바인딩이 vim과 다르게 동작하는 점임, 나는 익숙한 “x”가 커서 아래 글자를 삭제하거나 “d”로 동작을 기다리는 등, 오랜 시간 써온 vim의 익숙한 키 동작이 그대로 아니면 헷갈리고 화가 나는 경험임, 아마 많은 vim 사용자들이 이 부분에서 비슷하게 느낄 것이고, 습관을 바꾸는 것이 무척 어려움, 특히 vim이 어디서나 기본적으로 있으니 벗어날 수 없는 환경임, 다행히 evil-helix라는 Helix 소프트 포크가 Vim 키 바인딩을 추가해 줘서 내가 겪는 불편을 가진 사람들에 추천하고 싶음, 또한 Helix와 evil-helix는 Windows(cmd)에서도 rust 설치 없이 .exe만 받으면 바로 잘 동작함

    • 나에겐 새로운 걸 배우고 싶지 않아서가 아니라 이 키 바인딩을 다른 곳에서 쓸 수 없다는 점이 문제임, 거의 모든 온라인 에디터와 워크스테이션은 vim 키 바인딩을 제공하고, 리눅스에 ssh 접속하면 항상 vim이 있다는 점이 중요함, 마치 쿼티 키보드처럼 더 나은 배열이 있더라도 거의 모든 환경에 즉시 적응할 수 있는 탄력성을 버릴 수 없다는 생각임

    • 새로운 툴을 배우는 데는 전혀 문제 없음, Helix를 충분히 써 봤지만 명사-동사 모델이 오히려 안 좋아 보였고, 시각적 피드백도 코드 읽을 때는 오히려 방해 요소가 됨, vim에선 단순히 마지막 명령 반복(‘.’ 바인딩 등) 같은 것들이 편하게 가능하지만 Helix에선 포기해야 함, 상태 관리도 vim보다 더 신경 써야 하여, vim은 파일 내 현재 위치만 챙기면 되지만, Helix는 내가 어디에 있었는지도 고려해야 함, 나는 기본 설정, 모달 에디팅, 필요 이상의 시각 동기화를 강요하지 않는 에디터를 원함, 동기화가 많으면 편집 언어로서의 장점을 잃게 됨, 편집 자체보다 더 흥미로운 프로그래밍에 집중하고 싶음, 집중력을 더 요구하는 편집기는 오히려 에디터로서 덜 좋은 편임

    • vim(neovim)을 20년 가까이 쓰다 helix로 넘어갔을 때 전혀 어렵지 않았고, 지금은 훨씬 더 선호함, 일부 모달 행동을 수정하긴 했지만 helix의 논리를 따르면서 사용 중임, 다중 선택이나 LSP 같은 기능이 기본 제공되고, 멀티스텝 입력 시 가능 행동을 힌트로 보여주는 강력한 도움말이 큰 장점임, 가끔 순정 vim을 쓸 일이 있어도, 머릿속 맵핑이 달라진 게 있어도 기본적 명령은 기억해서 금방 수정 가능함

    • Helix는 현재 프로그래머블 설정을 위한 Scheme을 추가 중임, 프로그래머블 기능이 들어오면 현재 emacs의 repeat/ transient map, 상태별 추적 등 다양한 미세 조정이 가능해질 전망임, LLMs 혁신 덕분에 8, 9번째 언어도 쉽게 만질 수 있는 세상에선 섬세한 설정이 가능한 도구가 시장에 더 부상할 거라 봄

    • vim 키 바인딩이 Helix를 안 쓰는 단 하나의 이유였음, 외부 포크를 통해 vim 지원이 가능하다면 Helix 공식도 원하면 지원할 수 있을 텐데 일부러 하지 않는 걸까 하는 생각임

  • Helix를 정말 좋아함, vim이 잘 안 맞았던 사람이나 vim 컨셉을 좋아하지만 쉽게 적응은 못 했던 분들께 강력 추천임, 기존 vim류보다 배우고 쓰기가 훨씬 쉬웠고, 기본 제공하는 설정도 매우 실용적임

    • Helix를 정말 좋아함, 솔직히 말해서 마우스 기반 파일 탐색기 등 GUI에서 약간의 편의를 더해준다면 vscode와 대적할 만한 강력한 경쟁력이 있다고 생각함

  • 이런 뛰어난 능력을 지닌 에디터가 여전히 미니멀하면서도 쓸데없는 AI 기능에 집중하지 않는 모습이 보기 좋음

  • 축하의 인사, Helix가 잘되길 바라지만 내게는 맞지 않는 느낌임, 나는 Neovim을 사용 중이고 원하는 게 거의 다 가능함, 하지만 완전히 만족하는 건 아니기도 함, 내가 원하는 에디터는 다음과 같은 조건이 있음:

    • 최신 코드베이스, 완전히 새로 작성됨
    • Vim 키 바인딩, 이 근육 기억력이 강하기 때문에 Vim 스타일 고집함, 더 낫다는 소리에 흔들리지 않고 꼭 Vim처럼 동작하길 원함
    • 좋은 기본값, Neovim은 설정이 너무 많고 기본값이 항상 만족스럽지 않음
    • Treesitter 기반, WASM 위에서 동작하게 하면 더 좋음(Zed, 최신 Neovim처럼)
    • 확장 시스템은 Lua, JS, Scheme은 별로, WASM 모듈로 필수 함수만 노출하는 수준이 이상적, 비튜링 완전 설정 언어로 플러그인 설정 희망
    • TUI와 선택적 GUI
    • LSP, DAP, 스니펫, 자동 완성, 테스트/디버깅 UI 내장
    • Oil.nvim 같은 파일시스템 뷰 내장
    • Telescope/FZF-lua 스타일의 검색 내장
    • 깃 통합, magit/neogit 같은 git UI 내장도 환영
    • Flash.nvim 스타일로 Treesitter 기반 AST 조작과 라벨 점프 내장
    • 매크로와 멀티 커서
    • 선택적 커서 기반 AI 통합(Chat UI)

    • 나도 Vim 근육 기억을 인정하지만, 많은 사람들이 여기에 너무 집착한다는 생각임, 나는 OS, 에디터, IDE를 여러 번 바꿔왔고, 바꾼 첫 며칠간은 음청 답답하고 화가 나고 농부나 할까 싶은데, 그 시간이 지나면 언제나 새 근육 기억이 생김, 며칠의 불편 때문에 소프트웨어의 다른 수많은 장점을 포기하는 건 아쉬운 일이라고 생각함

    • Helix가 언급한 조건 중 어떤 점을 못 미친다는 건지 명확하진 않음, 내 눈에는 Helix가 거의 다 충족하는 것처럼 보임

    • 요구 사항을 보면, 결국 Neovim에서 Lua만 다른 언어로 대체하는 것을 바라는 모습임

  • Helix를 사랑함, 축하를 보냄, 기본 테마가 예쁘고, 기본 설정도 뛰어남, 설치만 하면 바로 쓸 수 있고 별다른 설정 필요 없음, 완전히 IDE를 대체하진 않았지만 vi에 alias를 걸고 $EDITOR도 Helix로 지정함, CLI에서 빠른 수정이나 디버깅이 필요할 땐 항상 Helix를 사용하게 됨

  • Helix를 정말 좋아하고 호감이 있었지만 undo 동작은 뭔가 논리적이지 않고, 너무 많은 내용을 한 번에 취소하는 등 부자연스러웠음, 이로 인해 실제로 작업을 잃은 적도 있었음

    • Undo와 관련해 불편했던 점 두 가지가 있음:

      • undo 시 편집 내용이 화면에 없으면 해당 영역으로 점프는 잘 되지만, 같은 키 입력으로 바로 undo까지 되어서 헷갈림, 다른 에디터들은 내용이 보이지 않으면 점프만 하고 취소는 하지 않음, Helix에선 한 번 누르면 뭔가 바꼈는지 꼭 확인해야 함
      • undo가 너무 덩어리 단위로 이뤄짐, 삽입 모드로 30분 타이핑해도 모드 전환까지 한 번에 undo됨, 세이브 포인트는 직접 등록해야 하고, 나는 스페이스바에 할당해서 더 세밀하게 undo하려 했지만 이러면 선택 영역이 날아가는 등의 부작용 있음, 깔끔한 해결책을 찾지 못함, Helix 자체는 만족하지만 undo의 깊이가 직접 조작을 요구하는 것은 정말 아쉬움

    • Undo와 "마지막 명령 반복"이 조금 이상하긴 하지만, 나머지 기능이 좋아서 메인 에디터로 Helix를 쓰고 있음, 그런데 작업을 잃은 부분에선 다시 redo가 안 됐는지 궁금함

  • Helix에서 "Kakoune 모드"가 생기길 바램, 회사에서 Windows를 쓰다보니 Kakoune은 최적이 아니라 Helix가 완벽해 보였지만 키 바인딩을 넘어서기 힘듦, Helix의 키바인딩 철학은 Kakoune의 간결함보다 더 장황한 방식이라 그 점이 거슬림, 또한 Helix의 키 바인딩 설정은 Kakoune을 제대로 따라갈 수 있을 만큼 강력하지 않아 아쉬움, 나는 vim의 불일관성과 비논리적인 동작에 실망해서 Kakoune으로 넘어왔고, Helix는 이 부문에서 한 단계 후퇴한 느낌임

  • "포스트 모던" 에디터라는 말이 재밌음, Fish 셸의 "90년대를 위한 셸" 이후로 두 번째로 좋은 농담 같음, 영상으로 보니 TUI 기반인 게 인상적이고 Emacs TUI 느낌이 살짝 남

  • Helix 수준의 올인원 완결성을 지닌 vim 라이크 에디터가 정말 필요한 상황임, Neovim 배포판들은 각 요소들이 너무 느슨하게 결합되어 항상 뭔가 미묘하게 불편함, Vim 인터페이스 전반적으로 재설계가 필요하다고도 생각하지만, 동작-객체 중심의 모달 방식은 유지되었으면 함

    • Evil-Helix가 이런 요구에 맞는 듯 함, 험한 면도 여전히 많아 보이지만 확인해볼 만함 https://github.com/usagi-flow/evil-helix

    • Action-Object 모달 방식이 무엇인지 궁금함

  • Helix와 유사 에디터들의 구문 강조, 코드 이해 기능에 대한 상세 설명이 인상적이었음, tree-sitter 기반의 구조와 기능이 쿼리 언어에 딱 맞는 느낌이고, 심볼 검색이나 참조 찾기를 넘어 범용적인 쿼리 DSL 가능해 보여서, 혹시 이런 기능이 이미 존재하는지 궁금함

답변달기