Kötü haberler, Emacs

• Emacs 30’un registers özelliğindeki değişikliklere yönelik bir eleştiri yazısıydı, ancak şu anda herkese açık metinde özgün içerik kaldırılmış durumda
• Özgün metin, Emacs’in son dönemdeki gelişimini aşırı derecede eleştirel ele aldığı ve ilgili kişilere karşı nazik olmadığı gerekçesiyle silinmiş
• Kaldırılan içeriği görmek isteyenlere yalnızca yazarın web sitesindeki Git logunu incelemeleri yönünde bir not bırakılmış
• Geriye kalan temel nokta, yazarın Emacs’in biraz farklı bir branch sürümünü günlük kullanım için kullanmaya başladığı
• Şu anki açık metinle Emacs 30 registers özelliğindeki somut değişiklikleri veya teknik tartışma noktalarını doğrulamak zor

---

Kaldırılan Emacs 30 eleştiri yazısı

• Özgün metin, Emacs 30’un registers özelliğinde kötüye gittiği düşünülen değişiklikleri ele alan bir yazıydı
• Açık metinde, özgün yazının Emacs’in yakın dönem geliştirmelerini aşırı biçimde eleştirdiği ve ilgili kişilere karşı nazik olmadığı için kaldırıldığı bilgisi yer alıyor
• Önceki blog yazılarına kıyasla çok daha fazla ilgi görmüş olması da kaldırılma gerekçeleri arasında anılıyor

Şu anda doğrulanabilen bilgiler

• Kaldırılan yazıyı mutlaka okumak istiyorsanız bu web sitesinin Git logunu inceleyebilirsiniz
• Yazar, Emacs’in biraz farklı bir branch sürümünü günlük kullanım için kullanmaya başladığını belirtiyor
• Şu anda açık olan metinde, Emacs 30 registers özelliğindeki değişikliklerin somut sorunları, örnekleri veya yama içeriği yer almıyor

[GN⁺]

Hacker News yorumları

