Cara Saya Menggunakan Windows Terminal – Otomatisasi Terminal Tingkat Tinggi dengan tmux dan Workflow Kustom

• Menggabungkan tmux, SSH, nvim, serta skrip pencarian dan otomatisasi yang kuat untuk mewujudkan workflow unik yang memungkinkan penelusuran, pengeditan, dan pencarian file di server jarak jauh secara instan tanpa GUI
• Dengan satu kombinasi tombol, pencarian nama file otomatis di beberapa jendela tmux dan langsung membukanya, termasuk perpindahan file dan manajemen buffer, semuanya ditangani lewat shortcut
• Karena tidak puas dengan kelambatan VSCode dan konflik key binding, penulis menyatukan semua operasi sendiri lewat skrip
• Dengan menggabungkan alat Unix seperti regex, perl, tmux, nvim, dan lainnya, penulis mewujudkan pengenalan otomatis jalur file dan informasi baris, lalu membukanya secara langsung
• Proses implementasinya sendiri sangat rumit, tetapi menunjukkan bahwa kekuatan dan ekstensibilitas terminal bisa dimaksimalkan

---

Cara Saya Sendiri Menggunakan Terminal

• Tulisan ini membagikan pengalaman membangun lingkungan pengembangan yang efisien dengan menggabungkan terminal dan berbagai alat
• Karena prosesnya cukup rumit dan biasanya perlu video, penulis menyertakan video demonstrasi nyata bersama teks (menonton videonya sangat disarankan)
• Beberapa tahap dalam video (0:11, 0:21, 0:41) adalah bagian yang membuat banyak orang terkejut dan bertanya, "Memangnya ini bisa?"

Ringkasan Tahap demi Tahap Workflow Terminal di Video

• 0:00 : Menjalankan Windows Terminal di laptop
• 0:02 : Membuka tab terminal baru dengan shortcut ctrl + shift + 5, lalu terhubung ke desktop di rumah lewat ssh, dan langsung menjalankan tmux
• 0:03 : Menjalankan shell bawaan zsh di tmux, menampilkan prompt dan memuat seluruh konfigurasi secara asinkron
• 0:08 : Berpindah direktori setelah melakukan pencarian fuzzy direktori terbaru dengan zoxide
• 0:09 : Mulai mengetik perintah ripgrep, lalu zsh melakukan autocomplete berdasarkan riwayat penggunaan sebelumnya, dan menerimanya dengan ctrl + f
• 0:11 : Dengan shortcut ctrl + kf, melakukan pencarian nama file di seluruh scrollback tmux, dan nama file disorot dengan warna biru
• 0:12 : Menekan tombol n terus-menerus untuk menelusuri file yang diinginkan dari daftar file hasil pencarian
• 0:21 : Dengan tombol o, membuka file yang dipilih di aplikasi bawaan (nvim), lalu tmux berjalan di jendela baru (tetap berjalan di server jarak jauh)
• 0:26 : Mencoba berpindah ke beberapa referensi dalam kode dengan rust-analyzer; sebagian macro gagal dikenali, tetapi pada 0:32 perpindahan berhasil dilakukan
• 0:38 : Dengan ctrl + kh, memindahkan fokus tmux ke jendela kiri
• 0:39 : Menekan tombol n lagi untuk terus menelusuri hasil pencarian file sebelumnya dalam status "copy-mode"
• 0:41 : Dengan tombol o, kali ini membuka file lain di instance nvim yang sudah ada
• 0:43 : Dengan tombol b, melihat daftar buffer file yang sedang terbuka, lalu menutup dengan berganti-ganti antara dua file tersebut

Mengapa Menggunakan Workflow Terminal Seperti Ini?

• VSCode terasa lambat, terutama saat memakai plugin vim, sangat tersendat-sendat
  • Sering terjadi konflik key binding antara editor, plugin vim, terminal, dan fitur manajemen jendela, sehingga tidak nyaman
  • Penulis juga sempat mencoba editor Zed, tetapi saat itu masih belum matang dan masalah konflik key binding tetap ada
