Uzak sunucu geliştirme editörü olarak Helix editörü nasıl kullanılır

 (rushter.com)
7 puan yazan GN⁺ 2025-10-14 | 2 yorum | WhatsApp'ta paylaş
  • Uzak sunucu geliştirme editörü olarak Helix’in seçilme nedeni, Vim/Neovim gibi onlarca eklenti kurmadan kullanılabilmesi ve tedarik zinciri saldırısı riskini azaltması
  • tmux entegrasyon ayarları ile Helix’te eksik kalan dosya gezgini ve Git TUI işlevleri tamamlanıyor; yazi dosya yöneticisi, lazygit vb. açılır pencerede çalıştırılabiliyor
  • Vim tarzı tuş atamaları taşınarak satır seçme, imleç hareketi, metin silme gibi işlemler Vim’e benzer çalışacak şekilde ayarlanıyor; ESC ile çoklu imleç sıfırlanacak şekilde değiştiriliyor
  • Durum çubuğuna (statusline) Git dalı, kodlama, konum gibi bilgiler eklenerek verimlilik artırılıyor
  • Tree-sitter injection kullanılarak Python/Go içindeki SQL sorguları, Markdown’daki kod blokları vb. için söz dizimi vurgusu uygulanıyor ve okunabilirlik iyileştiriliyor
  • LSP, otomatik kaydetme, renk modları gibi gelişmiş ayarlar kullanılarak çalışma verimliliği artırılıyor ve ayrıntılı özelleştirme yapılıyor

Helix’i seçme arka planı

  • Son dönemde tedarik zinciri saldırılarının artması ve eklenti bağımlılığı sorunları nedeniyle, uzak sunucu geliştirme editörü olarak Vim/Neovim yerine Helix benimsendi
  • Neovim’deki onlarca eklenti olmadan da yalnızca temel işlevlerle kullanılabilmesi başlıca avantaj
  • Helix’e geçildikten sonra, alışılmış Neovim deneyimini mümkün olduğunca yeniden oluşturmak için ayar özelleştirme çalışmaları yapıldı
  • Bunlar paylaşılırken amaç, diğer kullanıcıların zaman kazanmasını sağlamak

Tmux ayarları

  • Terminal çoklayıcısı olarak Tmux kullanılıyor; dosya yöneticisi ve Git TUI eksikliğini gidermek için özel tuş atamaları eklendi
  • Helix, dosya gezgininden dosya düzenlemeyi desteklemediği için, birçok dosya arasında hızlı geçişte rahatsızlık yaratıyordu
  • Tmux yapılandırma dosyasına şu bağlamalar eklendi
    • prefix - y: Yazi dosya yöneticisini açılır pencerede çalıştırır (ekranın %95’i boyutunda)
    • prefix - g: Lazygit’i açılır pencerede çalıştırır
    • prefix - e: Tmux çıktı geçmişini Helix editöründe açarak arama ve kopyalama işlemleri yapılmasını sağlar
  • Varsayılan prefix Ctrl + b, ancak kullanımda Ctrl + \\ olarak değiştirildi
  • Terminal çıktısı ile çalışırken faydalı; özellikle ClickHouse istemcisi çıktısını (CSV/JSON) Slack’e kopyalarken kullanılıyor
    • Dosyaya çıktı almak yerine doğrudan kopyalama mümkün olduğu için işlem adımları azalıyor
    • Fareyle de yapılabilir, ancak Tmux tampon kaydırması rahatsız olduğundan editörde işlemek daha verimli
  • Yazi ve Lazygit genellikle Helix editörünün üzerinde katman olarak gösteriliyor

Vim tuş atamalarını taşıma

  • Helix tuş atamalarına alışılmış olsa da, hâlâ bazı Vim bağlamaları taşınarak kullanılıyor
  • Select modu bağlamaları
    • 0: satır başına git
    • $: satır sonuna git
    • ^: boşluk olmayan ilk karaktere git
    • G: dosya sonuna git
    • D: satır sonuna kadar seçip sil ve normal moda geç
    • k/j: yukarı/aşağı satırın tamamını seç (Helix’in varsayılan davranışı kısmi seçim olduğu için rahatsız edici)
  • Normal mod bağlamaları
    • D: imlecin sağındaki tüm metni sil (Helix’te fazla tuş gerektiği için taşındı)
    • V: Select moduna geçip satırın tamamını seç
    • ESC: çoklu imleci sıfırla (Helix varsayılanı virgül, bu ise kullanışsız)
  • Helix’in görsel modda satır seçme biçimi beğenilmediği için Vim tarzına çevrildi
    • Yukarı/aşağı hareket ederken satırın tamamının seçilmesi sağlandı

