Cara memanfaatkan editor Helix untuk pengembangan di server jarak jauh

 (rushter.com)
7 poin oleh GN⁺ 2025-10-14 | 2 komentar | Bagikan ke WhatsApp
  • Alasan memilih Helix sebagai editor untuk pengembangan di server jarak jauh adalah karena dapat digunakan tanpa memasang puluhan plugin seperti Vim/Neovim, sehingga bisa mengurangi risiko serangan rantai pasok
  • Melalui konfigurasi integrasi tmux, kekurangan Helix pada penjelajah berkas dan fitur Git TUI dilengkapi, serta diatur agar dapat menjalankan pengelola berkas yazi, lazygit, dan lainnya dalam popup
  • Dengan mengimpor keybinding bergaya Vim, pekerjaan seperti memilih baris, memindahkan kursor, dan menghapus teks diatur agar berperilaku mirip Vim, serta ESC diubah untuk mereset multi-cursor
  • Dengan menambahkan informasi seperti branch Git, encoding, dan posisi ke status bar (statusline), produktivitas meningkat
  • Dengan memanfaatkan injeksi Tree-sitter, kueri SQL di dalam Python/Go serta blok kode di Markdown dapat diberi penyorotan sintaks sehingga keterbacaan meningkat
  • Konfigurasi lanjutan seperti LSP, auto-save, dan mode warna dimanfaatkan untuk meningkatkan produktivitas dan melakukan kustomisasi secara rinci

Latar belakang memilih Helix

  • Karena meningkatnya serangan rantai pasok belakangan ini dan masalah ketergantungan plugin, Helix diadopsi sebagai editor untuk pengembangan di server jarak jauh menggantikan Vim/Neovim
  • Keunggulan utamanya adalah bisa digunakan hanya dengan fitur bawaan tanpa puluhan plugin Neovim
  • Setelah beralih ke Helix, dilakukan kustomisasi konfigurasi untuk mereproduksi sebanyak mungkin pengalaman Neovim yang sudah familiar
  • Hal ini dibagikan dengan tujuan menghemat waktu pengguna lain

Konfigurasi Tmux

  • Menggunakan Tmux sebagai terminal multiplexer, dan menambahkan keybinding kustom untuk mengatasi ketiadaan pengelola berkas dan Git TUI
  • Karena Helix tidak mendukung pengeditan berkas dari penjelajah berkas, berpindah cepat di antara banyak berkas terasa kurang nyaman
  • Tambahkan binding berikut ke berkas konfigurasi Tmux
    • prefix - y: menjalankan pengelola berkas Yazi dalam jendela popup (ukuran 95% layar)
    • prefix - g: menjalankan Lazygit dalam popup
    • prefix - e: membuka riwayat output Tmux di editor Helix untuk pencarian dan penyalinan
  • Prefix bawaan adalah Ctrl + b, tetapi diubah menjadi Ctrl + \\ saat digunakan
  • Berguna untuk pekerjaan yang melibatkan output terminal, terutama saat menyalin output klien ClickHouse (CSV/JSON) ke Slack
    • Alih-alih menulis ke berkas, hasil bisa langsung disalin sehingga langkah kerja berkurang
    • Bisa juga memakai mouse, tetapi scroll buffer Tmux kurang nyaman sehingga lebih efisien menanganinya lewat editor
  • Yazi dan Lazygit biasanya ditampilkan sebagai overlay di atas editor Helix

Mengimpor keybinding Vim

  • Meskipun sudah terbiasa dengan keybinding Helix, beberapa binding Vim tetap diimpor untuk digunakan
  • Binding mode Select
    • 0: pindah ke awal baris
    • $: pindah ke akhir baris
    • ^: pindah ke karakter pertama yang bukan spasi
    • G: pindah ke akhir berkas
    • D: pilih hingga akhir baris lalu hapus dan pindah ke mode normal
    • k/j: pilih seluruh baris atas/bawah (perilaku bawaan Helix hanya memilih sebagian sehingga terasa kurang nyaman)
  • Binding mode Normal
    • D: hapus seluruh teks di sebelah kanan kursor (diimpor karena Helix membutuhkan terlalu banyak penekanan tombol)
    • V: pindah ke mode Select lalu pilih seluruh baris
    • ESC: reset multi-cursor (default Helix adalah koma, yang terasa kurang nyaman)
  • Karena cara pemilihan baris di visual mode Helix kurang disukai, perilakunya diubah ke gaya Vim
    • Saat bergerak ke atas/bawah, diatur agar seluruh baris ikut terpilih