• Penulis lalu mulai menggunakan nvim (Neovim) langsung di terminal, tetapi
  • Proses menyalin nama file satu per satu dari hasil pencarian seperti ripgrep lalu menempelkannya ke editor terasa terlalu merepotkan
  • Terutama jika hasil ripgrep menampilkan nama file beserta nomor baris, maka
    • setiap kali ditempel akan memicu kesalahan sintaks
    • sering kali perlu mengedit secara tidak perlu sebelum file benar-benar dibuka
  • Penulis merasa perlu workflow yang bisa langsung membuka path file, seperti ctrl-click di VSCode
• Karena itu, penulis menggunakan tmux untuk mewujudkan sendiri fitur yang diinginkan
  • Saat orang bertanya mengapa memakai tmux, penulis menjelaskan bahwa alasannya justru otomatisasi ini dan kemampuan mempertahankan sesi
  • Terminal sebenarnya jauh lebih kuat dari yang dibayangkan, tetapi kemampuan otomatisasi seperti ini tidak tampak jika hanya memakai fitur dasarnya
  • Walaupun tmux sudah tua, sintaksnya rumit, dan ada bug, penulis tetap memilihnya karena ekstensibilitas dan kemungkinan kustomisasinya

Metode Implementasi Utama

Pencarian Nama File di Seluruh Scrollback tmux

• Di copy-mode tmux, pola nama file dicocokkan dengan regular expression yang kompleks
• Dengan skrip regex buatan sendiri (search-regex.sh), jalur file, baris, hingga kolom bisa disorot
• Contoh konfigurasi tmux:

  bind-key f copy-mode \; send-keys -X search-backward '정규표현식'  
  

Membuka File yang Dipilih di Jendela Baru/Jendela Saat Ini

• Dengan shortcut tmux, file yang dipilih dibuka di aplikasi default atau editor (nvim dan lain-lain) secara kustom
• Mendukung path relatif dan ekspansi tilde

  bind-key -T copy-mode-vi o  send-keys -X copy-pipe 'cd #{pane_current_path}; ...'  
  bind-key -T copy-mode-vi O  send-keys -X copy-pipe-and-cancel 'tmux send-keys ...'  
  

Membuka File di Instance nvim yang Sudah Terbuka

• Dengan skrip perl, tmux mencari pane nvim tertentu lalu langsung mengirim input tombol ke pane tersebut, termasuk informasi file/baris
• Sintaks file:line:column diubah menjadi perintah vim agar file terbuka otomatis

Kelebihan dan Batasan Pendekatan Ini

• Mengatasi keterbatasan fitur terminal lokal: memungkinkan penelusuran, pengeditan, dan pencarian file di server jarak jauh dengan bebas melalui tmux
• Workflow yang sama tetap bisa dipakai meski editor tidak mendukung protokol pengeditan jarak jauh
• Semua key binding, pencarian, perpindahan file, manajemen buffer, dan sebagainya dapat diintegrasikan sepenuhnya sesuai preferensi pribadi
• Otomatisasi bisa dilakukan lebih cepat dan mudah dibanding membuat plugin VSCode
• Karena skrip buatan sendiri ini mudah rusak dan sulit dirawat, penulis merasa sulit merekomendasikannya kepada orang lain

Solusi Alternatif

• Kombinasi open source/alat yang secara umum direkomendasikan:
  • fish + zoxide + fzf: bisa menggantikan workflow direktori fuzzy, pencarian perintah, dan sebagian workflow pencarian file
  • Fitur bawaan editor (tab, window, fuzzy finder, dll.) juga sudah cukup untuk sebagian besar pengguna
  • qf: memungkinkan pemilihan file dari output terminal, tetapi tidak bisa terhubung dengan alat yang interaktif, dan memakai CLI bergaya vi
  • e: utilitas kecil yang mengenali path file:line (memerlukan skrip terpisah untuk tiap jenis editor)
  • vim --remote, code filename, emacsclient, dan lainnya juga memberi efek serupa, tetapi pengenalan file:line tidak sempurna

Kesimpulan dan Pelajaran