• Emacs geliştirme dalına, kasıtlı olsun ya da olmasın, uyumluluğu bozan bir değişiklik girip bazı kullanıcılar endişelerini dile getirdiğinde süreç bunu hemen geri almak şeklinde ilerlemez.
  Artıları ve eksileri tartışmak, çeşitli çözümleri uygulayıp iyileştirmek ve ardından bir uzlaşma noktası bulmak gerekir. Kullanıcıların endişelerini dile getirmesinin üzerinden yalnızca 3 gün geçtiğine göre bu sürecin çoktan bitmiş olması gerektiğini söylemek zor.
  Eli’nin son yanıtının özü de şuydu: “İlk tartışmaya katılan iki kişi yeni davranışın eski davranıştan çok daha makul olduğunu düşündü, ama şimdi karşı görüşler de geldiğine göre davranışı tartışmaya devam edebilir, ardından varsayılan değeri konuşabiliriz.”
  Emacs’in geliştirilme biçiminde ciddi sorunlar olduğunu düşünüyorum; ancak kullanıcıların normalde emacs-devel’deki inatçı kişileri suçlayıp, kendi hoşlanmadıkları bir değişiklik girince de dünyanın sonu gelmiş gibi davranmaları da bir sorun. Bu, bakımcıların savunmacı hale gelmesine yol açıyor.

  • Geliştirme dalını kullanırken uyumluluğu bozan bir değişiklik çıktı diye ortalığı ayağa kaldırmak doğru değil. Geliştirme dalında bunun olması beklenebilir.
    E-posta dizisini okuduğunuzda bunun “kibir”den ziyade güçlü bir görüş ayrılığı olduğu görülüyor; uzlaşmanın zaman alması kaçınılmaz. Biri kendi bakış açınıza göre hemen geri adım atmıyor diye onu herkesin önünde “kibirli” diye nitelemek ve diziyi okumayacak bir kalabalığı işin içine çekmeye çalışmak, tacize yakın görünüyor.
    Ayrıca değişikliği isteğe bağlı hale getiren yamanın görmezden gelindiğini söylemek de dürüstçe değil. O yama yalnızca isteğe bağlılık eklemiyordu; başka değişiklikleri de kaldırdığı için reddedildi. Sorumluluğu bu şekilde tek bir kişiye yüklemek de kabul edilebilir değil.
  • “Kullanıcı tepkisi nihai kararın temel girdisidir” derken, aynı zamanda olumsuz kullanıcı tepkisini “abartılı” diye eleştirmek çelişkili görünüyor.
    Kullanıcılar tepki vermeseydi, açıklanan sürece göre karşı çıktıkları ilk değişikliğin aynen girmiş olması kuvvetle muhtemeldi. clojure-mode’da da rms, uzun süredir korunan Clojure topluluğu yazarının adını alıp yeniden yazmaya çalışmıştı; insanlar listede itiraz ederek bunu durdurdu, ama sonrasında bu kişilere abarttıkları söylendi. Bu yüzden “abartı” eleştirisi pek anlamlı görünmüyor.
  • Bu kötü bir süreç. Özellik incelemesi ana dala birleştirildikten sonra değil, birleştirilmeden önce başlamalı.
    Geniş toplulukla tartışmadan kullanıcı akışını bozan bir özelliği ana dala koyarsanız insanların öfkelenmesi doğaldır. Bu tür bir birleştirme, eski araçların topluluk desteğini kaybetme biçimidir.
  • Emacs topluluğu, en azından tarihsel olarak geriye dönük uyumluluğa çok güçlü biçimde önem verdi. Mevcut kullanıcıları kırmak Emacs’te neredeyse yapılabilecek en kötü şeydir.
    Uyumluluğu bozan bir değişikliği hemen geri almayı ciddi biçimde değerlendirmiyorlarsa, bu Emacs geliştiricilerinin artık geriye dönük uyumluluğa eskisi kadar önem vermediğinin işareti olur ve bu da mevcut kullanıcıların kayda değer bir kısmını gözden çıkarmak anlamına gelir.
    https://www.murilopereira.com/the-values-of-emacs-the-neovim...
    Temel değerler önemlidir. Emacs bakımcıları temel değerleri ihlal etti ve topluluğun bundan rahatsız olması haklı.
  • Yazıdaki açıklamaya göre Emacs’in sağlığı konusunda endişeliyim. master’a birleştirilmeden önce de tartışma vardı, buna rağmen olduğu gibi birleştirildi.
    Kullanıcı iş akışlarını bozup bunu isteğe bağlı hale bile getirmemek, opt-in bir yana kapatılabilir bile yapmamak, kullanıcı deneyimini umursamazca yok saymak gibi görünüyor.

