Emacs'te Her Şey Bir Hizmet Gibi Görünür

• Emacs, bir işletim sisteminin kendisinden ziyade çekirdek üzerindeki uygulamaları ve yardımcı araçları orkestre eder; dosya sistemi, ağ ve harici programlardan yararlanarak çeşitli hizmetlerin istemcisi olur
• Bir istemcinin ihtiyaç duyduğu UI, iletişim katmanı ve yerel veri deposu, minibuffer, buffer, URL, TCP/UDP, JSON, SQLite gibi yerleşik kütüphanelerle kurulabilir
• Dinamik bir dil olan Emacs Lisp (Elisp), Elisp fonksiyonları ile kabuk komutlarını çalışma anında birleştirerek Emacs'ın erişebildiği işlevleri esnek biçimde orkestre eder
• Örnek wttr komutu, bir konum alıp wttr.in'e HTTP isteği gönderir, JSON'dan bölge, sıcaklık ve hava durumunu çıkarır, ardından bunu minibuffer'da gösterip kill ring'e de kaydeder
• Tam wttr.el, cloc ölçümüne göre 67 satırdır; ağ isteği ve JSON işlemeyi Python gibi komut satırı araçlarına bırakılırsa, kabuk komutunun kendisini hizmet olarak kullanan daha kısa bir Elisp istemcisi de yapılabilir

---

İşletim sisteminin üstünde hizmetleri orkestre eden Emacs

• Emacs'ı bir işletim sistemi olarak adlandırmak tam doğru değildir, ancak işletim sistemi çekirdeğinin üzerinde uygulamaları ve yardımcı araçları orkestre edebilmesi bu benzetmeye yol açar
• Dosya sistemi ve ağ gibi işletim sistemi hizmetlerine yerleşik yeteneklerle erişebilir ve başka programları da çalıştırabilir; bu yüzden Emacs içinde istemci davranışını anında kurmak kolaydır
• Birçok hesaplama işi farklı istemci modlarıyla yürütülebildiğinden, kullanıcının “yalnızca Emacs içinde yaşaması” fikri de anlam kazanır

İstek ve yanıt üzerinden istemci-sunucu modeli

• İstemci-sunucu modeli, kaynak sağlayan bir hizmet ile bunu talep eden bir istemcinin işi paylaştığı etkileşim kalıbıdır
  • İstemci bir istek gönderir
  • Sunucu isteği işleyip bir yanıt döndürür
• İstek ve yanıttan oluşan işlemler ağ üzerinden ya da tek bir sistem içinde yerel olarak gerçekleştirilebilir
• Ağ tabanlı model, REST tarzı yazılım mimarisinde geniş ölçüde gelişmiştir

Emacs istemcisini oluşturan üç alan

• Tipik bir istemci şu üç alandan sorumludur
  • UI: Gerektikçe kullanıcı girdisi ve çıktısını işler
  • İstemci sınırı (Client Edge): Hizmetle iletişim kurar; ağ istemcilerinde bu rolü ağ alt sistemi üstlenir
  • Yerel veritabanı: Sunucuyla değiş tokuş edilecek veya senkronize edilecek veriyi temsil eder; somut yönetim biçimi uygulama gereksinimlerine göre değişir

• Kullanıcı arayüzü oluşturma

  • Emacs, istemci UI'ı oluşturmak için çeşitli yerleşik yetenekler sunar
  • Minibuffers
  • Buffers
  • Completion
  • Tabulated List Mode
  • Variable Pitch Table(vtable)
  • Transient

• Hizmet iletişimi ve veri dönüşümü

  • Hizmete bağlanan istemci sınırında şu yeteneklerden yararlanılabilir
    • URL
    • Socket(TCP/UDP)
    • SMTP
  • Serileştirme ve serileştirmeyi çözme için yerleşik ayrıştırıcılar kullanılır
    • JSON
    • XML

• Yerel veri yönetimi

  • Sunucu verisinin yerel temsili için Elisp koleksiyonları kullanılabilir
    • Association Lists
    • Property Lists
    • Hash Tables
  • Kalıcı yerel depolama gerekirse SQLite kullanılabilir
  • Gerçek bir istemcinin karmaşıklığı gereksinimlere bağlıdır; ağır işlemleri üstlenen mevcut komut satırı yardımcı araçları varsa bunlar kabuk çağrısıyla erişilen bir hizmet olarak yeniden kurgulanabilir

