Kabar Buruk, Emacs

• Ini semula adalah tulisan kritik terhadap perubahan pada fitur registers di Emacs 30, tetapi pada teks publik saat ini naskah aslinya sudah diturunkan
• Teks asli dihapus karena membahas perkembangan Emacs terbaru secara terlalu kritis dan tidak ramah terhadap orang-orang terkait
• Hanya tersisa petunjuk bahwa jika ingin memeriksa konten yang dihapus, silakan cari log Git di situs web penulis
• Inti yang masih tersisa adalah bahwa penulis mulai memakai branch Emacs yang sedikit berbeda untuk penggunaan sehari-hari
• Dari teks publik yang ada sekarang, sulit memastikan perubahan spesifik atau isu teknis pada fitur registers Emacs 30

---

Tulisan kritik Emacs 30 yang telah diturunkan

• Teks asli adalah tulisan yang membahas perubahan pada fitur registers di Emacs 30 yang dianggap memburuk
• Pada teks publik, masih ada alasan penghapusan bahwa tulisan aslinya terlalu berlebihan dalam mengkritik perkembangan Emacs terbaru dan tidak ramah terhadap orang-orang yang terkait
• Disebutkan juga bahwa tulisan itu menerima perhatian jauh lebih besar dibandingkan tulisan blog sebelumnya, yang turut disebut sebagai latar belakang penghapusan

Informasi yang saat ini bisa dikonfirmasi

• Jika benar-benar ingin membaca tulisan yang dihapus, Anda bisa memeriksa log Git dari situs web ini
• Penulis menyatakan mulai menggunakan branch Emacs yang sedikit berbeda untuk penggunaan sehari-hari
• Teks publik yang tersedia saat ini tidak memuat masalah spesifik, contoh, maupun isi patch terkait perubahan fitur registers di Emacs 30

[GN⁺]

Komentar Hacker News