• Anladığımı özetlersem, yakın zamanda Emacs’te kopyalamadan biraz daha genel olan register işlemlerini değiştiren bir commit kabul edilmiş.
  Artık Emacs ne olup bittiğini gösteren bir minibuffer açıyor ve değişikliği Enter ya da buna karşılık gelen bir girişle onaylamanız gerekiyor. Asıl yazının yazarı bunu, varsayılan davranışı değiştirdiği, kolayca bir ayarla kapatılamayabileceği ve yeterince tartışılmadığı için korkunç bir uyumluluk kırılması olarak görüyor.
  Vim benzetmesiyle, geçerli satırı d register’ına kopyalamak için "dyy yazdığınızda, ardından bir scratch buffer açıp metni ve buffer’ı göstererek kapatmak için bir tuş girişi istemesi gibi. Register’ları anlayan tipik bir Vim kullanıcısı için berbat olurdu; ancak görsel modda kopyalayanlar gibi “neyin kopyalandığını açıkça gösteren” davranışı tercih edenler de olabilir.
  Yazının geri kalanı, asıl yazı yazarının tartışma başlatmaya çalıştığını ama commit’in yazarı Thierry’nin bunu engellediğini ve örtük olarak Emacs geliştirici topluluğunun geri kalanının da sorumluluk taşıdığını söylüyor.

  • Register’lar görece ileri seviye bir özellik ve çoğunlukla hızlı düzenleme için kullanılıyor. Fare kullanan ilk kez kullanıcıdan ziyade karmaşık işleri hızlıca klavyeyle yapan kişiler için.
    Emacs’i onlarca yıldır kullanıyorum ama register’lara derinlemesine girmedim; kişisel olarak kopyalama için kill/yank, karmaşık düzenlemeler için de çoklu imleçler ya da tek seferlik klavye makroları kullandım. Yine de Emacs’te kas hafızasına güvenmek isteyenler için çok sayıda isteğe bağlı gelişmiş düzenleme özelliği var.
    Buraya bir onay tuşu eklemek garip. Elektronik piyanoya “alışılmadık akoru onaylama pedalı” takmak gibi; hızlı ve karmaşık bir giriş eylemine bir adım daha ekliyor.
    Emacs’in mükemmel geri alma desteği var; dolayısıyla “d register’ındaki içeriği yapıştırayım mı?” diye sormak yerine doğrudan yapıştırıp, kullanıcı yanlış seçtiyse geri almasına izin vermek yeterli.
    Bu yüzden burada uyumluluğu kırmak garip; kapatma yolu da yoksa birçok kullanıcının kızması anlaşılır. Emacs modern GUI alışkanlıklarından daha eski bir araç, bu yüzden yeni kullanıcılara vscodium kadar tanıdık gelemez; bu nedenle power user’lara mümkün olduğunca iyi hizmet etme tarafının da ikna edici bir yanı var.
  • Emacs kullanmayanlar için şunu netleştirmek gerekiyor: standart kopyalama olan kill-ring-save, varsayılan M-w bundan etkilenmiyor; yalnızca daha gelişmiş bir özellik olan register’a kaydetme değişiyor.
    Register, pano yani kill ring’in bir üst kümesi değildir.
    Ayrıca bu değişikliğin yapılandırılamaz olacağını söyleyenler Emacs’in özelleştirilebilirliğini pek bilmiyor gibi. “Ayar” yalnızca kolaylık içindir; isterseniz kodun tamamını değiştirebilirsiniz. Bu, Emacs’in Elisp kısmı ve olduğu gibi girse bile birkaç dakika içinde davranışı değiştiren bir paket çıkar. Fork gerektiren bir şey değil; burada fork’tan bahsetmek olsa olsa performatif bir jest sayılır.
  • v30’da bu değişiklik gelirse epey can sıkıcı olacak gibi. Lisp’i hiç bilmiyorum ama öğeleri her zaman register’a kaydediyorum.
    Geri alınmazsa, ek tuş girişini benim yerime işleyecek bir makro parçası bulabilmeyi umuyorum. Emacs zaten basit işler için bile çok tuş girişi gerektiriyor; bu değişiklik için kendi makromu yapacak kadar uzman değilim.
  • Yazının özeti olarak fena değil, ama posta listesini de okuyunca sorunun özeti için yetersiz kalıyor.
    Görünüşe göre bu iş, Thierry’nin register davranışında birkaç sorun bulup düzeltmeye çalışmasıyla başladı.
    En önemli kusur, C-x r SPC ile save-to-register çalıştırıldıktan sonra basılan sonraki herhangi bir tuşun, o tuşa karşılık gelen register’a metni kaydetmesiydi. Özellikle Emacs’in evrensel iptal tuşu olan C-g bile burada çalışmıyor; bunun yerine metin ya da konum ^g adlı register’a kaydediliyordu. jump-to-register ya da insert-register yanlışlıkla çalıştırılsa bile C-g gibi bir şeyle iptal edilemiyor, mutlaka bir register seçmek gerekiyordu.
    İkincisi, register’lar metin, konum ya da boş değerlerden birini içerebilir. jump-to-register yalnızca konum içeren register’larda çalışır, insert-register ise metin bekler. Emacs komut çalıştırılırken boş olmayan register’ların önizlemesini sağlıyordu; ancak örneğin içinde string olan register’ları da jump-to-register adayı olarak gösteriyor, ayrım yapmıyordu.
    Thierry bu sorunları ve kod incelemesi geri bildirimlerini düzeltmeye çalıştı; incelemeciler de ek etkileşim doğsa bile bunun önemli bir değişiklik olduğunu düşündü. Normal bir register seçiminin ardından RET basmak ya da ^g gibi garip bir register’a kaydetmek için ek tuş kullanmak gibi uyumluluk kırılmalarını, elde edilen faydaya kıyasla kabul edilebilir gördüler.
    Asıl yazının yazarı yeni davranış ile eski davranış arasında geçiş yapan bir anahtar istedi ve kendisine yama göndermesi söylendi; ancak sunduğu yama, yukarıda bahsedilen iyileştirmelerin hepsini geri alıyor ve bambaşka bir özellik olan “boş olmayan register’ın üzerine yazmayı onaylama”yı bayrak tabanlı şekilde uyguluyordu. Thierry bunu uygulayıp denedi ve kısa bir geri bildirim verdi; yazar ise fiilen “buna gerek yok” diye yanıtladı.
    Sonrasında daha fazla kişi özelliği kullanınca, kırıcı değişikliğin etkisinin küçük olduğu yönündeki Thierry ve ilk incelemecilerin inancı yanlış çıktı; Thierry de yeni çalışmayı korurken eski akışa da izin veren bir bayrak oluşturmaya başladı. Özellikle fazladan RET gereksiniminin kaldırılması özden ziyade yan etkiye yakındı.
    Genel olarak süreç oldukça iyi işliyor gibi görünüyor; bağlamı yok sayıp “kabaca çalışıyorsa hiçbir şekilde değiştirilmemeli” şeklindeki anti-hacker bir tavırla tartışmayı zorlamaya çalışan taraf daha çok asıl yazının yazarı gibi duruyor.
  • Vim acemisi olarak dyy’nin geçerli satırı silmek anlamına geleceğini tahmin ederdim.
    Ama muhtemelen acemi olduğumun kanıtı da budur.

