GNU Emacs’te lsp-mode’dan Eglot’a geçiş

 (utcc.utoronto.ca)
1 puan yazan GN⁺ 2026-05-13 | 2 yorum | WhatsApp'ta paylaş
  • GNU Emacs’in yerleşik LSP çözümü Eglot’a, daha önce iyi çalışan lsp-mode tabanlı LSP ortamını tamamen değiştiren gerçek bir geçiş deneyiminin özeti
  • Eglot, lsp-mode’a kıyasla minimal ve daha sakin bir arayüz sunuyor; Corfu, Consult, Flycheck gibi harici paketlerle ve standart Emacs Lisp API’leriyle entegre oluyor
  • Geçiş çalışmasının büyük bölümü, Eglot’un kendi ayarlarından ziyade yardımcı paketleri bulma, yapılandırma ve deneme-yanılma sürecine harcandı
  • pylsp, gopls gibi LSP sunucularında workspace yapılandırma yöntemleri farklılık gösteriyor; proje bazlı ayarlar için .dir-locals.el kullanmak gerekiyor
  • Eglot, GNU Emacs’e yerleşik geldiği için uzun vadede Emacs kullanıcılarının geçişi değerlendirmesine değer bir seçenek

Geçiş motivasyonu ve genel izlenim

  • Özel olarak güçlü bir neden olmadan, Corfu’ya geçtikten sonra Eglot’u denemelik kullanıp devam etme durumu
  • lsp-mode + lsp-ui, aynı anda çok sayıda bilginin gösterildiği yoğun (busy) bir arayüz; daha sakin bir LSP deneyimi istendiği için geçiş yapıldı
  • Eglot, lsp-mode’dan daha minimal, ancak tam bir deneyim için ek paketlerle güçlendirilmesi gerekiyor
  • Sonuç olarak memnuniyet verici; Go ve Python modlarında 'common prefix ile otomatik tamamlama' gibi özellikler daha iyi çalışıyor
  • lsp-ui ayarları ayrıca ince ayarlanabilirdi, ancak Eglot’a geçmek tüm sorunları bir anda çözdü

Yardımcı paket entegrasyonu

  • Corfu, ek bir ayar olmadan mevcut yapılandırmayla otomatik tamamlama için çalıştı
  • Çapraz referanslarda lsp-ui tarzı önizleme almak için consult paketini bağlamak ve xref-show-xrefs-function değerini consult-xref olarak ayarlamak gerekiyor
  • Flycheck ile Flymake arasında düşünülüp sonunda Flycheck seçildi
    • Flymake, Eglot ile daha iyi entegre oluyor ama genel olarak Flycheck tercih ediliyor
    • Eglot, flymake-modeu otomatik etkinleştirdiği için, devre dışı bırakmak amacıyla eglot-stay-out-of içine flymake eklendi
    • flycheck-eglot’un global modu kararlı çalışmadığından, hook’ları doğrudan ayarlayan bir yöntem kullanıldı

Tuş atamaları

  • Eglot, varsayılan tuş atamaları sunmadığı için bunları elle tanımlamak gerekiyor
  • Şu anda kullanılan atama örnekleri:
    • C-c r → eglot-rename, C-c o → eglot-code-action-organize-imports
    • C-c h → eldoc, C-c a → eglot-code-actions, C-c q → eglot-code-action-quickfix
    • C-M-<mouse-2> → eglot-code-actions-at-mouse (flycheck-eglot’un entegrasyon sınırlamasını aşmak için kullanılan fare kısayolu)
  • eglot-format bilerek atanmadı — Go’da zaten go-mode’un gofmt aracı kullanılıyor
  • eglot-extend-to-xref değerini t yapmak, harici bir öğeye atladıktan sonra M-? ile projedeki diğer kullanımları aramayı mümkün kılıyor