• Jika di branch pengembangan Emacs masuk perubahan yang merusak kompatibilitas, disengaja ataupun tidak, lalu sebagian pengguna menyampaikan kekhawatiran, prosesnya tidak berjalan dengan langsung membatalkannya saat itu juga.
  Perlu ada proses mendiskusikan kelebihan dan kekurangannya, mengimplementasikan dan memperbaiki beberapa solusi, lalu mencari titik kompromi. Baru tiga hari sejak pengguna mengajukan kekhawatiran, jadi sulit mengatakan bahwa proses ini seharusnya sudah selesai.
  Jawaban terbaru Eli juga pada intinya adalah, “dua orang yang ikut dalam diskusi awal menganggap perilaku baru jauh lebih masuk akal daripada perilaku lama, tetapi sekarang ada pendapat yang menentang juga, jadi kita bisa terus mendiskusikan perilakunya lalu setelah itu membicarakan nilai default.”
  Saya memang melihat ada masalah serius dalam cara pengembangan Emacs, tetapi juga bermasalah jika pengguna biasanya menyalahkan orang-orang keras kepala di emacs-devel, lalu ketika ada perubahan yang tidak mereka sukai, bertindak seolah dunia akan kiamat. Itu membuat maintainer menjadi defensif.

  • Menggunakan branch pengembangan lalu ribut karena muncul perubahan yang merusak kompatibilitas itu tidak tepat. Di branch pengembangan, hal seperti itu bisa diperkirakan terjadi.
    Jika membaca thread emailnya, ini lebih terlihat seperti perbedaan pendapat yang kuat daripada “kesombongan”, dan mencapai konsensus memang pasti butuh waktu. Menyebut seseorang secara publik “sombong” hanya karena ia tidak langsung mundur sesuai sudut pandang sendiri, lalu mencoba menarik massa yang bahkan tidak akan membaca thread tersebut, terlihat hampir seperti perundungan.
    Selain itu, klaim bahwa patch yang menjadikan perubahan itu opsional diabaikan juga tidak jujur. Patch tersebut bukan hanya menambahkan opsi, tetapi juga menghapus perubahan lain, sehingga ditolak; dan sulit menerima cara menyalahkan satu orang seperti itu.
  • Mengatakan bahwa “reaksi pengguna adalah masukan utama dalam keputusan akhir”, tetapi pada saat yang sama mengkritik reaksi negatif pengguna sebagai “berlebihan”, terlihat kontradiktif.
    Jika pengguna tidak bereaksi, berdasarkan prosedur yang dijelaskan, besar kemungkinan perubahan awal yang mereka tentang akan masuk begitu saja. Di clojure-mode juga, rms mencoba mengambil nama penulis dari komunitas Clojure yang sudah lama dipertahankan dan menulis ulangnya; hal itu tertahan karena orang-orang memprotes di milis, tetapi justru orang-orang itu dibilang berlebihan. Karena itu, kritik “berlebihan” tidak terlihat terlalu bermakna.
  • Ini adalah prosedur yang buruk. Peninjauan fitur seharusnya dimulai sebelum digabungkan ke branch utama, bukan setelahnya.
    Jika fitur yang merusak alur kerja pengguna dimasukkan ke branch utama tanpa diskusi dengan komunitas yang lebih luas, wajar saja orang-orang marah. Penggabungan seperti ini adalah cara sebuah alat lama kehilangan dukungan komunitas.
  • Komunitas Emacs, setidaknya secara historis, sangat kuat menekankan kompatibilitas ke belakang. Merusak pengguna lama hampir merupakan salah satu hal terburuk di Emacs.
    Jika mereka tidak sungguh-sungguh mempertimbangkan untuk segera membatalkan perubahan yang merusak kompatibilitas, itu menjadi sinyal bahwa para pengembang Emacs tidak lagi menempatkan kompatibilitas ke belakang setinggi dulu, dan itu berarti meninggalkan cukup banyak pengguna lama.
    https://www.murilopereira.com/the-values-of-emacs-the-neovim...
    Nilai inti itu penting. Para maintainer Emacs telah melanggar nilai inti, dan wajar jika komunitas merasa tidak senang.
  • Jika mengikuti penjelasan tulisan tersebut, kondisi kesehatan Emacs mengkhawatirkan. Sudah ada kontroversi bahkan sebelum digabungkan ke master, tetapi tetap saja digabungkan.
    Merusak alur kerja pengguna tanpa menjadikannya opsional, bahkan bukan opt-in dan tidak bisa dimatikan sama sekali, terlihat seperti pengabaian yang ceroboh terhadap pengalaman pengguna.

