Windows Terminal’i Kullanma Biçimim – tmux ve Özel İş Akışlarıyla Kurduğum Üst Düzey Terminal Otomasyonu

• tmux, SSH, nvim ve güçlü arama/otomasyon betiklerini birleştirerek, uzak sunucudaki dosyaları GUI olmadan anında gezinip düzenleyip arayabildiği benzersiz bir iş akışı kuruyor
• Tek bir tuş kombinasyonuyla tmux’un birden fazla penceresinde dosya adlarını otomatik aratıp hemen açıyor, dosya geçişi ve buffer yönetimini de kısayollarla hallediyor
• VSCode’un yavaşlığı ve tuş ataması çakışmalarından rahatsız olduğu için tüm işlemleri betiklerle kendisi birleştiriyor
• regex, perl, tmux, nvim gibi Unix araçlarını bir araya getirerek dosya yolu ve satır bilgilerini otomatik tanıyıp açmayı sağlıyor
• Bunu bizzat kurma süreci oldukça karmaşık olsa da, terminalin gücünü ve genişletilebilirliğini en üst düzeye çıkarmanın mümkün olduğunu gösteriyor

---

Terminalimi kullanma biçimim

• Bu yazı, terminali ve çeşitli araçları birleştirerek verimli bir geliştirme ortamı kurma deneyimini paylaşıyor
• Süreç normalde video gerektirecek kadar karmaşık olduğu için metinle birlikte gerçek kullanım videosu da eklenmiş (videoyu izlemek önemli)
• Videodaki bazı anlar (0:11, 0:21, 0:41), birçok kişinin "bu gerçekten mümkün mü?" diye şaşırdığı kısımlar

Videodaki terminal iş akışının adım adım özeti

• 0:00 : Windows Terminal’i dizüstünde çalıştırma
• 0:02 : ctrl + shift + 5 kısayoluyla yeni bir terminal sekmesi açma, ssh ile evdeki masaüstüne bağlanma ve hemen tmux başlatma
• 0:03 : tmux içinde varsayılan kabuk zsh’i çalıştırma, prompt’u gösterme ve tüm yapılandırmayı asenkron yükleme
• 0:08 : zoxide ile yakın zamanda kullanılan dizinlerde fuzzy arama yapıp geçiş yapma
• 0:09 : ripgrep komutunu yazmaya başlama, zsh’in önceki kullanım geçmişine göre otomatik tamamlama yapması ve ctrl + f ile bunu kabul etme
• 0:11 : ctrl + kf kısayoluyla tmux scrollback’inin tamamında dosya adı arama, dosya adlarının mavi renkle vurgulanması
• 0:12 : n tuşuna art arda basarak arama sonuçlarındaki dosya listesinde istenen dosyayı gezme
• 0:21 : o tuşuyla seçili dosyayı varsayılan uygulamada (nvim) açma, tmux’un bunu yeni bir pencerede çalıştırması (hâlâ uzak sunucuda çalışıyor)
• 0:26 : rust-analyzer ile koddaki çeşitli referanslara gitmeyi deneme; bazı makroları tanıyamasa da 0:32’de başarıyla geçiş yapma
• 0:38 : ctrl + kh ile tmux odağını soldaki pencereye geçirme
• 0:39 : n tuşuna tekrar basarak "copy-mode" durumunda önceki dosya arama sonuçlarını gezmeye devam etme
• 0:41 : o tuşuyla bu kez başka bir dosyayı mevcut nvim örneğinde açma
• 0:43 : b tuşuyla açık dosya buffer’larının listesini görme ve iki dosya arasında geçiş yaparak bitirme

Neden böyle bir terminal iş akışı kullanmaya başladı?

• VSCode yavaştı; özellikle vim eklentisiyle çok fazla takılıyordu
  • Editör, vim eklentisi, terminal ve pencere yönetimi özellikleri arasında tuş ataması çakışmaları sık sık yaşanıyordu
  • Zed editörünü de denemiş ama o dönemde henüz olgunlaşmamıştı ve tuş ataması çakışması sorunu da sürüyordu