• Bu posta listesi başlığına bakılırsa ilgili davranışı geri alan bir seçenek eklenecek gibi görünüyor: https://yhetil.org/emacs/[e-mail]/#t
  Bu seçenek asıl yazı yayımlanmadan önce zaten anılmış gibi, ama yazar görmemiş olabilir. Bu sorunu çözecek gibi görünüyor; yine de gözden kaçırdığım bir şey olabilir.
  Düzeltme: Aşağıda ginko’nun yanıtına bakılırsa hâlâ RETURN tuşuna basmak gerekecek gibi.

  • Yine de register’ın üzerine yazmayı onaylamak için ek bir RET gerekiyor gibi görünüyor.
    https://yhetil.org/emacs/[e-mail]/
  • O başlığa bakınca register-use-previews bu davranışın toggle’ı gibi görünüyor.
    Ancak never olarak ayarlansa bile belirli iş akışlarında onayın çıktığı bir bug’dan söz ediliyor. Gerçekten bir seçenekse endişelerin çoğu çözülecek gibi.

• Emacs’te kas hafızası birinci sınıf bir mesele konumuna yükseltilmeli

  • Eskiden sevdiğim bir dosya yöneticisinin yeni sürümünün tuş bağlarını değiştirerek çıktığı olmuştu. Adını artık hatırlamıyorum ama o zaman hissettiğim öfke, o anda bile aşırı olduğunu düşündürecek kadar aklımda kaldı.
    Çünkü biriktirdiğim kas hafızası bozulmuştu. Sakinleşene kadar epey kötü niyetli düşünceler de geçirdim. Önemsiz görünebilir ama “kas hafızasına ihanet” suçuna verilen tepkinin “fork you” noktasına kadar büyümesinin nedenini anlayabiliyorum.
  • Bu yalnızca Emacs’e özgü değil. Emacs’le hiç ilgilenmiyorum ama bu hikâyenin önemli olmasının nedeni, insanların yerleşik beklentilerini dikkate almadan bir şeyleri “iyileştirmeye” kalkışan geliştiricilerin kibrini göstermesi.
    Bu, Emacs için olduğu kadar Google Maps veya iOS için de aynı şekilde geçerli.
  • Daha genel olarak, sık kullanılan yazılımlar kas hafızasına yerleşebilir olacak şekilde yapılmalı ve sonraki sürümlerde haklı bir neden olmadan bu bozulmamalı.
    Kas hafızası, her küçük etkileşimde görsel olarak kontrol etmek zorunda kalmadan, yazılımı “bakmadan” yarı asenkron biçimde kullanmayı sağlar. Ne yazık ki masaüstü yazılımlarında klavye kullanımını giderek daha zahmetli hâle getiren ya da tamamen imkânsızlaştıran bir eğilim var.
  • En azından kas hafızasını bozan geçişler, varsayılanı “ayarlarımı eskisi gibi koru” olan bir toggle olmalı.