• Jika diringkas dari apa yang saya pahami, baru-baru ini sebuah commit yang mengubah perilaku register—mekanisme yang sedikit lebih umum daripada copy—diterima di Emacs
  Sekarang Emacs membuka minibuffer yang menunjukkan apa yang terjadi, dan perubahan harus disetujui dengan Enter atau input yang setara. Penulis artikel asli menganggap ini sebagai pemutusan kompatibilitas yang mengerikan karena mengubah perilaku default, mungkin tidak bisa dimatikan dengan mudah lewat konfigurasi, dan tidak dibahas secara memadai
  Jika dianalogikan dengan Vim, ini seperti ketika mengetik "dyy untuk menyalin baris saat ini ke register d, lalu setelah itu membuka buffer scratch untuk menampilkan teks dan buffer, serta meminta input tombol untuk menutupnya. Bagi pengguna Vim umum yang memahami register, ini mengerikan, meski memang ada juga orang yang lebih menyukai perilaku yang “menunjukkan secara eksplisit apa yang disalin”, seperti mereka yang menyalin dari visual mode
  Sisa tulisannya berisi bahwa penulis asli mencoba memicu diskusi, tetapi dihalangi oleh Thierry, penulis commit tersebut, dan secara implisit komunitas pengembang Emacs lainnya juga ikut bertanggung jawab

  • Register adalah fitur yang relatif tingkat lanjut dan terutama dipakai untuk pengeditan cepat. Ini lebih ditujukan bagi orang yang mengetik operasi rumit dengan cepat daripada pengguna pertama yang memakai mouse
    Saya sudah memakai Emacs selama puluhan tahun, tetapi tidak pernah mendalami register; secara pribadi saya memakai kill/yank untuk copy, dan multi-cursor atau macro keyboard sekali pakai untuk pengeditan rumit. Meski begitu, Emacs punya banyak fitur pengeditan tingkat lanjut opsional untuk orang yang ingin mengandalkan muscle memory
    Menambahkan input tombol konfirmasi di sini terasa aneh. Ini mirip seperti memasang “pedal konfirmasi chord yang tidak biasa” pada piano elektrik: menambahkan satu langkah lagi pada rangkaian input yang cepat dan kompleks
    Emacs punya undo yang sangat bagus, jadi alih-alih bertanya “Apakah Anda ingin menempelkan isi register d?”, cukup tempelkan saja, lalu biarkan pengguna membatalkannya jika salah memilih
    Karena itu, memutus kompatibilitas di sini terasa aneh, dan jika tidak ada cara untuk mematikannya, wajar banyak pengguna akan marah. Emacs adalah alat yang lebih tua daripada konvensi GUI modern, jadi tidak mungkin terasa seakrab vscodium bagi pengguna baru; karena itu, ada alasan kuat juga untuk melayani power user sebaik mungkin
  • Bagi orang yang tidak memakai Emacs, perlu diperjelas bahwa copy standar, yaitu kill-ring-save dengan default M-w, tidak terdampak; yang berubah hanya penyimpanan register, fitur yang lebih lanjut
    Register bukan superset dari clipboard, alias kill ring
    Selain itu, orang yang mengatakan perubahan ini tidak akan bisa dikonfigurasi tampaknya tidak begitu memahami kemampuan kustomisasi Emacs. “Konfigurasi” hanyalah fasilitas kemudahan; jika mau, Anda bisa mengganti seluruh kodenya. Ini adalah bagian Elisp dari Emacs, dan sekalipun masuk apa adanya, dalam beberapa menit pasti akan muncul paket yang mengubah perilakunya. Ini bukan sesuatu yang membutuhkan fork, dan pembicaraan soal fork di sini paling banter hanya gestur performatif
  • Kalau perubahan ini masuk di v30, rasanya akan cukup menyebalkan. Saya sama sekali tidak tahu Lisp, tetapi selalu menyimpan item ke register
    Jika tidak dibatalkan, saya berharap bisa menemukan potongan macro yang menangani input tombol tambahan itu untuk saya. Emacs sudah membutuhkan banyak input tombol bahkan untuk hal sederhana, dan saya bukan ahli sampai bisa membuat sendiri macro untuk perubahan ini
  • Sebagai ringkasan tulisan, ini cukup baik, tetapi kalau melihat sampai mailing list, ini kurang memadai sebagai ringkasan masalah
    Tampaknya hal ini bermula ketika Thierry menemukan beberapa masalah dalam perilaku register dan mencoba memperbaikinya
    Cacat terpentingnya adalah setelah menekan C-x r SPC untuk save-to-register, tombol apa pun yang ditekan berikutnya akan menyimpan teks ke register yang sesuai dengan tombol itu. Secara khusus, C-g, tombol pembatalan universal Emacs, juga tidak berfungsi di sini, dan teks atau posisi justru disimpan ke register bernama ^g. Jika tidak sengaja menekan jump-to-register atau insert-register, Anda juga tidak bisa membatalkannya dengan C-g dan sejenisnya; Anda harus memilih register
    Kedua, register bisa berisi teks, posisi, atau nilai kosong. jump-to-register hanya bekerja pada register yang berisi posisi, sedangkan insert-register mengharapkan teks. Emacs menyediakan pratinjau register yang tidak kosong saat menjalankan perintah, tetapi tidak membedakannya; misalnya register berisi string juga ditampilkan sebagai kandidat untuk jump-to-register
    Thierry mencoba memperbaiki masalah-masalah ini beserta masukan code review, dan para reviewer menganggapnya perubahan penting meskipun menambah interaksi. Mereka menilai pemutusan kompatibilitas seperti harus menekan RET setelah memilih register biasa, atau harus memakai tombol tambahan untuk menyimpan ke register aneh seperti ^g, masih layak dibanding manfaat yang diperoleh
    Penulis asli meminta switch untuk beralih antara perilaku baru dan lama, lalu diminta mengirim patch, tetapi patch yang ia ajukan mengembalikan semua perbaikan yang disebutkan di atas dan mengimplementasikan fitur yang sama sekali berbeda—“konfirmasi menimpa register yang tidak kosong”—berbasis flag. Thierry mencobanya dan memberi masukan sederhana, lalu penulis pada dasarnya menjawab “itu tidak perlu”
    Setelah itu, ketika lebih banyak orang memakai fitur tersebut, keyakinan Thierry dan para reviewer awal bahwa dampak breaking change ini kecil ternyata keliru, dan Thierry mulai membuat flag yang mempertahankan pekerjaan baru sambil tetap mengizinkan alur lama. Khususnya, penghapusan RET tambahan bukan inti masalah, melainkan lebih seperti efek samping
    Secara keseluruhan, prosesnya tampak berjalan cukup baik, dan pihak yang lebih dekat dengan sikap anti-hacker yang mengabaikan konteks serta mencoba mendorong diskusi dengan prinsip “kalau kira-kira berjalan, jangan pernah diubah dengan cara apa pun” justru tampaknya penulis asli
  • Dari sudut pandang pemula Vim, saya mungkin akan mengira dyy berarti menghapus baris saat ini
    Tapi mungkin justru itu bukti bahwa saya pemula