Status bar yang ditingkatkan

  • Status bar bawaan kurang memiliki informasi penting seperti branch Git saat ini
  • Susunan konfigurasi status bar
    • Kiri: mode, spinner, version control, nama berkas, penanda read-only, penanda modifikasi
    • Tengah: kosong
    • Kanan: diagnostik, diagnostik workspace, posisi, jumlah total baris, persentase posisi, encoding berkas, format akhir baris, tipe berkas, register, jumlah seleksi
    • Pemisah: menggunakan karakter │
  • Memungkinkan situasi kerja dipahami sekilas

Keybinding yang berguna

  • Dengan keybinding kustom, efisiensi kerja meningkat drastis, meski perlu waktu untuk menemukannya
  • Fitur yang paling berguna: reload berkas, toggle soft wrap, Git undo, Git blame, Git diff
  • Daftar lengkap binding kustom
    • space - e - w: simpan buffer saat ini ke berkas
    • space - e - c: tutup buffer saat ini
    • space - e - x: tutup semua buffer lain (berguna saat puluhan buffer terbuka)
    • space - e - l: toggle inlay type hints (berguna, tetapi jika selalu ditampilkan menimbulkan banyak noise)
    • + - f: format berkas saat ini
    • + - w: render karakter spasi/whitespace (untuk memeriksa karakter tak terlihat dalam dokumen)
    • + - W: nonaktifkan render karakter spasi
    • space - f - .: tampilkan/sembunyikan berkas yang diabaikan Git di file picker
    • space - f - r: reload semua berkas (sangat berguna karena Helix tidak mendukung auto-reload, untuk perubahan eksternal atau pembaruan gutter setelah commit)
    • space - f - x: undo perubahan Git pada posisi kursor saat ini
    • space - f - w: tampilkan Git blame untuk baris saat ini
    • space - f - d: tampilkan Git diff

Konfigurasi editor

  • Setelah 6 bulan penggunaan, ditemukan bahwa ada fitur auto-save saat berpindah tab terminal
  • Beberapa fitur terbaru Helix dinonaktifkan secara default, agar pengguna lama tidak mengalami perubahan tak terduga
  • Fitur baru hanya bisa ditemukan dengan memeriksa tiap opsi secara langsung
  • Opsi konfigurasi utama
    • line-number = "relative": tampilkan nomor baris relatif
    • rulers = [120]: atur penggaris vertikal visual (berguna saat membatasi panjang baris maksimum tanpa auto-format)
    • true-color = true: paksa dukungan true color
    • completion-replace = true: auto-complete menggantikan seluruh kata
    • trim-trailing-whitespace = true: hapus spasi di akhir baris
    • color-modes = true: bedakan tampilan mode dengan warna
    • rainbow-brackets = true: gunakan warna berbeda untuk kurung bertingkat (fitur terbaru, belum rilis resmi)
    • editor.file-picker.hidden = false: tampilkan berkas tersembunyi (dot files) di file picker
    • editor.indent-guides.render = true: tambahkan panduan indentasi visual
    • editor.inline-diagnostics.cursor-line = "warning": tingkatkan tampilan diagnostik (lihat tangkapan layar)
    • editor.auto-save.focus-lost = true: auto-save saat kehilangan fokus (memerlukan dukungan terminal)
    • editor.auto-save.after-delay.enable = true: auto-save setelah jeda waktu tertentu (disetel ke 300 detik)

Penyesuaian LSP

  • Untuk semua bahasa, harper-ls LSP ditambahkan agar kesalahan tata bahasa di dalam komentar dapat diberi penyorotan

Injeksi Tree-sitter kustom

  • Helix mengizinkan penentuan injeksi Tree-sitter kustom, sehingga bahasa lain bisa diberi highlight di dalam satu bahasa
  • Contoh penggunaan
    • Penyorotan sintaks kueri SQL di dalam Python dan Go
    • Penyorotan YAML front matter dan blok kode di Markdown
    • Bisa juga dimanfaatkan untuk menyorot snippet HTML
  • Berkas konfigurasi telah diunggah ke GitHub untuk membagikan injeksi kustom dan pengaturan
  • Helix adalah editor terminal generasi berikutnya dengan keunggulan minim plugin, keamanan, dan kustomisasi yang intuitif