• Terminal jauh lebih kuat dari yang dibayangkan, dan jika dirangkai sendiri lewat skrip, ia bisa menghadirkan otomatisasi yang tidak mungkin dilakukan di alat GUI
• Namun, tetap ada batas praktis seperti kemudahan perawatan dan bug yang melekat pada skrip
• Jika tertarik pada otomatisasi workflow terminal, pendekatan yang realistis adalah membangun lingkungan tmux/nvim/fzf kustom secara bertahap

[GN⁺]

Komentar Hacker News

• Saya juga memakai trik yang mirip. Memanfaatkan scrollback tmux, lalu output yang sudah ditokenisasi dipipe ke zsh sehingga saya bisa memakai autocomplete untuk apa pun yang terlihat di layar tmux. Saya juga membagikan post Threads terkait dan kode gist. Sangat berguna buat saya

• Saya sangat suka gaya workflow seperti ini, jadi saya juga sudah bertahun-tahun mengulang dan menyempurnakan sesuatu yang mirip. Seiring waktu, saya berusaha mengurangi lapisan kustom seminimal mungkin, karena makin banyak overlay, makin besar juga biaya perawatannya. Di Vim bawaan pun (tanpa tmux terpisah) sebagian besar hal yang diperkenalkan di postingan itu bisa dilakukan, misalnya dengan rg --vimgrep restore_tool | vim -c cb - (vim -c cb - adalah fitur favorit saya di Vim, sampai-sampai heran kenapa hampir tidak ada yang memakainya). Tentu saja, menjalankan ulang pencarian rg setiap saat bisa terasa berat, jadi biasanya saya menganalisis hasilnya dulu di terminal lalu, jika perlu, memakai perintah kustom tmux untuk menyalin output perintah terakhir dan mengirimkannya ke vim. Untuk itu saya kadang memakai trik memanfaatkan karakter Unicode di prompt atau meneruskannya lewat tmux saveb - | vim -c cb -

  • Sepuluh tahun lalu saya membuang konfigurasi vim multi-file dan multi-package yang sangat besar, dan sekarang makin menyederhanakannya dengan hanya membuat vimrc yang sangat sederhana, mungkin bertambah 1–2 baris per tahun. Biasanya ada alasan kenapa software lama punya pengaturan bawaan seperti itu, jadi saya sarankan pahami dulu alasannya sebelum mengubahnya sembarangan
  • (Anda bilang vim -c cb - adalah fitur favorit Anda di Vim, jadi saya penasaran apakah Anda bisa menjelaskan itu sebenarnya melakukan apa. Saya sudah mencoba ls | vim - dan ls | vim -c cb -, tapi tidak langsung paham apa bedanya)
  • Saya penasaran apakah ini dipakai untuk tujuan yang sama seperti vim -q <(ripgrep --vimgrep restore_tool)