• Melihat thread mailing list ini, tampaknya akan ada opsi untuk mengembalikan perilaku tersebut: https://yhetil.org/emacs/[e-mail]/#t
  Opsi ini tampaknya sudah disebut sebelum tulisan asli dipublikasikan, tetapi mungkin penulisnya tidak melihatnya. Sepertinya ini akan menyelesaikan masalah, meski mungkin ada bagian yang terlewat
  Sunting: melihat jawaban ginko di bawah, tampaknya input tombol RETURN tetap masih diperlukan

  • Meski begitu, tampaknya RET tambahan tetap diperlukan untuk mengonfirmasi penimpaan register
    https://yhetil.org/emacs/[e-mail]/
  • Dari thread itu, register-use-previews tampaknya seperti toggle untuk perilaku ini
    Namun disebutkan ada bug bahwa konfirmasi tetap muncul dalam alur kerja tertentu meskipun disetel ke never. Kalau ini benar-benar opsi, sepertinya sebagian besar kekhawatiran akan teratasi

• Di Emacs, memori otot harus dinaikkan menjadi perhatian kelas satu

  • Dulu pernah ada versi baru dari manajer berkas yang saya sukai yang mengubah key binding. Sekarang namanya saja sudah tidak ingat, tetapi amarah yang saya rasakan saat itu masih melekat sampai-sampai bahkan waktu itu pun terasa berlebihan
    Karena memori otot yang sudah terbentuk jadi rusak. Sebelum tenang, saya juga sempat punya pikiran yang cukup jahat. Ini mungkin tampak sepele, tetapi saya bisa memahami mengapa reaksi terhadap kejahatan “mengkhianati memori otot” bisa membesar sampai “fork you”
  • Ini bukan cuma masalah Emacs. Saya sama sekali tidak peduli pada Emacs, tetapi cerita ini penting karena menunjukkan keangkuhan para pengembang yang mencoba “memperbaiki” sesuatu tanpa mempertimbangkan ekspektasi stabil orang-orang
    Ini berlaku sama persis untuk Google Maps atau iOS seperti halnya untuk Emacs
  • Secara lebih umum, perangkat lunak yang sering dipakai harus dibuat agar memungkinkan pembentukan memori otot, dan tidak boleh merusaknya di versi berikutnya tanpa alasan yang sah
    Memori otot memungkinkan kita mengoperasikan perangkat lunak secara semi-asinkron “tanpa melihat”, tanpa harus memeriksa secara visual setiap interaksi kecil. Sayangnya, di perangkat lunak desktop ada tren yang membuat pengoperasian dengan keyboard makin merepotkan, atau bahkan sama sekali mustahil
  • Minimal, transisi yang merusak memori otot harus berupa toggle dengan default “pertahankan pengaturan saya seperti dulu”