Bacaan terkait

2 komentar

 
xguru 2025-10-14

Pengembang yang telah menggunakan Vim selama 20 tahun membagikan pengalamannya beralih dari Vim ke Helix
 
GN⁺ 2025-10-14
Opini Hacker News

  • Belakangan ini saya sedang membangun ulang konfigurasi editor. Sudah 20 tahun memakai Emacs dan 15 tahun memakai Vim secara berdampingan, dan saya tidak bisa memilih salah satunya saja. Tujuannya adalah melihat seberapa cepat saya bisa membuat setup yang cukup matang untuk langsung dipakai mengerjakan software Python tingkat enterprise. Kali ini saya terutama mencoba mengurangi ketergantungan pada ekstensi pihak ketiga semaksimal mungkin dan menyisakan hanya fitur yang benar-benar diperlukan. Saat ini saya menganggap setup Neovim saya adalah yang terbaik yang pernah saya pakai, tetapi ternyata saya memakai lebih banyak plugin daripada yang saya perkirakan. Untuk Emacs, saya masih di tahap awal, tetapi menarik melihat betapa jauhnya perkembangannya sehingga di versi 30 ke atas kebutuhan akan plugin pihak ketiga jauh berkurang. Dulu saya memakai lsp-mode, tetapi sekarang saya puas dengan Eglot. completion preview mode juga cukup bagus meski belum sepenuhnya menggantikan corfu. Daftar plugin Emacs yang wajib bagi saya adalah Magit, Expreg(teeesitter expand region), Multiple cursors, dape(debugging yang terintegrasi dengan Eglot). Mungkin saya juga akan menambahkan Consult dan orderless. Konfigurasi Neovim saya bisa dilihat di sini

    • nvim baru juga makin mengurangi kebutuhan akan plugin. Sudah ada plugin manager bawaan, diff viewer, dan lsp

    • Anda mengelola cukup banyak plugin nvim! Minggu lalu saya menulis ulang setup nvim saya dengan 4 plugin termasuk mini.nvim. Saya merasa kalau terlalu banyak menambahkan plugin, stabilitas dan keandalan nvim langsung turun drastis. Saya iri Anda hanya butuh 2 plugin di Emacs, dan itu memang terdengar akan berjalan jauh lebih stabil. Setup saya bisa dilihat di sini

    • Setelah memakainya beberapa bulan, saya penasaran apakah menurut Anda hasilnya bisa menyamai setup bawaan Pycharm+IdeaVIM. Tentu mengutak-atik konfigurasi sendiri itu menyenangkan, tetapi kalau fokusnya hanya pada efisiensi memakai IDE, bukankah menghabiskan banyak waktu untuk setup Neovim jadi agak tidak efisien?

    • Expreg(teeesitter expand region) mengingatkan saya pada combobulate(ini belum saya coba, tapi kelihatannya keren). Hanya saja Expreg terasa jauh lebih sederhana dan ringan

    • Saya benar-benar penasaran dengan cerita para pengguna Emacs lama. Saya ingin tahu bagaimana perbandingannya dengan Helix/Vim. Orang yang bilang Helix/Vim itu bagus biasanya terdengar seperti baru pertama kali memakainya, jadi terkesan belum tahu keunggulan nyata Emacs yang sudah lama dipakai. Memang benar key ala Vim dan mode-nya tampaknya lebih terintegrasi di editor modern, tetapi saat benar-benar dicoba, saya kurang punya kesabaran untuk bertahan sampai jari saya terbiasa. Saya ingin mendengar pengalaman pindah dari pengguna Emacs yang benar-benar hardcore

  • Saya termasuk yang berpindah dari Emacs → VS Code → Helix. Sampai sekarang saya berusaha semaksimal mungkin mempelajari keybinding bawaan dan memakainya secara efektif tanpa banyak menyentuh konfigurasi. Karena sulit menghafal semua yang bisa dilakukan Helix, saya membuat deskmat berisi tombol-tombolnya untuk ditaruh di meja saya. Mungkin baru akan tahu seberapa membantu setelah benar-benar dicetak dan dipakai. Deskmat saya bisa dilihat di sini

    • Saya penasaran, sudah berapa lama Anda memakai Emacs?

  • Selama 10 tahun terakhir saya memakai Emacs sebagai editor utama, dan sebelumnya saya memakai Sublime Text. Untuk edit file sederhana atau di server jarak jauh, saya kadang memakai Vim, tetapi saya tidak pernah merasa perlu sepenuhnya bergantung pada Vim saja. Di Emacs saya membuat modul dan fungsi sendiri sehingga lingkungannya pas sekali untuk saya. Bulan lalu saya mencoba Helix, dan ternyata memulainya sangat sederhana. Dasar-dasar penggunaannya—navigasi, pencarian, paste, berpindah buffer/jendela—juga cepat saya kuasai. Saya tidak begitu tahu sejarah Helix, tetapi desainnya sangat bagus. Pencarian globalnya sangat bagus, integrasi lsp-nya pas sekali, dan kecepatannya benar-benar tinggi. Rasanya sangat menyenangkan karena default-nya ditentukan secara konsisten dan berguna. Saya berencana terus memakainya agar makin terbiasa; editor default saya tetap Emacs, tetapi Helix begitu cepat sehingga untuk editing kode ia bisa saja menjadi editor utama saya

  • Saya sedang pertama kali mencoba Helix, dan ada dua kekurangan yang terasa besar

    • Modal editing adalah inti utamanya, tetapi dengan Vim saya bisa memakai muscle memory yang sudah ada di mana saja (mode Vim dipakai hampir di semua tempat, ada banyak ekstensi seperti Vimium, dan kalau di lingkungan ssh hampir pasti ada Vim)
    • Helix mengejar kesederhanaan sehingga tidak punya integrasi terminal, dan extensibility plugin-nya juga tidak terlalu tinggi (bahkan fitur lint pun hanya didukung berbasis lsp), dan kombinasi seperti ini berarti kita perlu membangun setup di atas editor itu sendiri, jadi tampak ada batasannya (perlu memanfaatkan tmux, dll.) Saya bukan hendak mencela kekurangannya, tetapi saya penasaran apa kelebihannya yang cukup kuat untuk menutupi hal-hal ini

    • Saya kurang paham kenapa LSP dianggap sebagai kekurangan. Karena LSP berjalan sebagai proses terpisah, justru menurut saya itu bagus untuk sandboxing plugin. Dalam praktiknya, malah bisa jadi bekerja lebih baik daripada plugin editor tradisional. Soal tidak adanya integrasi tmux juga tidak terlalu terasa bagi saya; meski saya terutama memakai Emacs, saya hampir tidak pernah memakai terminal internal. Kalau muscle memory-nya saja bisa dipindahkan, editor cepat yang dibuat dengan rust rasanya sudah cukup meyakinkan

    • Ada anggapan bahwa motion Vim bisa dipelajari sebagai muscle memory lalu dipakai di mana saja, tetapi kenyataannya hampir tidak ada developer yang ingin memakai lingkungan Vim dasar apa adanya tanpa plugin/konfigurasi. Kebanyakan ingin editor dengan setup dan fitur yang disesuaikan secara rinci untuk diri mereka sendiri. Pengecualiannya mungkin hanya orang yang benar-benar ssh ke banyak mesin dan perlu lingkungan editor bawaan. Anda juga menyebut kesederhanaan Helix dan keterbatasan plugin-nya, padahal awalnya Helix memang mengarah ke editor all-in-one, tetapi komunitas tidak menginginkannya sehingga sistem plugin sedang dikembangkan. Belum masuk rilis utama, tetapi di branch terpisah sudah ada berbagai plugin yang dibuat dan dipakai. Menurut saya menunda rilis sampai sistem plugin cukup stabil adalah keputusan yang benar. Kelebihan terbesar Helix adalah ia memperbaiki UX yang canggung yang masih tersisa di vi/vim/neovim. Artinya, urutan kerja diubah sehingga kita bisa lebih mudah melihat perubahan sebelum commit, sehingga mengurangi efek samping yang tidak disengaja

  • Dengan konfigurasi sebesar ini, rasanya lebih baik langsung pakai vim saja. Anda mencoba mereplikasi fitur vim di dalam Helix, dan Helix sendiri juga punya banyak dependensi internal(hanya saja tidak terlihat di permukaan seperti nvim). Setup vim8 saya sudah dijaga tetap sederhana selama lebih dari 8 tahun. Saya memakai vim8 karena itu versi yang tersedia di distro LTS. Hanya ada satu plugin yang dimuat otomatis(vim-tmux-navigator untuk berpindah mudah antara split vim dan split tmux), saya sudah meninjau kodenya dan tidak pernah meng-updatenya. Dua plugin "opsional" saya aktifkan saat perlu dengan :packadd! lewat package manager bawaan vim. Saya hanya memakai ale(lsp, diagnostik, auto-format saat simpan) dan vim-fugitive(integrasi git). ale tidak punya dependensi. vim-fugitive setelah dipasang tinggal dipakai saja. Alasan saya tidak memuat plugin otomatis adalah karena vim biasanya dipakai untuk edit cepat, dan saya hanya menyalakan git/lsp pada proyek jangka panjang. Plugin yang tidak perlu memang tidak perlu dipakai

    • Saya juga suka Neovim modern, jadi saya membuat paket python untuk menyelesaikan masalah ini(terutama cocok untuk orang yang sudah ada di ekosistem python atau memakai uv, pipx). Dengan uv tool install binwheels-neovim atau pipx install binwheels-neovim, Anda bisa memasang Neovim terbaru, dan langsung berjalan di Windows, mac, dan Linux. Paket ini membungkus rilis resmi Neovim lalu memakai uv atau pipx untuk mengambil biner yang sesuai dengan OS/arsitektur. Untuk Linux, karena dibutuhkan dukungan GLIBC yang lebih lama daripada rilis resmi, saya menyediakan build terpisah. Detail terkait bisa dilihat di PyPI, Github utama, log build

    • Dibandingkan nvim+plugin-plugin, Helix punya permukaan serangan supply chain yang sangat kecil. Helix dikelola sebagai satu kesatuan, jadi jauh lebih aman daripada nvim yang tiap plugin-nya punya vendor berbeda. Rilis Helix juga berjalan lambat dan hati-hati, sehingga dioperasikan dengan cara yang meminimalkan dampak besar bahkan jika ada kerentanan

    • Model editing Helix lebih unggul

  • Kalau Anda butuh TUI saat memakai Helix, saya penasaran kenapa harus memilih Helix daripada neovim. Saya suka default Helix, tetapi saat sampai pada titik perlu mengubah beberapa hal, rasanya jadi makin merepotkan. Dan kalau yang dicari adalah 'pengalaman IDE penuh' dengan Helix, saya juga kurang paham kenapa tidak sekalian memakai Zed, VSC, atau IDE JetBrains. Kalau saya butuh yang sederhana, saya pakai nvim; kalau butuh lebih banyak fitur, saya buka WebStorm, atau kalau rekan kerja perlu mencari sesuatu, saya pakai itu bersama mereka

    • Saat bekerja lewat ssh di perangkat berspesifikasi rendah, helix nyaris langsung terbuka. Untuk merakit fungsi yang sama di nvim, hasilnya jadi lebih lambat dan biaya perawatan konfigurasi/pembaruan plugin jadi besar. Selain itu saya tahu rust, jadi saya juga bisa ikut berkontribusi memperbaiki bug. Saya tidak paham bahasa keluarga C, jadi untuk proyek open source saya cenderung memilih yang ditulis dalam bahasa yang saya kuasai. Saya hanya coder hobi yang memakai n/vim selama 12 tahun lalu pindah ke helix dalam 2 tahun terakhir. Memang ada banyak hal dari nvim yang saya rindukan dan terasa lebih alami, tetapi helix benar-benar “langsung jalan”, dan kenyamanan itu mengalahkan segalanya

    • Dalam beberapa tahun terakhir saya sempat memakai neovim, helix, emacs, dan nano masing-masing cukup lama, dan pengalaman out-of-the-box helix sejauh ini yang paling unggul. Default-nya benar-benar sangat bagus, dan bantuan serta petunjuk kontekstualnya tampil dengan sangat baik, jadi saya tidak perlu mengingat perintah yang sering dipakai, dan yang jarang dipakai pun mudah dicari. Selain itu, di kepala saya urutan kerja perintah helix terasa lebih alami daripada vim. Editor modern seperti nvim/spacemacs punya hambatan plugin/konfigurasi yang terlalu tinggi. Berkat ekosistem plugin, helix memang bisa kalah dalam hal-hal yang sekarang belum bisa dilakukannya(misalnya emacs bisa dipakai seperti IDE untuk bahasa lisp apa pun, sedangkan helix tidak bisa memuat repl), tetapi sebagai gantinya kita harus mempelajari bukan hanya editor itu sendiri melainkan juga banyak plugin, dan hasil pencarian pun membingungkan karena jawabannya berbeda-beda tergantung versi/kombinasi. Saat membuat setup baru, pada akhirnya kita harus percaya rekomendasi orang lain atau menambah waktu untuk mencoba dan belajar sendiri. Helix adalah proyek yang lebih baru, jadi tidak menanggung beban keputusan lama dan bisa memilih keputusan serta default yang cocok dengan pola pengembangan modern. Tidak sempurna, tetapi untuk pemula TUI yang ingin sesuatu yang langsung bisa dipakai sekarang juga dan mudah dimulai tanpa konfigurasi, saya ingin merekomendasikan helix

    • hx cepat saat start maupun saat dipakai, dan bahkan terlihat bagus. Default-nya juga cukup memuaskan sehingga saya hanya mengubah sedikit, dan tidak seperti emacs/neovim yang dulu membuat saya terjebak dalam endless improvement loop, hx terasa punya titik akhir. TUI juga berjalan baik di server jarak jauh, jadi saya memakai lingkungan yang sama di mac, linux, dan server mana pun(walau editor lain juga bisa, hx juga mendukung ini dengan baik). Semua lsp yang saya butuhkan didukung dengan baik, dan konfigurasi languages.toml memang agak merepotkan, tetapi setup editor lain juga sama saja

    • Saya suka konfigurasi yang sederhana, dan selection-first editing model. Referensi terkait ada di sini. Setelah bicara dengan orang-orang yang kesulitan beradaptasi dengan Vim, saya menyadari bahwa sejak awal saya memang lebih cocok dengan model 'pilih dulu' seperti Helix. Saya sulit beradaptasi dengan operasi ala Vim di mana teks target tidak terlihat dulu(baru terlihat area yang terpengaruh setelah perintah dijalankan)

    • Memilih editor bukan keputusan yang sangat rasional; faktor psikologis seperti selera pribadi, rasa segar, atau kesenangan jauh lebih besar pengaruhnya

  • Baru tahu ada perintah :reset-diff-change. Selama ini saya hanya memakai checkout -p di git, tetapi melakukannya langsung di dalam Helix jauh lebih nyaman

  • Saya sudah mencoba memakai Helix dan berusaha keras beradaptasi sampai sekarang cukup mahir. Namun justru saya menyadari bahwa 'alur kerja terbalik' ini memang lebih mudah dipelajari dan diimplementasikan, tetapi saat dipakai malah lebih lambat. Jadi pada akhirnya saya kembali ke Vim, lalu ke Zed(mode Vim)

  • Hari ini saya pertama kali mencoba Helix, dan ini editor yang benar-benar dirancang dengan baik. Namun saya merasa kehilangan shortcut kerja cepat Vim seperti y2$, dw

    • Sebenarnya bukan tidak ada shortcut-nya, hanya saja y2$ ditulis sebagai 2xy, dan dw sebagai wd

  • Saya masih belum menemukan cara menghapus baris saat ini di Helix termasuk saat barisnya kosong. xd memang menghapus satu baris kalau barisnya tidak kosong, tetapi jika barisnya kosong, dua baris sekaligus ikut terhapus

    • x memilih baris saat ini, dan kalau sudah dalam keadaan terpilih maka akan diperluas ke baris berikutnya. X memperluas seleksi ke batas baris(selection line-wise). Pakai X

    • Untuk baris kosong, cukup pakai d

    • Ini memang diam-diam cukup mengganggu. Saya juga menjalankan fork sederhana yang mengubah perilaku x agar berbeda pada baris kosong. Detailnya bisa dilihat di PR ini