• nvim’i (Neovim) doğrudan terminalde kullanmaya başladıktan sonra ise,
  • ripgrep gibi araçlarla bulunan dosya adlarını tek tek kopyalayıp editöre yapıştırma süreci fazla zahmetli gelmiş
  • Özellikle ripgrep çıktısında dosya adıyla birlikte satır numarası da geldiğinde,
    • her yapıştırmada sözdizimi hatası oluşuyor
    • gerçek dosyayı açmadan önce gereksiz düzenlemeler yapmak gerekiyor
  • VSCode’daki ctrl-click gibi dosya yolunu doğrudan açabilen bir iş akışına ihtiyaç duyduğunu hissetmiş
• Bu yüzden tmux kullanarak istediği işlevleri kendisi kurmuş
  • İnsanlar neden tmux kullandığını sorduğunda, bunu doğrudan bu otomasyon ve oturum kalıcılığı ile açıklıyor
  • Terminal sanıldığından çok daha güçlü, ancak bu tür otomasyonlar varsayılan özelliklerle pek görünür olmuyor
  • tmux eski, sözdizimi karmaşık ve yer yer hatalı olsa da, genişletilebilirliği ve özelleştirme imkânı nedeniyle bunu seçmiş

Başlıca uygulama yöntemleri

tmux içinde tüm scrollback boyunca dosya adı arama

• tmux copy-mode içinde karmaşık düzenli ifadelerle dosya adı desen eşleştirme
• Kendi yazdığı regex betiği (search-regex.sh) ile dosya yolu, satır ve sütun bilgisine kadar vurgulama
• Örnek tmux yapılandırması:

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

Seçili dosyayı yeni pencerede/mevcut pencerede açma

• tmux kısayollarıyla seçili dosyayı varsayılan uygulamada veya editörde (nvim vb.) açacak şekilde özelleştirme
• Göreli yol desteği ve tilde genişletmesi dâhil

  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 ...'  
  

Dosyayı zaten açık olan nvim örneğinde açma

• perl betiğiyle tmux’un belirli bir nvim panelini bulup o panele dosya/satır bilgisini doğrudan tuş girdisi olarak göndermesi
• file:line:column biçimini vim komutuna dönüştürerek otomatik açma

Bu yaklaşımın artıları ve sınırları

• Yerel terminalin işlev sınırlarını aşma: tmux üzerinden uzak sunucudaki dosyaları serbestçe gezinme/düzenleme/arama
• Editör uzak düzenleme protokolünü desteklemese bile aynı iş akışını kullanabilme
• Tüm tuş atamalarını, aramayı, dosya geçişini ve buffer yönetimini tamamen kendi tercihlerine göre birleştirme
• VSCode eklentisi yazmaktan daha hızlı ve kolay otomasyon kurabilme
• Kendi yazdığı betikler kolay bozulabilir ve bakımı zor olduğu için başkalarına önermesi güç

Alternatif çözümler

• Genel olarak önerdiği açık kaynak/araç kombinasyonları:
  • fish + zoxide + fzf: fuzzy dizin, komut arama ve bazı dosya arama iş akışlarının yerini alabilir
  • Editörün yerleşik özellikleri (sekmeler, pencereler, fuzzy finder vb.) çoğu kullanıcı için zaten yeterli
  • qf: terminal çıktısından dosya seçebiliyor, ancak etkileşimli araçlarla entegre olamıyor; vi benzeri bir CLI kullanıyor
  • e: file:line yollarını tanıyan küçük bir araç (editör türüne göre ayrı betik gerekiyor)
  • vim --remote, code filename, emacsclient gibi araçlar da benzer etki yaratıyor, ancak file:line tanıma desteği eksik kalabiliyor

Sonuç ve çıkarımlar

• Terminal sanılandan çok daha güçlü; doğru betiklerle birleştirildiğinde GUI araçlarında mümkün olmayan otomasyonlar kurulabiliyor
• Ancak bakım kolaylığı ve betiklerde gömülü hata riski gibi pratik sınırlamalar var
• Terminal iş akışı otomasyonuyla ilgileniyorsanız, özel tmux/nvim/fzf ortamını adım adım kurarak başlamak en gerçekçi yaklaşım