LSP sunucusunu otomatik başlatma

  • Eglot’un resmî belgeleri elle başlatmayı önerse de, yalnızca yerel dosyalar için otomatik başlatma ayarlandı
  • eglot-ensure-local-only fonksiyonu tanımlanarak, file-remote-p ile uzak dosya olup olmadığı kontrol ediliyor ve ardından eglot-ensure çağrılıyor
  • eglot-ensure kısıtı: bir dil için birden fazla LSP sunucusu olduğunda (ör. Python’da pylsp ve ruff), yalnızca varsayılan sunucu otomatik seçiliyor; değiştirmek için mevcut sunucuyu kapatıp eglotu elle çağırmak gerekiyor
  • Birden fazla LSP sunucusunu aynı anda çalıştırmak için rassumfrassum gibi çoklayıcı programlar kullanılabiliyor

Code Actions erişilebilirliği

  • LSP sunucularının sunduğu code action sayısı fazla, ancak Eglot içinde bunlara rahat erişmek zor (lsp-mode’da da benzer)
  • LSP sunucuları code action’ları yalnızca istek üzerine sağlıyor ve bunlar belirli konumlara bağlı
  • Eglot, sunucunun gönderdiği uzun code action listesini filtreleme özelliği sunmadığı için, hem Go hem Python’da liste kalabalıklaşıyor

pylsp Workspace yapılandırması

  • pylsp’de (Python LSP sunucusu), stil tabanlı linter’ları sürekli tanılamadan devre dışı bırakmak için eglot-workspace-configuration kullanmak gerekiyor
  • lsp-mode, tek tek tanılama araçlarını (mccabe vb.) kapatmak için kullanışlı denetimler sunarken, Eglot’ta JSON biçiminde workspace configuration doğrudan yazılmalı
  • Örnek olarak mccabe, pylint, mypy, pycodestyle gibi bileşenler :enabled :json-false ile devre dışı bırakılıyor
  • mypy ile ilgili anahtarların pylsp_mypy ve mypy olmak üzere iki farklı adla karışık kullanılması, pylsp’nin iç uygulama ayrıntılarından kaynaklanıyor
  • Mutlaka setq-default kullanılmalı; setq ile çalışmıyor

Proje bazlı ayarlar ve .dir-locals.el

  • Proje bazında LSP sunucu parametrelerini geçici olarak ayarlamanın kolay bir yolu Eglot’ta yok
  • Belirli ayarlar gerekiyorsa, bunu doğru biçimde .dir-locals.el dosyasına yazmak en kolay yöntem
  • gopls (Go) ve pylsp (Python) için yapılandırma yapıları tamamen farklı; her LSP sunucusu ayrı ayrı öğrenilmeli
  • Çalışma anında ayar değiştirmek için dir-locals-set-class-variables ile yeni bir sınıf tanımlayıp, ardından dir-locals-set-directory-class ve eglot-signal-didChangeConfiguration çağrılarını yapan özel bir fonksiyon yazmak gerekiyor
  • Eglot, tüm proje (dizin ağacı) için tek bir LSP sunucusu çalıştırdığı için, dosya/buffer düzeyinde LSP ayarı yapılamıyor; ayarlar mutlaka proje düzeyinde uygulanmalı
  • eglot-workspace-configuration genel bir yöntemle ayarlanırsa buffer-local değişken haline geliyor ve pratikte işe yaramaz oluyor

Flymake ve Flycheck deneyimi

  • Flymake, Eglot ile daha iyi entegre oluyor; tanılama notlarında doğrudan LSP sunucusu tabanlı düzeltme önerilerini (quickfix code action) button 2 açılır menüsünde gösteriyor
  • Flycheck yalnızca hata işaretleme yapıyor; LSP code action’larını ayrıca tetiklemek gerekiyor
  • İlk başta Flymake’e geçilmiş olsa da, Flycheck’in daha iyi olduğu yönler bulunduğu için iki tarafın ayarları da korundu
  • flycheck-eglot geliştiricisi bu konu için bir geçici çözüm önerdiğinden Flycheck’e geri dönüldü
  • Flycheck, Flymake’e göre daha geniş bir checker koleksiyonuna sahip ve checker’lar arasında geçiş daha kolay
  • Flymake’in 'satır sonunda tanılama gösterimi' seçeneği eksik kalıyor
    • flycheck-inline, yalnızca mevcut konumdaki uyarıları gösteriyor; kaydırırken tüm uyarıları göstermiyor
    • Sideline + sideline-flycheck aynı sınırlamaya sahip ama UI deneyimi daha iyi