• Ini memang rant yang bagus, tetapi tidak menjelaskan fitur apa yang sebenarnya dibahas, dan itu tidak membantu meyakinkan pembaca
  Register Emacs adalah abstraksi yang sangat lama. Register bisa dipakai untuk memasukkan dan mengambil nilai seperti clipboard terpisah, dan ada 62 register yang terhubung ke simbol ASCII inti [a-zA-Z0-9], sehingga menyediakan antarmuka keyboard yang fleksibel dan cepat. Hal menarik seperti menjalankan makro keyboard dari register juga bisa dilakukan. Ada orang yang banyak menggunakannya, tetapi secara pribadi saya tidak
  Alasan penulis marah adalah karena binding default berubah, sehingga UI modal kini menyela di depan pekerjaan yang dulu bisa dilakukan sepenuhnya hanya dengan keyboard dan home row. Keluhannya terdengar masuk akal, dan kalau fitur yang tertanam dalam memori otot saya berubah seperti ini, saya juga mungkin akan kesal

  • Saya sudah lama berhenti memakai Emacs, tetapi saya sangat bergantung pada buffer seleksi X11, yaitu paste dengan klik tengah, jadi saya bisa berempati
    Kalau setiap kali antara seleksi dan paste ada dialog modal konfirmasi yang menyela, dan tidak ada pengaturan untuk mengembalikan perilaku lama, jelas saya akan marah. Cukup implementasikan perilaku lama sebagai opsi. Secara harfiah bisa dilakukan dengan beberapa baris kode
  • Register jumlahnya lebih dari 62. Salah satu keluhannya adalah minibuffer mematahkan akses register seperti C-a
    Saya kenal orang yang memakai huruf untuk posisi, dan C-huruf untuk teks. Bagi sebagian orang itu mungkin kasus yang sangat aneh, tetapi orang-orang seperti itu tampaknya akan sangat marah
  • Eli tampaknya tidak berniat mengunci ini sebagai perilaku default. Saya juga bukan penggemarnya
    Di https://yhetil.org/emacs/[e-mail]/, Eli berkata, “karena ada keberatan, kita masih mendiskusikan perilaku seperti apa yang seharusnya, dan setelah ada kesimpulan barulah kita bisa membicarakan default”
  • Kalau disebut “binding default”, terdengar seolah bisa dikonfigurasi berbeda, tetapi apakah memang bisa?
  • Ini praktis seperti menyalakan uac-mode global yang tidak bisa dimatikan di semua buffer. Kalau itu tidak benar, ya tinggal ditertawakan saja

• Interpretasi penulis artikel asli kurang baik. Pengguna yang menginginkan stabilitas seharusnya berada di branch rilis atau mematok commit tertentu dari master
  Branch pengembangan harus dipahami sebagai tempat pengembangan fitur yang masih berjalan, dan fitur seperti ini bisa memerlukan waktu untuk dipoles. Kalau mengikuti master, Anda akan sering menemui perubahan yang mematahkan kompatibilitas, dan ketika itu mengganggu alur kerja, Anda harus terbiasa kembali ke commit sebelumnya. Pilihan yang lebih baik adalah tetap di rilis