• İyi bir rant, ama ele aldığı özelliğin gerçekte ne olduğunu açıklamaması ikna ediciliğe yardımcı olmuyor.
  Emacs register’ları çok eski bir soyutlama. Register’lara ayrı bir pano gibi değer koyup geri alabilirsiniz; temel ASCII sembolleri [a-zA-Z0-9] ile ilişkilendirilmiş 62 tane oldukları için esnek ve hızlı bir klavye arayüzü sunarlar. Register’dan klavye makrosu çalıştırmak gibi eğlenceli şeyler de mümkündür. Bunları çok kullananlar var ama ben şahsen kullanmıyorum.
  Yazarın kızmasının nedeni, varsayılan bağlamanın değişmesi ve eskiden tamamen klavye ve home row ile yapılan bir işin önüne modal UI sokulması. Makul bir şikâyet gibi geliyor; benim kas hafızama işlemiş bir özellik böyle değiştirilseydi ben de sinirlenirdim.

  • Uzun zaman önce Emacs’i bırakmış olsam da X11 selection buffer’a, yani orta tıkla yapıştırmaya çok bağımlı olduğum için empati kurabiliyorum.
    Seçme ile yapıştırma arasına her seferinde onay isteyen modal bir diyalog girse ve eski davranışa dönmek için bir ayar da olmasa kesinlikle öfkelenirdim. Eski davranışı seçenek olarak uygulamak yeterli. Kelimenin tam anlamıyla birkaç satır kodla yapılabilir.
  • Register’lar 62’den fazla. Şikâyetlerden biri, minibuffer’ın örneğin C-a register erişimini bozması.
    Tanıdığım biri konumlar için harfleri, metin için C-harf kullanıyor. Birileri için çok uç bir durum olabilir ama bu kişilerin çok öfkeleneceğini düşünüyorum.
  • Eli bunu varsayılan davranış olarak sabitlemeye çalışıyor gibi görünmüyor. Ben de hayranı değilim.
    https://yhetil.org/emacs/[e-mail]/ adresinde Eli, “itiraz geldiğine göre davranışın ne olması gerektiğini tartışmaya devam ediyoruz; sonuca vardığımızda varsayılanı konuşabiliriz” diyor.
  • “Varsayılan bağlama” deyince farklı şekilde ayarlanabiliyormuş gibi geliyor; gerçekten mümkün mü?
  • Fiilen kapatılamayan küresel uac-mode’u tüm buffer’larda açmak gibi. Doğru değilse gülüp geçilecek bir şey.

• Orijinal yazı yazarının yorumu iyi değil. Kararlılık isteyen kullanıcılar release branch’te olmalı ya da master’daki commit’i sabitlemeli.
  Geliştirme branch’inin, devam eden özelliklerin geliştirilmesi için kullanılması beklenmeli; bu tür özelliklerin cilalanması zaman alabilir. master’ı takip ediyorsanız sık sık uyumluluğu bozan değişikliklerle karşılaşırsınız ve iş akışınızı bozan bir şey olduğunda önceki commit’e dönmeye alışkın olmanız gerekir. Daha iyi seçenek release’te kalmaktır.