[GN⁺]

Hacker News yorumu

• Ben de benzer bir numara kullanıyorum. tmux scrollback'ten yararlanıp tokenize edilmiş çıktıyı zsh'e pipe ediyorum; böylece tmux ekranında görünen her şey için otomatik tamamlama kullanabiliyorum. İlgili Threads gönderisi ve gist kodu burada. Gerçekten çok faydalı oldu

• Bu tür workflow yaklaşımını gerçekten seviyorum; ben de yıllardır benzer bir şeyi tekrar tekrar kurup inceltiyorum. Zaman geçtikçe özel katmanları olabildiğince azaltmaya çalışıyorum, çünkü overlay sayısı arttıkça bakım maliyeti de büyüyor. Yazıda anlatılanların çoğu saf Vim ile de yapılabiliyor (ayrı bir tmux olmadan); örneğin rg --vimgrep restore_tool | vim -c cb - ile (vim -c cb - Vim'deki en sevdiğim özelliklerden biri; neredeyse kimsenin kullanmaması şaşırtıcı). Tabii her seferinde rg aramasını yeniden çalıştırmak pahalı olabilir; ben de sonuçları terminalde inceliyorum, gerekirse tmux için özel bir komutla son komutun çıktısını kopyalayıp vim'e gönderiyorum. Bazen prompt'ta Unicode karakterleri kullanma numarasını kullanıyorum, bazen de tmux saveb - | vim -c cb - ile aktarıyorum

  • 10 yıl önce devasa çok dosyalı, çok paketli vim ayarımı çöpe attım; şimdi her yıl yalnızca 1-2 satır kadar ekleyerek çok basit bir vimrc ile giderek daha sadeleşiyorum. Eski yazılımların varsayılan ayarlarının genelde bir nedeni vardır; onları rastgele değiştirmeden önce o nedeni anlamayı tavsiye ederim
  • (vim -c cb -'nin Vim'de en sevdiğin özellik olduğunu söylemişsin; bunun ne yaptığını açıklayabilir misin diye merak ettim. ls | vim - ile ls | vim -c cb - komutlarını denedim ama aradaki farkı hemen anlayamadım)
  • Bunun vim -q <(ripgrep --vimgrep restore_tool) ile aynı amaca hizmet edip etmediğini merak ediyorum

• Bu kurulum; tmux, fzf, rg, zoxide ve temiz bir nvim içerdiği için güzel görünüyor. Eğer yoksa atuin, starship, bat, glow, duf, dogdns, viddy, gum/sesh, dust, btop gibi araçları da tavsiye ederim. Hepsini GitHub'daki Awesome Terminal XYZ listelerinde bulabilirsiniz. atuin gerçekten olmazsa olmaz seviyesinde; zoxide yoksa, sporcusun ama ayakkabın ayağına uymuyormuş gibi hissettiriyor. Terminal videosu çekecekseniz asciinema daha iyi bir tercih. Aslında eskiden bu tür kurulumlara "programcı" denirdi. Bugünlerde ise VSCode, Zed, Cursor gibi araçlar da şart ve hangi LLM'e neyi yaptıracağını da biliyor olman gerekiyor. Bunlar artık yeni “asgari seviye”, ama mevcut ortamın yerini almıyor. Claude Code'u, gptel'i ne kadar iyi kullanırsanız kullanın bazen ağaç yapısını yine bozabilirsiniz; magit olmadan git kullanmayı ise hayal bile edemem. Eğer biri saf Cursor'la OP'den daha hızlı olduğunu düşünüyorsa, o kişinin LLM'i gerçek işte kullanırken bir video çekmesini isterim

  • Programcı olmak geliştirme ortamı kurmaktan ibaret değil. Bazı ünlü programcılar ex editörünü severek kullanır, bazı acemiler ise parlatılmış bir IDE'ye rağmen temel anlayıştan yoksundur. Elbette iyi araçlar yardımcı olabilir, ama gerçek başarı üzerindeki etkileri genelde küçüktü. Belki LLM'ler bunu değiştirir. Örneğin koşu ayakkabın tam uymadığı için %5 yavaş olsan bile, startup'ta başarıyla başarısızlığı ayıran şeyler genelde böyle küçük farklar değildir. Sorun çoğu zaman kurucu ortak kavgası, motivasyon kaybı ya da ürün-pazar uyumsuzluğu gibi daha büyük şeylerdir
  • Araç listen güzel, ama atuin, dogdns, btop gibi isimlerin çoğunu bilmeyen biri için biraz yabancı görünebilir
  • Komut listesini gerçekten sevdim. Ben buna mutlaka fd'yi de eklerdim (yazarı: sharkdp). find'ın yerine geçen bir araç ve kullanılabilirlik açısından harika. Ayrıca atuin da benim CLI hayatımdaki en büyük yükseltme oldu. 6 ay önce yazdığım nadir bir komutu bile çok kolay bulmamı sağlıyor
  • Araç seçimine biraz fazla takıntılı gibisin. Gerçekten iyi geliştiriciler çıplak bir ortamda bile hızlıca sonuç üretir. Elbette iyi araçlar küçük bir fark yaratabilir, ama çoğu zaman bu daha çok kişisel zevk ve eğlence meselesi. Üretkenliğinin IDE'ye ne kadar bağlı olduğunu gerçekten hissediyorsan, demek ki önünde hâlâ uzun bir öğrenme ve gelişme yolu var. Eskiden de “araçları bilmek = programcı olmak” diye bir denklem yoktu. Gördüğüm en iyi geliştiricilerin çoğu, more/grep/vi üzerine biraz düşünce ekleyerek ezici sonuçlar üretiyordu. Değer üretimi nihayetinde düşünceden gelir. LLM çağında bile bu değişmiş değil

• Bütün vim/tmux kullanıcıları büyük ihtimalle yarı hatalı ama hızlı çalışan, gayriresmî bir “taklit Emacs”ı kendi elleriyle yapmıştır

  • Ben, iki tuşlu tmux prefix'ini tüm komutlar için tek bir ctrl-modified tuşa çeviren bir terminal emülatörü bile yaptım. Proje bağlantısı
  • Benim gibi hem vim/tmux hem de emacs kullanan biri olarak (ve geçmişte uzun süre sadece emacs kullanmış biri olarak), emacs ortamım çok daha doğaçlama, daha az belgelenmiş ve daha hatalıydı. vim+tmux kurulumu ise buna kıyasla daha istikrarlı
  • Bu söze derinden katılıyorum. Ben şu anda workflow'mda nvim içinde :Term çalıştırıyorum
  • vim+tmux ortamı pipe, dosya, sinyal, scrollback gibi sistem primitiflerine çok dayanıyor. Bu yüzden çeşitli araç zincirlerinin olduğu ortamlarda, ssh üzerinde ya da kısıtlı shell'lerde doğal ve şeffaf biçimde çalışıyor. Bu da taşınabilirlik ve hata ayıklama açısından büyük avantaj. Yani workflow'mun böyle temel güvenceler üzerinde özgürce parçalanabilmesi, kendi vim ayarlarımı yazmayı son derece doğal bir seçim gibi hissettiriyor

• Windows'ta tmux kullandığını söylüyor ama bunu pratikte nasıl yaptığını merak ediyorum. Açıklayabilecek biri olsa iyi olurdu

  • Bence Unix sistemlere uzaktan bağlanıp asıl işi orada yapıyor. Unix sunucuda tmux'u kusursuz biçimde çalıştırabilirsiniz. Ben de bazen WSL yerine daha temiz bir uyumluluk katmanı olarak VirtualBox VM'e SSH ile bağlanıyorum. Bu açıdan tmux'un diğer yöntemlere göre güçlü olmasının nedenlerinden biri de bu. Sunucuda kurulu olduğu sürece uzaktan da tüm işlevini yerine getiriyor. İlgili açıklama bağlantısı

• Bu tür workflow paylaşımlarını gerçekten seviyorum. Hedef kitleye tam uyuyor. Videoda ses olmasını isterdim ama sonradan aksiyon listesini okumak da iyiydi. Kendi workflow'm için de işe yarar bir şeyler öğrendim. tmux'un anlaşılması zor klavye kısayollarından bahsetmişsin; burada byobu kullanan var mı? byobu, tmux için bir wrapper ve komutların çoğunu F# tuşlarına atıyor. Onunla ilk kez 10 yıl önce tanıştım ve o zamandan beri kullanıyorum. Ondan önce birkaç yıl saf tmux kullanmıştım

  • İçeriği keyifle izlemiş olmana sevindim :) Mümkün olduğunca net ve tek bakışta anlaşılır yapmaya çalıştım. tmux kısayollarımın çoğunu yeniden eşledim. ctrl-k benim prefix'im ve h, varsayılan "sol paneli seç" tuşu değil. byobu'yu hiç denemedim ama anlattıklarından, varsayılan kısayolları biraz daha rahat hale getirmekten öteye geçmiyor gibi; bu yüzden üstüne fazladan bir katman eklemeyi çok istemem