Elisp ile işlevleri birleştirme biçimi

• Yukarıdaki kütüphanelerin tamamına Emacs Lisp (Elisp) içinden erişilebilir
• Elisp, çalışma anında yüksek düzeyde doğaçlama yapılandırmaya izin veren dinamik bir programlama dilidir
• Emacs'ın kullanabildiği davranışlar, Elisp fonksiyonlarından kabuk komutlarına kadar birleştirilerek karmaşık akışlar orkestre edilebilir

wttr.in hava durumu istemcisinin uygulanması

• wttr.in, konsol odaklı bir hava tahmini web hizmetidir ve JSON çıktısını destekler
• Emacs için wttr komutu şu sırayla çalışır
  1. Kullanıcıdan bir konum alır
  2. wttr.in istek URL'sini oluşturur
  3. HTTP isteğini gönderir
  4. JSON yanıtını işler
  5. Sonucu minibuffer'da gösterip kill ring'e kaydeder
  6. İşleme sırasında hata oluşursa minibuffer'da hata mesajını gösterir

• İstek URL'sini oluşturma

  • wttr--request-url, temel URL olarak https://wttr.in kullanır
  • Girilen konumdaki boşlukları + ile değiştirir ve /<location>?0&format=j1 biçiminde sorgu oluşturur
  • Oluşturulan URL daha sonra JSON getirme fonksiyonuna aktarılır

• HTTP isteği ve JSON ayrıştırma

  • fetch-json-as-hash-table, URL'yi url-retrieve-synchronously ile eşzamanlı olarak getirir
  • Veri alınamazsa Failed to fetch data from <URL> hatasını üretir
  • Yanıt buffer'ında HTTP meta veri başlıklarının sonrasına gider, ardından kalan içeriği json-parse-buffer ile Elisp hash-table yapısına dönüştürür
  • İşlem bittikten sonra indirilen ağ buffer'ı, bellek sızıntısını önlemek için her zaman kaldırılır

• Hava durumu mesajını birleştirme

  • wttr--report-message, JSON verisinden şu değerleri çıkarır
    • En yakın bölgenin adı
    • Bölge
    • Ülke
    • Anlık santigrat sıcaklık temp_C
    • Anlık fahrenheit sıcaklık temp_F
    • Hava durumu açıklaması weatherDesc
  • Boş olmayan konum öğelerini virgülle birleştirir ve konum: santigrat, fahrenheit hava durumu açıklaması biçiminde sonuç üretir
  • Tüm uygulama wttr.el kaynağında görülebilir

Komut satırı araçlarını da hizmet olarak kullanmak

• Emacs API'si yüksek seviyeli soyutlamalar sunar ve HTTP isteğiyle JSON işlemeyi doğrudan uygulayan wttr.el bile cloc ölçümüne göre 67 satırdır
• Daha basit bir alternatif, gerçek ağ isteği ve JSON işlemeyi weather adlı bir Python betiğine bırakmaktır
  • Elisp'in weather komutu kullanıcıdan bir konum alır
  • Konumu argüman olarak ekleyip weather kabuk komutunu oluşturur
  • Komutu shell-command-to-string ile çalıştırır
  • Dönen sonucu kill ring'e kaydedip minibuffer'da gösterir
• Bu düzende kabuk komutu, istek alan hizmet olur ve Elisp fonksiyonu istemci rolünü üstlenir
• Elisp'in dinamik doğası sayesinde Elisp kütüphaneleri ile komut satırı yardımcı araçları gerektikçe birleştirilebilir; bu entegrasyon olanağı, Emacs içinde her şeye bir hizmet gibi yaklaşmayı mümkün kılar

[GN⁺]

Hacker News yorumları

• Lisp Machine ailesi ana akım haline gelemediği için Emacs bir işletim sistemi gibi görünüyor
  “Symbolics Lisp Machine demo”
  https://www.youtube.com/watch?v=o4-YnLpLgtk
  “Emacs and Lisp”
  https://funcall.blogspot.com/2025/04/emacs-and-lisp.html
  Lucid, erken dönem LSP fikirlerinden birini hayata geçirmek için Emacs’i XEmacs olarak fork etmişti ve o dönemdeki özelliklerin çoğu artık yeniden Emacs’e entegre edildi
  https://dreamsongs.com/Cadillac.html
  “Lucid Energize Demo”
  https://www.youtube.com/watch?v=pQQTScuApWk

  • İşletim sistemi, birden fazla programın paylaşması için yapılmış bir sanal makinedir. Genelde üzerinde çalıştığı komut kümesi mimarisinin (ISA) büyük kısmını açığa çıkarır, ama Inferno, Taos, AS/400 gibi istisnalar da vardır
  • LISP makineleri başarılı olsaydı bile, onların üzerinde çalışan editör işletim sistemi olmazdı. Platform ile işletim sistemini karıştırırsanız web tarayıcısına, hatta Roblox’a bile işletim sistemi deme noktasına gelirsiniz