• Emacs’in özü, aşırı derecede özelleştirilebilir bir platform olması; bir özelliğin davranışını beğenmiyorsanız birkaç satır Lisp ile kendiniz düzeltebilirsiniz.
  Obscure bir özellik değişikliği yüzünden tüm projeyi fork’lamak hiç mantıklı değil. TECO makrolarıyla uygulandığı dönemlerden, yaklaşık 1981’den beri Emacs kullanıyorum ama register kullanmıyorum.

  • Aşırı özelleştirilebilir bir platform olabilmesi için platformun kendisinin çok kararlı olması gerekir.
    Aksi hâlde platform her değiştiğinde herkesin tüm özelleştirmelerini yeniden yazması ya da düzeltmesi gerekir.
  • “Kendin düzeltmek” ile “fork” arasındaki farkın ne olduğunu bilmiyorum.
    Bu patch aynen kalır ve biri tam olarak eski şekilde kullanmak isterse, fiilen Emacs’in yerel deposuna geri alma patch’i uygulayıp kendi değişikliklerini bunun üzerine koymak zorunda kalır. Upstream Emacs değiştikçe yeni değişiklikleri almak için rebase yapmak gerekir.
    Bu bir özel forktur. Sonsuza kadar fork’lu kalıp sonsuza kadar rebase etmektir.
    Kabaca, shipped dosya yerine ya da arkasından kendi dosyanızı yükleyip fonksiyonu yeniden tanımlayan bir monkey patch de yapabilirsiniz; ama bu da bir tür fork’tur. Malzemeyi bir proje olarak bir yerde saklamanız ve değişiklikler monkey patch’i bozduğunda uyarlamaya hazır olmanız gerekir.
  • Görünüşe göre bu değişikliğin herhangi bir ayarla eski davranışa geri dönebilme imkânı içermediği kısmını kaçırmışsınız.

• Emacs’ten ayrılalı 20 yıl oldu ama bu değişikliğin epey yıkıcı olduğunu anlıyorum.
  Anlamadığım şey, “mutfak lavabosuna kadar her şey var” diye övünen Emacs’in neden eski davranışa dönme seçeneği eklemediği.

  • Muhtemelen o seçeneği ekleyecekler. Orijinal yazının yazarı sadece kendi patch’i kabul edilmediği için kızgın.
    O patch bir flag ekliyordu ama diğer tüm iyileştirmeleri de ortadan kaldırıyordu.

• Yazının tonu epey “neckbeard” havasında. Üç nerd’ün kullandığı son derece obscure bir özellik; Kutsal Kabir Kilisesi’ndeki yerinden oynatılamayan merdiven değil.
  Ücretsiz çalışan bir maintainer’ın size önceden sormadan biraz değiştirmesi, mutlaka “master’ı bozdu” anlamına gelmez. Burada söz konusu olan kararlı sürüm ya da tag’lenmiş release değil, master.

• Elbette mümkün olan tek çözüm, bir başka Emacs fork’u ya da yeniden uygulaması denemek.
  Bu seferki kesinlikle başarılı olacak ve diğerleri gibi tamamen alakasız bir varlığa dönüşmeyecek.

  • Bu tür fork’ların etkisi, ana proje etrafındaki topluluğun yavaş yavaş aşınmasıdır.
    Ancak fork’un ana projeyi pazarlık masasına çekip çekmemesi pek önemli değil. Orijinal yazının yazarı o patch’i kendi yerel deposunda sonuna kadar taşıyıp sürdürme yeteneğine ve isteğine sahip. Fork’u tamamlamak için eksik olan tek şey, o yerel depoyu herkese açmak.
  • Blog yazısından bakınca yazarın fork konusunda uzun vadede nasıl bir niyeti olduğunu pek anlayamıyorum.
    Belki de mainline maintainer’larını ikna etmeye yöneliktir.