• Setup ini enak dilihat karena mencakup tmux, fzf, rg, zoxide, dan nvim yang rapi. Kalau belum ada, saya juga ingin merekomendasikan atuin, starship, bat, glow, duf, dogdns, viddy, gum/sesh, dust, btop, dan lain-lain. Semuanya bisa ditemukan di daftar Awesome Terminal XYZ di GitHub. atuin benar-benar nyaris wajib, dan tanpa zoxide rasanya seperti atlet yang memakai sepatu yang ukurannya tidak pas. Untuk merekam video terminal, asciinema adalah pilihan yang lebih baik. Dulu sebenarnya setup seperti ini cukup disebut sebagai "programmer". Sekarang tool seperti VSCode, Zed, Cursor, dan juga tahu tugas apa yang sebaiknya diberikan ke LLM tertentu, terasa seperti kebutuhan wajib juga. Tool-tool ini sekarang hanyalah “minimum” yang baru, bukan pengganti lingkungan lama. Sebaik apa pun Anda memakai Claude Code atau gptel, kadang tree tetap bisa rusak, dan memakai git tanpa magit itu nyaris tak terbayangkan. Kalau ada yang merasa Cursor polos lebih cepat daripada OP, suruh saja dia merekam video saat benar-benar memakai LLM dalam praktik langsung

  • Menjadi programmer bukan cuma soal setelan lingkungan pengembangan. Ada programmer terkenal yang senang memakai editor ex, dan ada pemula yang IDE-nya kelihatan keren tapi pemahaman dasarnya masih kurang. Tentu alat yang bagus bisa membantu, tetapi dampaknya terhadap keberhasilan nyata biasanya kecil. Mungkin LLM bisa mengubah ini. Misalnya, walau sepatu lari yang salah bikin Anda 5% lebih lambat, keberhasilan atau kegagalan startup biasanya tidak ditentukan hal sekecil itu. Penyebabnya hampir selalu masalah yang lebih besar seperti konflik antarko-founder, hilangnya motivasi, atau product-market fit yang buruk
  • Daftar tool Anda bagus, tapi bagi orang yang tidak mengenal sebagian besar nama seperti atuin, dogdns, atau btop, itu bisa terasa cukup asing
  • Saya suka sekali daftar perintah ini. Saya juga pasti akan menambahkan fd (pembuatnya: sharkdp). Ini pengganti find yang sangat bagus dari sisi kemudahan pakai. Dan atuin adalah peningkatan terbesar dalam hidup CLI saya. Perintah langka yang saya ketik enam bulan lalu pun bisa ditemukan dengan sangat mudah
  • Rasanya Anda terlalu terobsesi pada pilihan tool. Developer yang benar-benar bagus tetap bisa menghasilkan sesuatu dengan cepat bahkan di lingkungan yang sangat minim. Tentu tool yang baik bisa sedikit membantu, tapi sebagian besar ini cuma soal kesenangan dan selera pribadi. Kalau Anda benar-benar merasa produktivitas sangat bergantung pada IDE, itu berarti perjalanan belajar dan bertumbuh Anda masih panjang. Dari dulu tidak pernah ada rumus “tahu tool = programmer”. Developer terbaik yang pernah saya lihat kebanyakan menghasilkan hal luar biasa hanya dengan more/grep/vi ditambah banyak pemikiran. Penciptaan nilai pada akhirnya datang dari cara berpikir. Bahkan di era LLM pun tetap begitu

• Kemungkinan besar semua pengguna vim/tmux pada akhirnya telah membuat sendiri semacam “Emacs tiruan” tidak resmi yang setengah buggy tapi cepat

  • Saya bahkan membuat emulator terminal yang mengganti prefix dua tombol tmux menjadi satu tombol dengan modifier ctrl untuk semua perintah. Tautan proyek
  • Saya memakai keduanya, vim/tmux dan emacs (dan dulu lama sekali memakai emacs saja), dan lingkungan emacs saya jauh lebih spontan, kurang terdokumentasi, dan lebih penuh bug. Setup vim+tmux relatif lebih stabil
  • Saya sangat setuju dengan kalimat itu. Dalam workflow saya sekarang, saya menjalankan :Term di dalam nvim
  • Lingkungan vim+tmux sangat bergantung pada primitif sistem seperti pipe, file, signal, dan scrollback. Karena itu tooling-nya bekerja secara alami dan transparan di berbagai lingkungan, lewat ssh, atau di shell yang terbatas. Ini keunggulan besar dari sisi portabilitas dan debugging. Jadi rasanya workflow saya bebas terurai di atas jaminan dasar seperti itu, sehingga membuat konfigurasi vim sendiri terasa sebagai pilihan yang sangat wajar

• Dia bilang memakai tmux di Windows, jadi saya penasaran bagaimana tepatnya itu dipakai dalam praktik. Akan bagus kalau ada yang bisa menjelaskannya

  • Menurut saya dia tersambung jarak jauh ke sistem Unix dan melakukan pekerjaan sebenarnya di sana. tmux bisa dijalankan dengan sempurna di server Unix. Saya sendiri kadang SSH ke VM VirtualBox untuk memakai lapisan kompatibilitas yang lebih bersih daripada WSL. Ini juga salah satu alasan tmux lebih kuat dibanding pendekatan lain. Selama terpasang di server, dari jarak jauh pun tetap bisa menjalankan fungsinya sepenuhnya. Tautan penjelasan terkait