• Böyle şeyleri dev bir regex olmadan da tmux eklentileriyle, örneğin kopyalama modu özelliklerini genişleterek yapabilirsiniz. tmux-fpp, tmux-copycat, tmux-fingers, tmux-urlview gibi seçenekler var. Hız açısından yerleşik işlevlere olabildiğince yaslanmak avantajlı olabilir; aklınızda bulunsun. Ben özellikle tmux-resurrect (oturum kaydetme/geri yükleme), tmux-continuum (otomasyon özellikleri) ve Oh-My-Fish için tmux-zen'i de çok seviyorum. tmux-resurrect, tmux-continuum, tmux-zen burada. Harika bir tmux ortamı kurmanın sanıldığından çok daha kolay olduğunu özellikle vurgulamak isterim

  • Ben de orijinal regex'i tmux-copycat'ten almıştım. Ama a) o regex : karakterini iyi yakalamıyor, b) copycat kendi görüntüleyici soyutlamasını kullandığı için bir aramada yalnızca tek bir eylem yapılabiliyor. Benim yöntemim tmux'un yerleşik aramasını yeniden kullanıyor; böylece vurgulanan dosyalara istediğim eylemi serbestçe bağlayabiliyorum. Çoğu eklentinin sadece kopyala/yapıştır desteklemesinin ya da kendi modunu oluşturmasının sebebi de bu; çünkü tmux, vurgu kontrolünü neredeyse sadece yerleşik arama üzerinden sunuyor