• Inti Emacs adalah bahwa ia merupakan platform yang sangat bisa dikustomisasi, jadi kalau Anda tidak suka perilaku suatu fitur, Anda bisa memperbaikinya sendiri dengan beberapa baris Lisp
  Mem-fork seluruh proyek karena perubahan pada satu fitur obscure sama sekali tidak masuk akal. Saya sudah memakai Emacs kira-kira sejak 1981, ketika masih diimplementasikan dengan makro TECO, tetapi saya tidak memakai register

  • Untuk menjadi platform yang sangat bisa dikustomisasi, platform itu sendiri harus sangat stabil
    Kalau tidak, setiap kali platform berubah, semua orang harus menulis ulang atau memperbaiki semua kustomisasi mereka setiap saat
  • Saya tidak tahu apa bedanya “memperbaiki sendiri” dan “fork”
    Jika patch ini tetap seperti sekarang dan seseorang ingin memakainya persis seperti cara lama, pada dasarnya ia harus menerapkan patch revert ke repositori lokal Emacs lalu menumpuk perubahan pribadinya di atasnya. Setiap kali upstream Emacs berubah, ia harus melakukan rebase untuk mengambil perubahan baru
    Itu adalah fork privat. Selamanya tetap ter-fork dan selamanya melakukan rebase
    Bisa saja kira-kira memakai monkey patch dengan memuat berkas sendiri sebagai pengganti atau setelah berkas shipped untuk mendefinisikan ulang fungsi, tetapi itu juga semacam fork. Materinya harus disimpan di suatu tempat sebagai proyek, dan harus siap menyesuaikan ketika perubahan membuat monkey patch rusak
  • Sepertinya terlewat bahwa perubahan ini tidak menyertakan fitur untuk mengembalikan perilaku lama lewat pengaturan apa pun

• Saya sudah meninggalkan Emacs 20 tahun lalu, tetapi saya mengerti bahwa perubahan ini cukup merusak
  Yang tidak saya mengerti adalah mengapa Emacs, yang bangga punya “semuanya sampai kitchen sink”, tidak menambahkan opsi untuk mengembalikan perilaku lama

  • Kemungkinan besar opsi itu akan ditambahkan. Penulis asli hanya marah karena patch miliknya tidak diterima
    Patch itu memang menambahkan flag, tetapi juga menghapus semua peningkatan lainnya

• Nada tulisannya terasa sangat “neckbeard”. Ini fitur yang sangat obscure yang hanya dipakai tiga nerd, bukan tangga tak bergerak di Gereja Makam Kudus
  Hanya karena maintainer tak berbayar mengubahnya sedikit tanpa bertanya lebih dulu kepada Anda, bukan berarti ia pasti “merusak master”. Yang sedang dibicarakan ini adalah master, bukan stable atau rilis bertag

• Tentu saja satu-satunya solusi yang mungkin adalah mencoba fork atau reimplementasi Emacs lainnya
  Yang kali ini pasti berhasil, dan tidak akan menjadi sesuatu yang sama sekali tidak relevan seperti yang lain-lain

  • Dampak fork seperti ini adalah komunitas di sekitar proyek utama perlahan terkikis
    Namun, apakah fork itu berhasil membawa proyek utama ke meja negosiasi tidak terlalu penting. Penulis asli punya kemampuan dan kemauan untuk mempertahankan patch itu di repositori lokalnya sampai akhir. Satu-satunya hal yang kurang untuk menyelesaikan fork adalah memublikasikan repositori lokal itu
  • Dari tulisan blog saja, sulit mengetahui apa niat jangka panjang penulis terhadap fork tersebut
    Mungkin saja tujuannya untuk meyakinkan maintainer mainline