• client, server, request kavramlarını yeterince geniş tanımlarsanız her şeyi istemci/sunucu mimarisi içine sıkıştırabilirsiniz. Bu, LISP fonksiyonları tek bir işi iyi yapıyor diye Emacs’in Unix felsefesini izlediğini zorla iddia etmeye benziyor
  Emacs’in LISP machine fikrini takip ettiğine çoğunlukla katılabilirim ve onun üzerinde fiilen istediğiniz her şeyi inşa edebilirsiniz. CLI araçlarıyla mükemmel biçimde entegre olur, ama buna istemci/sunucu demenin ne kazandırdığı belirsiz
  On yıllar boyunca çeşitli modaları takip ederek özellikleri içine aldı; içinde bugün neredeyse hiç kullanılmayan CEDET anlamsal analiz motoru bile var. Sonra LSP geldi, şimdi de ajan çağı geldi ve Emacs ajanlar için bir frontend olarak da gayet iyi iş görüyor

  • Emacs, Unix dünyasına sığınmış bir LISP mültecisidir. Unix felsefesini değil, LISP felsefesini izler; ama Unix ile iyi entegre olur
  • Eskiden çoğu IDE’nin kendi anlamsal analiz motoruna sahip olması yaygındı. İlk Java dil sunucusunun da Eclipse’in Java anlamsal analiz motorundan ayrıştırılarak çıkarıldığını hatırlıyorum

• Emacs’i 25 yıldan uzun süredir kullanıyorum ama geçen yıl geçtiğim şirkette, Emacs’in özellikle çok uygun olduğu işler için bile kullanmama izin verilmiyor. Gerekçe, tüm ekip üyelerinin aynı araçları kullanması gerektiği; başkalarını Emacs’e geçirmek de başarısız oldu
  Şimdi her iş için ayrı tek amaçlı araçları çok daha verimsiz şekilde kullanıyor, üstüne sürekli yeni arayüzler ve tuş eşlemeleri öğreniyorum

  • Şirket büyüdükçe kurulu yazılımları kontrol etmeye başladı ve kurulum izinlerini/engellerini Microsoft Intune ile yönetiyor gibi görünüyor. Emacs’i artık kullanamayacağım korkusuyla dizüstü güncellemesini ya da değişimini bile erteliyorum
    Yöneticiler yeni projede herkesin Visual Studio Code kullanmasını isteyecektir, ama kullandığımız tüketim modeli VSCode tarafından da desteklenmiyor. Git ve dağıtım süreci uyuyorsa editörü herkesin iyi bildiği şekilde seçmesi gerekir, ama muhtemelen Microsoft tarafından desteklenmeyen açık kaynak olduğu için riskli ve şirket tarafından doğrulanmamış yazılım olduğu cevabı gelecektir
    Emacs her gün kullandığım temel araç; yasaklanırsa istifa etmeyi düşünürüm. Yöneticiler anlamaya ya da mantıklı değerlendirme yapmaya çalışmıyor, sadece başka bir BT departmanının talimatını izliyor
  • Herkesin telnet kullanıp ssh’ın yasaklanmasını da makul bulur musunuz? Emacs kullanmak için izin istemeyin, sadece kullanın
    Şirket genel amaçlı metin editörünü belirlediyse Notepad açmanın da sorun olup olmadığını, kişisel yapılacaklar aracı bile belirleyip belirlemediğini görmek ilginç olabilir. Emacs’in yapabildiği ama şirketin henüz araç atamadığı bir kategori bulun ve o amaçla kurun
  • Bu, farklı mizaçları yönetmek verimsiz olur diye tüm ekip üyelerine lobotomi uygulamakla aynı mantık
  • Başka araçlarda da Emacs’teki kadar özgürlük ve özelleştirilebilirlik olsaydı, Emacs kullanıcıları her işi onun içine tıkmaya çalışmazdı. Mesele Emacs’in mutlak olarak üstün olması değil; diğer araçlar daha kısıtlı ve kendi kendini belgeleme konusunda daha zayıf
  • Tüm ekip üyelerinin neden aynı araçları kullanmak zorunda olması gerektiği iddiasının neden geçerli sayıldığını merak ediyorum