İlgili okumalar

2 yorum

 
GN⁺ 2026-05-13
Lobste.rs yorumları

  • Dile bağlı olarak Eglot’u otomatik başlatmayı tavsiye etmek ölümcül derecede kötü olabilir. Birçok dilin LSP sunucusu güvenilmeyen kodla güvenli şekilde kullanılamaz ve saldırganın kontrol ettiği bir Rust veya Elixir projesindeki dosyayı yalnızca açmak bile makinenin ele geçirilmesine yol açabilir
    Güvenli olduğu bilinen bir LSP sunucusuna sahip bir dil değilse LSP’yi otomatik etkinleştirmekten kaçınılmalı. Dayanak: https://rust-analyzer.github.io/book/security.html

    • Düşmanca olabilecek koda bakıyorsanız, sonuçta tüm çalışmayı gerçek bir güvenlik sınırı içinde yapmanız gerekir. git status bile bir saldırı yüzeyi olabilir: https://github.com/justinsteven/advisories/…
      Fark şu ki yukarıdaki örnekte istismarın deponun kendisinde bulunması gerekirken, LSP’de sorun bağımlılık tarafında da çıkabilir. Yine de alışkanlık gereği LSP’yi açmaya alışırsanız uyarılara karşı duyarsızlaşmayı engellemek zor görünüyor
    • Otomatik başlatmadan kaçınmak için bir başka neden de bazı dil sunucularının kaynak gereksinimlerinin yüksek olması. Orta ölçekli bir Rust projesinde yalnızca kısa süreliğine bir dosya açmak bile birkaç dakika çalışan 4GB’lık bir rust-analyzer süreci ve 1GB’ı aşan bir target/debug/ dizini oluşturabilir
    • Zaten cargo build komutunu çalıştırdığınız anda iş işten geçmiş sayılır. Elbette LSP’nin otomatik yüklenmesi ile kullanıcının açıkça çalıştırdığı bir komut arasında büyük fark var, ama gerçek kullanımda bu fark düşünüldüğünden daha küçük olabilir
    • Otomasyon istiyorsanız, lsp-mode gibi etkinleştirmeden önce sorup projeyi bir izin listesine ekleyen bir yöntem daha iyi. Zaten “otomatik çalıştır” kancanız varsa, önce read-from-minibuffer ile “bu klasöre güveniyor musunuz?” diye sordurmak yaklaşık 10 satırda yapılabilir ve projectile gibi bir şeyle temel dizini belirleyerek güvenlik faydasının çoğunu elde edebilirsiniz
      Benim ayarım lsp-modeun izin listesini kullanıyor ama her oturumda siliyor; böylece Emacs’i her yeniden açtığımda proje bazında yeniden onay vermem gerekiyor. Sanırım bunu başta performans için yapmıştım; lsp-mode bazen belirli bir projeyi açmadan önce birden çok süreç başlatıyordu. Güvenlik riski gerçek, ama makul bir iş akışı kurmak da çok zor değil

  • Eglot’taki en can sıkıcı şey, komutların çoğunu fonksiyon olarak sunmaması ve bunları xref gibi Emacs arayüzleri üzerinde tanımlaması. Clojure’da olduğu gibi hem CIDER hem de clojure-lsp için xref arka uçları olduğunda, yüklenmiş kodun gerçek çalışma zamanı durumunu bilen CIDER tarafını tercih ediyorum
    clojure-lspnin statik analizi özellikle uzak REPL iş akışlarında senkron dışına çıkabiliyor. lsp-modeda tanıma git gibi özellikleri doğrudan komut olarak çağırırken xrefi kullanmaya devam edebilirsiniz, ama Eglot’ta belirli bir xref arka ucunu devre dışı bırakmak epey zahmetli. lsp-modedaki bazı diğer komutlar da Eglot’ta yok, halbuki bunlar da aslında xrefe benzer Emacs entegrasyon noktaları üzerinden sunulabilecek özellikler

  • lsp-modeu bir kez denedim ama kafa karıştırıcı açılır pencereler ve bildirimler o kadar fazlaydı ki hemen kaldırdım. Eglot çok daha sessiz bir LSP deneyimi sunuyor
    Açık tutup, hazır olduğunuzda özellikleri kullanıyorsunuz. ~cks’in ters yönden yaklaşarak çeşitli ipuçları ve alternatiflerden söz etmesi ilginç

    • lsp-modeu pek çok özelliği kapatarak oldukça sessiz bir arayüzle kullanıyorum. Eglot’a geçmeye çalıştım ama istediğim entegrasyonları sunmuyor gibi göründüğü için o zaman fazla uğraşmadım
      Asıl aradığım şey çok büyük depoları kaldırabilecek bir LSP sunucusu. Bu sık sık sınır olarak karşıma çıkıyor; kaynak indekslemeyi bir kerede büyük ölçüde yapıp sonra çeşitli LSP tarzı işler için yeniden kullanacak bir şey mi yazmalıyım diye düşünüyorum ama başka bir okyanusu kaynatmaya kalkmak da istemiyorum

  • Emacs için LSP istemcileri arasında en bilinenler Eglot ve lsp-mode, ama lspce ve lsp-bridge gibi alternatifler de var
    Eglot’u birkaç yıldır memnuniyetle kullanıyorum, ancak ileride daha büyük sorunlara dönüşebilecek tasarımsal bir sınırlaması var. Her arabellek için tek istemci varsayıyor; Eglot tasarlanırken bu makuldü ama artık tek bir arabellekte birden fazla LSP sunucusu çalıştırmak istemek giderek daha yaygın. Şu anki öneri, ayrı bir programı LSP çoklayıcısı gibi kullanmak

    • Bu amaç için şu var

  • 4 gün önce Python için lsp-modedan Eglot’a geçtim ve memnunum
    Mevcut yapılandırmamın en minimal sürümünü burada paylaştım: https://discuss.afpy.org/t/configuration-emacs-minimale-en-2026/3001

    • Neredeyse bir yıl önce elpy’den eglot + basedpyright’a geçtim, ben de oldukça memnunum
      Yalnız tamamlama konusunda bazı rahatsızlıklar var. Örneğin foo<tab><tab> bastığımda mevcut kapsamla eşleşen bir sembol olmasına rağmen basedpyright bazen garip bir şeyi otomatik içe aktarıyor ve yalnızca en uzun ortak dizeye kadar tamamlama yapmanın bir yolunu hâlâ bulamadım. Bunun dışında oldukça iyi

  • İnsanların Emacs’i modern bir IDE gibi kullanabilmesini kıskanıyorum. Emacs tuş bağlarını kullanıyorum ama 6-8 saat harcasam bile Emacs’i IDE gibi çalışır hale getiremedim
    Eskiden Linux ve FreeBSD geliştirme ortamlarında TypeScript yerine kullandığım FB Flow ile bunu yapmaya çalışıp vazgeçtim; geçen hafta sonu da Windows’ta tree-sitter’lı tam özellikli bir Python ortamı kurmaya çalışıp yine vazgeçtim. Ayarlanacak çok şey var ve tree-sitter ayrıştırıcıları gibi DLL’leri de ayrıca tek tek indirmek gerekiyor; düzgün bir IDE gibi yapmak için gerekenler fazla geliyor. Artık buna zaman harcamak istemiyorum ama ara sıra herhangi bir terminalde emacs -nw yazınca tanıdık düzenleme ortamının açılması hoşuma gidiyor

    • Python için fido-vertical-mode, which-key-mode, global-completion-preview-mode, yasnippet, eglot-ensure, basedpyright gibi minimal bir yapılandırmayla başlamak için yeterli olabilir
      basedpyright PATH içindeyse, tree-sitter sözdizimi olmadan da düzgün tamamlama ve sözdizimi vurgulaması elde edersiniz. Bu, tam yapılandırmamın en aza indirilmiş bir sürümü; tam yapılandırma my full config içinde
    • doom emacs denemeye değer. Yapılandırması çok kolay ve varsayılan haliyle de çoğu şey iyi çalışıyor. evil-mode hoşunuza gitmezse Emacs tuş bağlarına da geri dönebilirsiniz