Geliştirilmiş durum çubuğu

  • Varsayılan durum çubuğunda mevcut Git dalı gibi önemli bilgiler eksik
  • Durum çubuğu yapılandırması
    • Sol: mod, spinner, sürüm kontrolü, dosya adı, salt okunur göstergesi, değişiklik göstergesi
    • Orta: boş
    • Sağ: tanılar, çalışma alanı tanıları, konum, toplam satır sayısı, konum yüzdesi, dosya kodlaması, satır sonu biçimi, dosya türü, register, seçim sayısı
    • Ayırıcı: │ karakteri kullanılıyor
  • Çalışma durumunu tek bakışta görmeyi sağlıyor

Faydalı tuş atamaları

  • Özel tuş atamalarıyla çalışma verimliliği büyük ölçüde arttı; bunları keşfetmek zaman aldı
  • En faydalı özellikler: dosyayı yeniden yükleme, soft wrap aç/kapat, Git undo, Git blame, Git diff
  • Tüm özel bağlama listesi
    • space - e - w: geçerli tamponu dosyaya kaydet
    • space - e - c: geçerli tamponu kapat
    • space - e - x: diğer tüm tamponları kapat (onlarca tampon açıkken faydalı)
    • space - e - l: inlay type hint aç/kapat (yararlı ama sürekli görünürse fazla gürültü yapıyor)
    • + - f: geçerli dosyayı biçimlendir
    • + - w: boşluk karakteri gösterimi (belgedeki görünmez karakterleri kontrol etmek için)
    • + - W: boşluk karakteri gösterimini devre dışı bırak
    • space - f - .: dosya seçicide Git ignore dosyalarını göster/gizle
    • space - f - r: tüm dosyaları yeniden yükle (Helix otomatik yeniden yüklemeyi desteklemediği için çok yararlı; dış değişiklikler veya commit sonrası gutter güncellemesi için)
    • space - f - x: geçerli imleçteki Git değişikliğini geri al
    • space - f - w: geçerli satırın Git blame bilgisini göster
    • space - f - d: Git diff göster

Editör ayarları

  • 6 aylık kullanımın ardından, terminal sekmesi değiştiğinde otomatik kaydetme özelliği olduğu fark edildi
  • Helix’in bazı yeni özellikleri varsayılan olarak devre dışı geliyor; bu da mevcut kullanıcıların beklenmedik değişiklikler yaşamamasını amaçlıyor
  • Yeni özellikleri keşfetmek için her seçeneği tek tek kontrol etmek gerekiyor
  • Başlıca yapılandırma seçenekleri
    • line-number = "relative": göreli satır numarası göster
    • rulers = [120]: görsel dikey cetvel ayarı (otomatik biçimlendirme olmadan azami satır uzunluğu sınırı koyarken yararlı)
    • true-color = true: true color’ı zorla etkinleştir
    • completion-replace = true: otomatik tamamlama kelimenin tamamını değiştirir
    • trim-trailing-whitespace = true: sondaki boşlukları temizle
    • color-modes = true: mod gösterimini renklerle ayır
    • rainbow-brackets = true: iç içe parantezlerde farklı renkler kullan (yeni özellik, henüz resmî sürümden önce)
    • editor.file-picker.hidden = false: dosya seçicide gizli dosyaları (dot files) göster
    • editor.indent-guides.render = true: görsel girinti kılavuzları ekle
    • editor.inline-diagnostics.cursor-line = "warning": tanı gösterimini iyileştir (ekran görüntüsüne bakın)
    • editor.auto-save.focus-lost = true: odak kaybolduğunda otomatik kaydet (terminal desteği gerekir)
    • editor.auto-save.after-delay.enable = true: belirtilen gecikme süresinden sonra otomatik kaydet (300 saniye olarak ayarlı)

LSP ayarlamaları

  • Tüm diller için harper-ls LSP eklendi; böylece yorumlardaki dil bilgisi hataları vurgulanıyor

