悪い知らせ、Emacs
(eshelyaron.com)- Emacs 30のregisters機能の変化に対する批判文だったが、現在公開されている本文では原文が取り下げられた状態になっている
- 原文は最近のEmacs開発を過度に批判的に扱い、関係する個人に不親切だったことを理由に削除された
- 削除された内容を確認したいなら、著者のWebサイトのGitログを探すよう案内だけが残っている
- 残っている核心は、著者がEmacsのやや異なるブランチ(branch) を日常用として使い始めたという点である
- 現在公開されている本文だけでは、Emacs 30のregisters機能の具体的な変更点や技術的争点を確認しにくい
取り下げられたEmacs 30批判文
- 原文はEmacs 30のregisters機能で悪化したと見なした変化を扱った文章だった
- 公開本文には、元の文章が最近のEmacs開発を過度に批判し、関係者に不親切だったという削除理由が残っている
- 以前のブログ記事よりはるかに多くの関心を集めた点も、削除の背景として言及されている
現在確認できる情報
- 削除された文章をどうしても読みたいなら、このWebサイトのGitログを確認できる
- 著者はEmacsのやや異なるbranchを日常用として使い始めたと明かしている
- 現在公開されている本文には、Emacs 30のregisters機能変更に関する具体的な問題、事例、パッチ内容は含まれていない
1件のコメント
Hacker News の意見
Emacs の開発ブランチに、意図したかどうかにかかわらず互換性を壊す変更が入り、一部ユーザーが懸念を示したとしても、それを即座に差し戻す形で進むわけではありません
長所と短所を議論し、複数の解決策を実装・改善したうえで、妥協点を探るプロセスが必要です。ユーザーが懸念を提起してからまだ3日しか経っていないので、このプロセスがすでに終わっているべきだったとは言いにくいです
Eli の最近の返信も、「最初に議論に参加した2人は新しい挙動のほうが従来の挙動よりはるかに妥当だと見ていたが、今は反対意見も出てきたので、挙動について引き続き議論し、その後でデフォルト値について話せる」という趣旨でした
Emacs の開発方式には深刻な問題があると思いますが、ユーザーが普段は emacs-devel の頑固な人たちを責めておきながら、自分の嫌いな変更が入ると世界の終わりのように振る舞うのも問題です。そうなるとメンテナーは防御的になってしまいます
メールスレッドを読むと、「傲慢さ」というよりは強い意見の相違に見え、合意にはどうしても時間がかかります。自分の見方に沿って即座に引き下がらないからといって、誰かを公に「傲慢だ」と呼び、そのスレッドを読むこともない群衆を巻き込もうとするのは、嫌がらせに近いように見えます
また、その変更を選択可能にするパッチが無視されたという言い方も誠実ではありません。そのパッチは選択肢を追加しただけでなく、別の変更まで削除していたため拒否されたのであり、そのように1人に責任を押しつけるのも受け入れがたいです
ユーザーが反応しなければ、説明されている手続き上、彼らが反対した元の変更がそのまま入っていた可能性が高いです。clojure-mode でも、rms が長年維持してきた Clojure コミュニティの作者名を持っていって書き換えようとし、人々がメーリングリストで抗議して止められましたが、当の人々は大げさだと言われました。なので、「大げさだ」という批判にはあまり意味があるように見えません
広いコミュニティと議論せずに、ユーザーのフローを壊す機能をメインブランチに入れれば、人々が怒るのは当然です。このようなマージは、古いツールがコミュニティの支持を失っていくやり方です
互換性を壊す変更を即座に差し戻すことを強く検討しないのであれば、Emacs 開発者がもはや以前ほど後方互換性を重視していないというシグナルになり、それは既存ユーザーのかなりの部分を切り捨てることを意味します
https://www.murilopereira.com/the-values-of-emacs-the-neovim...
核となる価値は重要です。Emacs のメンテナーは核となる価値を破り、コミュニティが不快に思うのは正当です
ユーザーのワークフローを壊しながら選択可能にもせず、opt-in どころかオフにすることさえできないようにしたのは、ユーザー体験を無頓着に無視したものに見えます
理解した内容を要約すると、最近 Emacs でコピーよりもう少し一般的な レジスター の動作を変更するコミットが受け入れられた、ということ。
これから Emacs は、何が起きているかを示すミニバッファを開き、Enter またはそれに相当する入力で変更を承認しなければならない。元記事の筆者は、デフォルト動作を変えており、簡単に設定で無効化できない可能性があり、十分な議論もなかった点から、ひどい互換性破壊だと見ている。
Vim にたとえると、現在行を
dレジスターにコピーしようとして"dyyと入力したとき、その後 scratch バッファを開いてテキストとバッファを表示し、閉じるためにキー入力を要求するようなもの。レジスターを理解している一般的な Vim ユーザーにとってはひどいが、ビジュアルモードでコピーする人たちのように「何がコピーされるのかを明示的に見せる」動作を好む場合も一応ある。記事の残りは、元記事の筆者が議論を起こそうとしたが、コミット作者の Thierry がそれを阻み、暗黙のうちに Emacs 開発コミュニティの残りのメンバーにも責任がある、という内容。
Emacs を何十年も使ってきたが、レジスターに深く入り込んだことはなく、個人的にはコピーには kill/yank を使い、複雑な編集にはマルチカーソルや使い捨てのキーボードマクロを使っていた。それでも Emacs には、筋肉記憶に頼りたい人のための選択的な高度編集機能が多くある。
ここに確認のキー入力を追加するのは奇妙だ。電子ピアノに「特殊コード確認ペダル」を付けるようなもので、高速で複雑な入力操作にさらに一段階を載せることになる。
Emacs には優れた undo があるので、「レジスター d の中身を貼り付けますか？」と尋ねるより、そのまま貼り付けて、ユーザーが間違って選んでいたら戻せるようにすればよい。
したがって、ここで互換性を壊すのは奇妙で、無効にする方法もないなら多くのユーザーが怒るのも当然。Emacs は現代的な GUI の慣習より古いツールなので、vscodium ほど新規ユーザーに親しみやすくはなれない以上、パワーユーザーにできるだけよく奉仕する方向にも説得力がある。
kill-ring-save、デフォルトではM-wは影響を受けず、より高度な機能である レジスターへの保存 だけが変わる、という点を明確にすべき。レジスターはクリップボード、つまり kill ring の上位集合ではない。
また、この変更が設定不能になるだろうと言っている人たちは、Emacs のカスタマイズ性をよく知らないように見える。「設定」は利便性のためのものにすぎず、望むならコードを丸ごと変えられる。これは Emacs の Elisp 部分であり、そのまま入ったとしても数分以内に動作を変えるパッケージが出てくるだろう。フォークが必要な話ではなく、ここでフォークを語るのはせいぜいパフォーマティブなジェスチャーに近い。
戻されないなら、追加のキー入力を代わりに処理してくれる マクロ片 を見つけられることを願う。Emacs は簡単なことにもすでにキー入力が多いし、この変更用のマクロを自作できるほどの専門家ではない。
この件は、Thierry がレジスター動作にいくつかの問題を見つけ、それを直そうとしたことから始まったように見える。
最も重要な欠陥は、
C-x r SPCでsave-to-registerを押したあと、次に押すどのキーであっても、そのキーに対応するレジスターにテキストが保存される点だった。特に Emacs の汎用キャンセルキーであるC-gもここでは機能せず、^gというレジスターにテキストや位置が保存される。jump-to-registerやinsert-registerを誤って押してもC-gなどでキャンセルできず、必ずレジスターを選ばなければならなかった。第二に、レジスターにはテキスト・位置・空の値のいずれかを格納できる。
jump-to-registerは位置が入ったレジスターでのみ動作し、insert-registerはテキストを期待する。Emacs はコマンド実行時に空でないレジスターのプレビューを提供するが、文字列が入ったレジスターもjump-to-registerの候補として表示する、といった具合に区別していなかった。Thierry はこうした問題とコードレビューのフィードバックを直そうとし、レビュアーたちは追加の対話が発生するとしても重要な変更だと見ていた。通常のレジスター選択後に
RETを押す必要があったり、^gのような奇妙なレジスターに保存するには追加キーが必要になったりする互換性破壊も、得られる利点に比べれば受け入れられると見なしたわけだ。元記事の筆者は新しい動作と古い動作を切り替えるスイッチを求め、パッチを出してほしいと返答されたが、提出したパッチは前述の改善をすべて戻し、まったく別の機能である「空でないレジスターの上書き確認」をフラグベースで実装するものだった。Thierry がそれを適用してみて簡単なフィードバックを返すと、筆者は事実上「そういうものは要らない」と答えた。
その後、より多くの人がこの機能を使う中で、破壊的変更の影響は小さいという Thierry と初期レビュアーたちの考えは間違っていたことが明らかになり、Thierry は新しい仕組みを維持しつつ以前のフローも許可するフラグを作り始めた。特に追加の
RETをなくすことは本質ではなく、副作用に近かった。全体として手続きはかなりうまく機能しているように見え、文脈を無視して「だいたい動くなら、どんな形でも変えてはいけない」という反ハッカー的な態度で議論を押し通そうとしているのは、むしろ元記事の筆者側に近い。
dyyは現在行の削除を意味すると予想したと思う。ただし、おそらくそれこそが初心者である証拠なのかもしれない。
このメーリングリストのスレッドを見ると、該当の動作を元に戻す オプション が追加されるように見える: https://yhetil.org/emacs/87h6kr9817.fsf@posteo.net/#t
このオプションは元記事が投稿される前にすでに言及されていたようだが、筆者が見落とした可能性もある。これで問題は解決しそうだが、見落としている点があるかもしれない。
追記: 下の ginko の返信を見ると、依然として RETURN キー入力が必要になりそうだ。
RETが必要なようだ。https://yhetil.org/emacs/87a5qi1vui.fsf@posteo.net/
register-use-previewsがこの動作の トグル のように見える。ただし、
neverに設定しても特定のワークフローでは確認が出るバグが言及されている。本当にオプションなら、懸念の大半は解消されそうだ。Emacsでは筋肉記憶を第一級の関心事に格上げすべき
積み上げてきた筋肉記憶が壊されたからだ。落ち着くまで、かなり邪悪な考えさえ抱いた。些細に見えるかもしれないが、「筋肉記憶への裏切り」という罪に対する反応が「fork you」にまで大きくなる理由は理解できる
これはGoogle MapsやiOSにも、Emacsとまったく同じように当てはまる
筋肉記憶があれば、細かなインタラクションのたびに目で確認しなくても、「見ずに」半非同期的にソフトウェアを操作できる。残念ながらデスクトップソフトウェアでは、キーボード操作をますます面倒にしたり、そもそも不可能にしたりする流れがある
よいrantではあるが、肝心の対象機能が何なのかを説明していない点は説得の助けにならない
Emacsのレジスタは非常に古い抽象化だ。レジスタは別のクリップボードのように値を入れたり取り出したりでき、主要なASCII記号
[a-zA-Z0-9]に結び付いた62個があり、柔軟で高速なキーボードインターフェースを提供する。レジスタからキーボードマクロを実行するという面白いこともできる。多用する人もいるが、個人的には使わない筆者が怒っている理由は、デフォルトのバインドが変わり、以前は完全にキーボードとホームロウだけでできていた作業の前にモーダルUIが挟まるようになったからだ。もっともな不満に聞こえるし、自分の筋肉記憶に染み付いた機能がこのように変わったら、自分も苛立っただろう
選択と貼り付けのたびに確認用のモーダルダイアログが挟まり、従来の挙動に戻す設定もないなら、確実に腹が立つだろう。既存の挙動をオプションとして実装すればよい。文字通り数行のコードで可能だ
C-aレジスタへのアクセスを壊すという点だ知り合いには、位置には文字、テキストには
C-文字を使う人がいる。誰かにとってはかなり特殊なケースかもしれないが、そういう人たちは非常に怒るだろうhttps://yhetil.org/emacs/8334wawfvg.fsf@gnu.org/でEliは「反対意見が出たので、どのような挙動にすべきか引き続き議論中であり、結論が出たらデフォルト値について話せる」と述べている
元記事の筆者の解釈はよくない。安定性を望むユーザーはリリースブランチにいるか、masterのコミットを固定すべきだ
開発ブランチは進行中の機能を開発するために使われるものだと考えるべきで、こうした機能は磨き上げるのに時間がかかることがある。masterを追うなら、互換性を壊す変更に頻繁に遭遇することになり、ワークフローが壊れたら以前のコミットに戻すことに慣れているべきだ。よりよい選択はリリースに留まることだ
Emacsの核心は極度にカスタマイズ可能なプラットフォームである点で、ある機能の挙動が気に入らなければ、Lispを数行書いて自分で直せる
あるobscureな機能変更のためにプロジェクト全体をフォークするのは、まったく意味がない。TECOマクロで実装されていた時代、1981年ごろからEmacsを使ってきたが、レジスタは使わない
そうでなければ、プラットフォームが変わるたびに、誰もが毎回すべてのカスタマイズ設定を書き直したり修正したりしなければならない
このパッチがそのまま残り、誰かが正確に以前の方式で使いたいなら、事実上Emacsのローカルリポジトリに巻き戻しパッチを適用し、自分の変更を載せる必要がある。upstreamのEmacsが変わるたびに新しい変更を取り込むにはrebaseしなければならない
それは私的フォークだ。永遠にフォークされたまま、永遠にrebaseし続けることになる
ざっくりmonkey patchで、shippedファイルの代わりに、あるいは後から自分のファイルをロードして関数を再定義することもできるが、それも一種のフォークだ。資料をプロジェクトとしてどこかに保管する必要があり、変更でmonkey patchが壊れたときに調整する準備をしておかなければならない
Emacsを離れて20年になるが、この変更がかなり破壊的だということは理解できる
理解できないのは、「キッチンシンクまで何でもある」と自負するEmacsが、なぜ既存の挙動に戻すオプションを追加しなかったのかという点だ
そのパッチはフラグを追加したが、他の改善点まで全部なくしてしまっていた
文章の調子がかなり「neckbeard」っぽい。3人のnerdだけが使っているものすごくobscureな機能であって、聖墳墓教会の動かせない梯子ではない
無給のメンテナが事前にあなたに尋ねず少し変えたからといって、必ずしも「masterを壊した」ことにはならない。今話しているのは安定版やタグ付きリリースではなくmasterだ
当然ながら、可能な唯一の解決策はまた別のEmacsフォークか再実装を試みることだ
今回のものは間違いなく成功し、他のもののように完全に無関係な存在にはならないだろう
ただし、フォークがメインプロジェクトを交渉のテーブルに引き出すかどうかは、あまり重要ではない。元記事の筆者には、そのパッチを自分のローカルリポジトリに最後まで抱えて維持する能力と意志がある。フォークを完成させるのに欠けているのは、そのローカルリポジトリを公開することだけだ
もしかすると、mainlineのメンテナを説得するためのものかもしれない