• Emacs bir platformdur ve işletim sistemi de birçok platformdan sadece biridir. Platform, üzerinde yeni şeyler inşa edebilmeniz için tasarlanmış bir yazılım katmanıdır; dolayısıyla kurmak istediğiniz Y için hangi X platformunun uygun olduğunu sormalısınız
  Benim için X çoğu zaman Emacs oluyor, ama Racket ya da Rust da olabilir. Hem uygulama olup hem de iyi bir platform olan araçlara, sıradan uygulamalardan daha fazla öğrenme yatırımı yapmak değerlidir

• Emacs’i yeterince kullanıp “Emacs bir işletim sistemidir” sözünü şaka değil de gerçekten anlamlı bir kavram olarak kavradığım an, kariyerimde önemli bir dönüm noktası oldu

  • Zaten işletim sistemleri de vardı ve program da yazılabiliyordu; Emacs’in gerçekten yeni bir yetenek sağlayıp sağlamadığı şüpheli. Emacs bir IDE ya da genel amaçlı otomasyon çalışma ortamı değil, bir metin editörü; MSPaint’e Lisp ekleyince bir anda müthiş bir araca dönüşeceği fikrini anlamakta zorlanıyorum

• org mode’u denemek için birkaç yıl önce Emacs kullanmaya başladım ve aşırı yüksek esnekliği yüzünden kullanmaya devam ettim

  • Bir süre Spacemacs kullandım, ama artık Caps Lock’u yeniden programlayabildiğim bir Keychron G6 Pro’m var; bu yüzden şimdi init.el dosyamı gerçekten kendim kurcalamayı düşünüyorum

• Emacs, içine metin editörü gömülü bir programlama ortamına daha yakındır. Bazı Smalltalk image’larına benzetirseniz oldukça ilginç bir araç olarak görünebilir

• Emacs işletim sistemi değil, daha çok bir shell gibidir; ama shell kavramının kendisi de yaygın biçimde anlaşılmıyor

  • Shell’i diğer araçları kullanma aracı olarak görürseniz, vi aslında shell’e daha yakındır. Çünkü birçok işi :.! ile diğer standart Unix programlarına devretmek zorundadır
    Buna karşılık Emacs, bir işletim sistemi gibi her türlü işlevi tek bir dev dağıtımın içine toplar

• Emacs kullanmayan birine göstermek için uygun kısa bir giriş videosu yakın zamanda buldum
  https://www.youtube.com/watch?v=mJZDmO5yOxE

  • Anon Emoose’un init.el dosyasını gerçekten merak ettim

• Emacs’in kendisi istemci ve sunucu olarak çalıştırılabilir. emacs --daemon ile sunucuyu başlatıp ardından emacsclient ile bağlanırsanız, terminal ve GUI’deki tüm örnekler aynı sunucuyu kullanır ve açık dosyalarıyla buffer’ları paylaşır
  Ne yazık ki bu sadece yerelde çalışıyordu; Emacs sunucu soketini ssh ile tünelleyip uzak istemciden bağlanmayı denedim ama başaramadım

  • Geriye dönüp bakınca emacsclient adı pek iyi değilmiş. 2026’da Emacs’le ilk kez karşılaşan biri, bunun REST istemcileri gibi ağ üzerinden istemci ve sunucunun çalışma durumunu senkronize ettiğini kolayca sanabilir
    Burada istemci ve sunucu, Unix yerel alanı yani dosya sistemi soketi üzerinden istemcinin basit kontrol komutları gönderdiği bir yapıyı ifade ediyor. Daha sonra ağ soketleri de desteklenmeye başlandı, ama istemcinin gönderdiği şey hâlâ yalnızca basit kontrol komutları
  • Soket tünelleme çalışmasa da X11 kullanıyorsanız ssh -X ile uzak Emacs’in frame’ini yerel X sunucusunda açabilirsiniz. Ancak PGTK olmayan GTK derlemelerinde, yeni bir frame kapatıldığında uzak Emacs çökebilir; buna dikkat etmek gerekir
  • Soket tünellemenin neden başarısız olduğunu kontrol edip etmediğinizi merak ediyorum