• Saya suka sekali cara berbagi workflow seperti ini. Sangat pas untuk audiens sasarannya. Saya berharap videonya ada suara, tapi membaca daftar aksinya belakangan juga tidak masalah. Ada beberapa hal yang bisa saya terapkan ke workflow saya sendiri, jadi saya belajar sesuatu. Dia sempat menyinggung shortcut keyboard tmux yang rumit; apakah ada yang pernah memakai byobu di sini? byobu adalah wrapper untuk tmux yang memetakan sebagian besar perintah ke tombol F#. Saya pertama kali mengenalnya 10 tahun lalu dan sejak itu terus memakainya. Sebelum itu saya memakai tmux murni selama beberapa tahun

  • Senang mendengar Anda menikmati kontennya :) Saya berusaha membuatnya sejelas mungkin dan mudah dipahami sekilas. Saya sudah memetakan ulang sebagian besar shortcut tmux saya. ctrl-k adalah prefix, dan h bukan default untuk "pilih panel kiri". Saya belum pernah memakai byobu, tapi dari deskripsinya sepertinya hanya membuat shortcut bawaan sedikit lebih nyaman, jadi saya tidak terlalu ingin menambahkan lapisan ekstra lagi

• Dengan cara seperti ini, tanpa regex raksasa pun Anda bisa memperluas fitur copy mode dan lain-lain lewat plugin tmux. Ada tmux-fpp, tmux-copycat, tmux-fingers, dan tmux-urlview. Mungkin berguna juga untuk lebih mengandalkan fitur bawaan karena bisa lebih unggul dari sisi kecepatan. Saya pribadi juga sangat suka tmux-resurrect (simpan/pulihkan sesi), tmux-continuum (fitur otomasi), dan tmux-zen untuk Oh-My-Fish. Saya perkenalkan tmux-resurrect, tmux-continuum, dan tmux-zen. Intinya, setup lingkungan tmux yang keren ternyata jauh lebih mudah daripada yang dibayangkan

  • Saya juga mengambil regex dasarnya dari tmux-copycat. Tapi a) regex itu kurang bagus menangkap :, dan b) karena copycat memakai abstraksi viewer sendiri, dalam satu pencarian Anda hanya bisa melakukan satu aksi. Metode saya mendaur ulang pencarian bawaan tmux sehingga saya bisa dengan bebas mengikat aksi apa pun ke file yang sedang di-highlight. Alasan kebanyakan plugin hanya mendukung copy/paste atau membuat mode khusus sendiri juga karena tmux pada dasarnya hampir hanya mengizinkan kontrol highlight lewat pencarian bawaannya

• Setup seperti ini benar-benar indah. Tapi tetap misterius kenapa belum ada AI typeahead terminal yang benar-benar bagus. Tab di Cursor rasanya sangat cocok, tapi entah kenapa penerapannya ke terminal terhambat. Saya bahkan tergoda untuk cepat-cepat membuat produk sementara yang mem-pipe output terminal ke file palsu lalu mengirimkannya ke Cursor

• Judul artikelnya sebenarnya adalah "How I use my terminal"

  • Fitur otomatis HN memotong kata pertama jika judulnya diawali How. Tidak ada dasar jelasnya; admin bilang itu untuk mencegah clickbait, tapi kenyataannya cuma bikin bingung
  • Awalnya saya kira tulisan ini semacam parodi film 'There Will Be Blood' (karena judulnya sekarang 'I use my terminal')
  • Saya juga sempat mengira ini tulisan tentang seseorang yang memakai emulator terminal buatan sendiri
  • Saya juga baru sadar itu. Setelah melihat sekilas artikelnya, sepertinya judul lengkapnya kira-kira "I use my terminal (and so should you )". Tulisan soal terminal selalu saya sambut baik, dan sebagai pengguna Chromebook, browser dan terminal saja sebenarnya sudah cukup. Begitu pindah ke Mac, semuanya terasa terlalu berlebihan, jadi biasanya saya hanya memakai terminal atau browser
  • Saat mendaftarkan judul di HN, prefiks atau sufiks yang umum memang sering dipotong otomatis