Özel Tree-sitter injection

  • Helix, özel Tree-sitter injection tanımlamaya izin vererek bir dil içinde başka bir dili vurgulamayı mümkün kılıyor
  • Kullanım örnekleri
    • Python ve Go içindeki SQL sorgularına söz dizimi vurgusu
    • Markdown’daki YAML front matter ve kod bloklarını vurgulama
    • HTML snippet vurgulamada da kullanılabiliyor
  • Özel injection’ları ve ayarları paylaşmak için yapılandırma dosyaları GitHub’a yüklendi
  • Helix, eklenti minimizasyonu, güvenlik ve sezgisel özelleştirme avantajlarıyla öne çıkan yeni nesil bir terminal editörü

İlgili okumalar

2 yorum

 
xguru 2025-10-14

20 yıldır Vim kullanan bir geliştiricinin Vim’den Helix’e geçiş deneyimi
 
GN⁺ 2025-10-14
Hacker News yorumu

  • Son zamanlarda editör ayarlarımı yeniden kuruyorum. 20 yıldır Emacs, 15 yıldır da Vim kullanıyorum ve ikisinden birini seçemiyorum. Amacım, kurumsal düzeyde Python yazılımı üzerinde çalışmaya hemen uygun, olgun bir ayarı ne kadar hızlı kurabildiğimi görmek. Bu kez özellikle üçüncü taraf eklentilere bağımlılığı mümkün olduğunca azaltıp yalnızca gerekli özellikleri bırakmayı deniyorum. Şu anki Neovim ayarım, kullandıklarım arasında en iyisi bence ama beklediğimden daha fazla eklenti kullanmış oldum. Emacs tarafı hâlâ erken aşamada, ama 30 ve üstü sürümlerde üçüncü taraf eklenti ihtiyacını ciddi biçimde azaltacak kadar çok gelişmiş olması ilginç. Eskiden lsp-mode kullanıyordum ama artık Eglot’tan memnunum. Completion preview mode da corfu’nun yerini tamamen tutmasa da gayet iyi seviyede. Emacs için vazgeçilmez eklenti listem Magit, Expreg(treesitter expand region), Multiple cursors, dape(Eglot ile entegre hata ayıklama). Muhtemelen Consult ve orderless’ı da ekleyeceğim. Neovim ayarımı burada görebilirsiniz

    • Yeni nvim de eklenti ihtiyacını giderek azaltıyor. Yerleşik eklenti yöneticisi, diff görüntüleyici ve lsp’nin hepsi var

    • Oldukça fazla nvim eklentisi yönetiyorsun! Ben geçen hafta nvim ayarımı mini.nvim dahil 4 eklentiyle yeniden yazdım. Çok fazla eklenti ekleyince nvim’in kararlılığı ve güvenilirliği ciddi biçimde düşüyor gibi geldi. Emacs’te yalnızca 2 tane yetmesi kıskandırıcı, üstelik muhtemelen çok daha stabil çalışıyordur. Benim ayarım burada

    • Birkaç ay kullandıktan sonra bile bunun, Pycharm+IdeaVIM’in kutudan çıktığı haliyle sunduğu deneyime yakın olduğunu düşünüyor musun, merak ediyorum. Elbette ayarlarla uğraşmanın kendi içinde bir eğlencesi var, ama yalnızca IDE’yi verimli kullanma amacına odaklanırsak Neovim ayarına bu kadar zaman harcamak biraz verimsiz değil mi?

    • Expreg(treesitter expand region), bana combobulate’i hatırlatıyor (henüz denemedim ama havalı görünüyor). Yine de Expreg çok daha basit ve hafif hissettiriyor

    • Uzun yıllardır Emacs kullananların görüşlerini gerçekten merak ediyorum. Helix/Vim ile kıyaslayınca nasıl geliyor, bilmek isterim. Helix/Vim’i ilk kez kullananlar genelde iyi diyor ama sanki Emacs’i uzun süre kullanmanın asıl değerini bilmeden konuşuyorlar gibi. Aslında Vim tarzı tuşlar ve modlar modern editörlerde daha iyi entegre oluyor gibi, ama ben denediğimde ellerim alışana kadar dayanacak sabrım yetmedi. Gerçekten hardcore bir Emacs kullanıcısının geçiş deneyimini duymak isterim

  • Ben Emacs → VS Code → Helix sırasıyla geçtim. Şimdiye kadar mümkün olduğunca varsayılan tuş atamalarını öğrenip ayarları neredeyse hiç kurcalamadan verimli kullanmaya çalıştım. Helix’in yapabildiği her şeyi ezberlemek zor olduğu için, tuşları bastırıp masamda tutacağım bir deskmat bile yaptım. Gerçekten bastırıp kullandığımda ne kadar yardımcı olduğunu göreceğim. Masa matımı burada görebilirsiniz

    • Emacs’i ne kadar süre kullandığını merak ettim

  • Son 10 yıldır Emacs’i ana editörüm olarak kullanıyorum, ondan önce ise Sublime Text kullanıyordum. Basit dosya düzenlemeleri ya da uzak sunucularda ara sıra Vim kullanıyorum ama tamamen Vim’e geçme ihtiyacı hiç hissetmedim. Emacs’te kendime özel modüller ve fonksiyonlar yazarak tam bana uyan bir ortam kurmuştum. Geçen ay Helix’i denedim ve başlaması şaşırtıcı derecede basitti. Temel kullanımına—gezinti, arama, yapıştırma, buffer/pencere geçişi—de hızlıca alıştım. Helix’in geçmişini çok bilmiyorum ama tasarımı gerçekten çok başarılı. Özellikle global arama çok iyi, lsp entegrasyonu tam yerinde çalışıyor ve gerçekten çok hızlı. Varsayılanların tutarlı ve işe yarar biçimde seçilmiş olması çok ferah hissettiriyor. Daha da alışmak için kullanmaya devam etmeyi planlıyorum; varsayılan editörüm hâlâ Emacs ama Helix o kadar hızlı ki kod düzenleme için ana editörüm olabilir

  • Helix’i ilk kez kullanıyorum ve iki büyük dezavantaj hissediyorum

    • Modal düzenleme ana özelliği ama Vim’de mevcut muscle memory’ni her yerde aynen kullanabiliyorsun (Vim modu neredeyse her yerde var, Vimium gibi uzantılar da çok, ssh ortamındaysan da neredeyse her zaman Vim bulunur)
    • Helix sadeliği hedeflediği için terminal entegrasyonu yok ve eklenti genişletilebilirliği de yüksek değil (lint özelliği de yalnızca lsp tabanlı), bu kombinasyon da editörün üstüne ayrı bir kurulum yapman gerektiği anlamına geliyor ve bana sınırlayıcı geliyor (tmux gibi araçlar gerekiyor) Bunları kötülemek için söylemiyorum; sadece bu eksileri dengeleyecek kadar büyük artıları ne, merak ediyorum

    • LSP’nin neden dezavantaj sayıldığını pek anlamıyorum. LSP ayrı bir süreçte çalışıyor gibi ve bence bu, eklentileri sandbox’lamak açısından avantaj. Hatta pratikte geleneksel editör eklentilerinden daha iyi bile olabilir. tmux entegrasyonunun olmaması da bana çok dokunmuyor; ana editörüm Emacs olmasına rağmen dahili terminali neredeyse hiç kullanmıyorum. Muscle memory’yi taşıyabiliyorsam, Rust ile yazılmış hızlı bir editör gayet ikna edici

    • Vim hareketlerinin muscle memory olarak öğrenilip her yerde kullanılabildiği söyleniyor ama gerçekte eklentisiz/ayarsız saf Vim ortamını olduğu gibi kullanmak isteyen geliştirici sayısı çok az. Çoğu kişi kendi kurulumunu ve özelliklerini ince ayarladığı bir editör istiyor. İstisna, gerçekten birden çok makineye ssh ile bağlanan ve varsayılan editör ortamına ihtiyaç duyan insanlar olabilir. Helix’in sadeliği ve sınırlı eklenti yapısından bahsetmişsin; aslında Helix başlangıçta hepsi bir arada bir editör olmayı hedefliyordu ama topluluk bunu istemediği için şu anda bir eklenti sistemi geliştiriliyor. Ana sürümde yok ama ayrı bir branch üzerinde şimdiden çeşitli eklentiler yapılıp kullanılıyor. Eklenti sistemi yeterince sağlamlaşmadan sürüme almamaları bence doğru karar. Helix’in en büyük avantajı, vi/vim/neovim’de hâlâ kalan hantal UX’i iyileştirmiş olması. Yani işlem sırasını değiştirerek commit’ten önce değişen şeyleri daha kolay görmeni sağlıyor ve böylece istenmeyen yan etkileri azaltıyor

  • Bu kadar ayar varsa bence doğrudan vim kullanmak daha mantıklı olur. Helix içinde vim işlevlerini yeniden üretmeye çalışıyorsun ve Helix’in de içeride çok sayıda bağımlılığı var (sadece nvim gibi yüzeye çıkmıyorlar). Benim vim8 ayarım 8 yılı aşkın süredir basitliğini koruyor. Vim8 kullanma nedenim, LTS dağıtımlarla gelen sürüm olması. Otomatik yüklenen yalnızca tek bir eklentim var (vim-tmux-navigator; vim bölmeleriyle tmux bölmeleri arasında kolay geçiş için) ve kodunu inceledim, hiç güncellemiyorum. “İsteğe bağlı” iki eklentiyi de vim’in yerleşik paket yöneticisiyle gerektiğinde :packadd! ile açıyorum. Yalnızca ale(lsp, tanı, kaydederken otomatik biçimlendirme) ve vim-fugitive(git entegrasyonu) kullanıyorum. ale’nin bağımlılığı yok. vim-fugitive ise bir kez kurduktan sonra öylece kullanılıyor. Eklentileri otomatik yüklemememin nedeni, vim’i genelde hızlı düzenleme için kullanmam; yalnızca uzun süreli projelerde git/lsp açıyorum. Gerekmediğinde eklentiye de gerek yok

    • Ben de modern Neovim’i seviyorum; bu sorunu çözmek için bir Python paketi yaptım (özellikle zaten Python ekosisteminde olanlar ya da uv, pipx kullananlar için). uv tool install binwheels-neovim ya da pipx install binwheels-neovim ile en güncel Neovim’i kurabiliyorsun; Windows, macOS ve Linux’ta doğrudan çalışıyor. Bu paket resmi Neovim sürümlerini sarıyor ve uv ya da pipx kullanarak işletim sistemi/mimariye uygun ikili dosyayı indiriyor. Linux tarafında ise resmi sürümden daha eski GLIBC desteği gerektiği için ayrıca derleyip sağlıyorum. Ayrıntılar için PyPI, Github ana sayfa, build log

    • Helix, nvim+eklentilere kıyasla tedarik zinciri saldırısı yüzeyi açısından son derece küçük. Sadece Helix’in kendisi yönetiliyor; her eklentinin ayrı tedarikçileri olduğu nvim’e göre çok daha güvenli. Helix sürümleri de yavaş ve dikkatli ilerlediği için bir zafiyet çıksa bile büyük sorun yaratmaması hedefleniyor

    • Helix’in düzenleme modeli daha üstün

  • TUI istiyorsan, neden neovim yerine Helix kullanasın, merak ediyorum. Helix’in varsayılanlarını seviyorum ama bir noktadan sonra değiştirmek istediğin şeyler çıkınca gittikçe daha zahmetli hale geliyor gibi. Ayrıca Helix ile “tam IDE deneyimi” istiyorsan neden Zed, VSC ya da JetBrains IDE’lerini kullanmayasın, onu da çok anlamıyorum. Ben basit bir şey gerekiyorsa nvim kullanıyorum; daha fazla özellik lazımsa WebStorm açıyorum ya da bir çalışma arkadaşım bir şey arıyorsa onunla birlikte oradan bakıyorum

    • Düşük donanımlı cihazlarda ssh ile çalışırken Helix neredeyse anında açılıyor. Aynı özellikleri nvim ile kurmaya çalışınca yavaşlıyor, ayrıca ayar ve eklenti güncelleme maliyeti artıyor. Bir de Rust bildiğim için hata düzeltmeye katkı verebiliyorum. C ailesi dillerini bilmediğimden, açık kaynak projelerde bildiğim dille yazılmış olanları tercih ediyorum. 12 yıl boyunca yalnızca n/vim kullandım, son 2 yılda Helix’e geçtim; hobi olarak kod yazıyorum. Açıkçası nvim’de özlediğim ve daha doğal gelen şeyler hâlâ çok ama Helix gerçekten “hemen çalışıyor” ve bu rahatlık hepsinin önüne geçiyor

    • Son birkaç yılda neovim, helix, emacs ve nano’yu belli sürelerle kullandım; kutudan çıktığı haliyle en iyi deneyim açık ara Helix’teydi. Varsayılanlar gerçekten çok iyi seçilmiş ve bağlama göre çıkan yardım ve ipuçları o kadar iyi ki, sık kullanılan komutları unutmasan da olur, nadiren kullandıklarını da kolayca bulabiliyorsun. Ayrıca benim zihnimde Helix’in komut sırası, vim’inkinden daha doğal geliyor. nvim/spacemacs gibi modern editörlerde eklenti/ayar bariyeri çok yüksek. Eklenti ekosistemi sayesinde Helix’in şu an yapamadığı şeyler yapılabiliyor olabilir (örneğin emacs’te herhangi bir Lisp dilini IDE gibi kullanabiliyorsun ama Helix bir REPL yükleyemiyor), fakat bunun bedeli yalnızca editörü değil sayısız eklentiyi de öğrenmek ve arama yaptığında cevapların sürüm/kurulum kombinasyonuna göre değişmesi nedeniyle iyice kafa karışması. Yeni bir sistem kurarken sonuçta ya başkalarının tavsiyesine güveniyorsun ya da bizzat deneyip öğrenmek için ek zaman harcıyorsun. Helix yeni bir proje olduğu için geçmiş kararların yükünü taşımıyor; modern geliştirme kalıplarına uygun kararlar ve varsayılanlar seçebiliyor. Kusursuz değil ama TUI’ye yeni başlayan ve hemen kullanılabilir, ayarsız kolay başlangıç isteyen biri için Helix’i tavsiye ederim

    • hx hem başlatma hem çalışma sırasında hızlı, bir de güzel görünüyor. Varsayılanlar da epey tatmin edici, bu yüzden yalnızca ufak tefek düzenlemeler yaptım; emacs/neovim’deki o bitmeyen iyileştirme döngüsüne kıyasla hx ile sanki bir son nokta var. TUI uzak sunucularda da iyi çalışıyor; bu yüzden mac, linux ve sunucu ortamında aynı düzeni kullanıyorum (başka editörlerle de yapılır ama hx bunu iyi destekliyor). İhtiyacım olan tüm lsp’leri gayet iyi destekliyor; languages.toml ayarı biraz uğraştırdı ama diğer editörlerde de durum farklı değildi

    • Basit ayarı ve selection-first editing model’i seviyorum. Bununla ilgili referans burada. Vim’e alışmakta zorlanan insanlarla konuşunca, aslında benim Helix’teki gibi bir “önce seç” modeline doğal olarak yatkın olduğumu fark ettim. Vim’deki gibi hedef metni işlemin ardından gördüğün komutlara alışmak benim için zordu

    • Editör seçimi çok rasyonel bir karar olmaktan ziyade, kişisel zevk, yenilik hissi ya da eğlence gibi psikolojik etkenlerle çok daha fazla belirleniyor

  • :reset-diff-change komutunu ilk kez duydum. Ben şimdiye kadar git’te yalnızca checkout -p kullanıyordum ama bunu Helix içinden yapmak çok daha rahatmış

  • Helix’i kullanıp ciddi şekilde alıştım, artık epey akıcı da kullanabiliyorum. Ama tam tersine, bu “ters iş akışı”nın öğrenmesi ve uygulaması kolay olsa da kullanım hızını düşürdüğünü fark ettim. O yüzden sonunda tekrar Vim’e ve ardından Zed(Vim modu) tarafına döndüm

  • Bugün ilk kez Helix kullandım; gerçekten çok iyi tasarlanmış bir editör. Ama y2$, dw gibi Vim’in hızlı kısayolları eksikmiş gibi geldi

    • Aslında kısayol eksik değil; y2$ yerine 2xy, dw yerine wd yazılıyor

  • Helix’te boş satır dahil mevcut satırı silmenin yolunu hâlâ bulamadım. xd, satır boş değilse tek satır siliyor ama boş satırda iki satırı birden siliyor

    • x mevcut satırı seçer; zaten seçiliyse sonraki satıra genişletir. X ise seçimi satır sınırlarına genişletir (line-wise seçim). X kullanmalısın

    • Boş satırda doğrudan d kullan

    • Gerçekten hafif sinir bozucu. Ben de x davranışını boş satırlarda farklılaştıran önemsiz bir fork kullanıyorum. Ayrıntılar için bu PR’a bakabilirsiniz