• Bu tür bir kurulum gerçekten çok güzel. Ama terminale hâlâ düzgün bir yapay zeka typeahead gelmemiş olması gizem gibi. Cursor tab bunun için biçilmiş kaftan olurdu ama terminale uygulanması engellenmiş durumda. Geçici çözüm olarak terminal çıktısını sahte dosyalara pipe edip Cursor'a gönderen bir ürün hızlıca yapma isteği geliyor insanın içine

• Makalenin başlığı aslında "How I use my terminal"

  • HN'nin otomatik özelliği, başlığın ilk kelimesi How ise onu kesip atıyor. Bunun için ortaya konmuş gerçek bir gerekçe yok; yönetici buna clickbait önleme diyor ama pratikte sadece kafa karıştırıyor
  • İlk başta bunun "There Will Be Blood" filminin bir parodisi olduğunu sandım (şu anki başlık "I use my terminal" olduğu için)
  • Ben de bunun birinin kendi yaptığı terminal emülatörünü nasıl kullandığına dair bir yazı olduğunu sanmıştım
  • Ben de bunu yeni öğrendim. Yazıyı tarayınca tam başlığın "I use my terminal (and so should you)" gibi bir şey olduğunu düşündüm. Terminal yazıları her zaman ilgimi çeker; Chromebook kullanıcısı olarak bana tarayıcı ve terminal yetiyor. Mac'e geçince ortam fazla dağınık geliyor, bu yüzden günlük kullanımda ya terminal ya da tarayıcı kullanıyorum
  • HN'de başlık gönderirken yaygın ön ekler ve son ekler genelde otomatik olarak kırpılıyor