Scribble at 2024-03-29 10:13:58 Last modified: 2024-03-29 10:19:59

暫く使ってみたが、やはり Pulsar も放棄することとした。もちろん理由は、wrap の挙動があまりにも不安定だからだ。(1) 画面の端で改行する、(2) "Preferred Line Length" で設定した桁で改行する、そして (3) まったく改行しない（しかも水平スクロール・バーすら出ない）という三つの状態を、エディタ全体としてではなく、あろうことかファイルごとにバラバラな挙動となる。もちろん、すべて HTML ファイルとしてファイル形式も揃えて確認済みだから、ファイル形式ごとに挙動が変わってしまうというわけではない。ファイルを開くインスタンスと言っていいのかセッションと言っていいのかバッファと言っていいのか、ともかくファイル単位で挙動が変わってしまう。

こんなのは、まともな（とりわけ僕らのようなプロの開発者が仕事で使うような）テキスト・エディタとは言えない。

もう既に Windows 標準のメモ帳よりも安心して使えないレベルのものであり、しかもこれは10年くらい前にも共通のリポジトリを使っていた Atom Editor で起きていた問題なのに、まったく解決しようとしていないように思える。もちろん、フォーラムなどでもバグ報告はあるから、開発者が気づいていないなんてことはありえない。

そうすると、Atom Editor だろうと後継の Pulsar だろうと、考えられる想像は一つだ。それは、コミットしている開発者に UI を正しく制御するスキルがないということ、そもそもテキスト・エディタだろうとなんだろうと、GUI プログラミングのまともなスキルがない人々しか関与していない、気の毒なプロジェクトなんだろうという想像ができる。

昨今のテキスト・エディタの多くは、実は共通のエンジンなり SDK のようなものを使っていて、ゲームで言えば Unity のようなものがある。そして、Atom Editor や Pulsar では、ご承知のように、Electron というエンジンあるいはフレームワークを採用している。採用しているというよりも、このフレームワークは、もともと "Atom shell" と呼ばれていたくらいだから、Atom Editor のエンジンとして開発されたのだが、このフレームワーク自体がオープンソースであるため、同じエンジンを使って UI だけこねくり回した「卒業制作」レベルのガラクタみたいなテキスト・エディタが、そのあと続々と量産されるようになった。JavaScript と CSS で「テーマ」をカスタマイズするエンド・ユーザと大して変わらないスキルしかなくても、エンジンをカスタマイズできれば自作のテキスト・エディタをリリースできてしまうからだ。そして、いつまでもこういう致命的で基本的なバグが治らないということは、Atom editor や Pulsar の開発者は Electron というフレームワークを十分に理解していない可能性がある。

そして、そう想像できる理由もある。なぜなら、僕がいま使っている Microsoft の Visual Studio Code (VSCode) も Electron をベースに開発されているからだ。同じエンジンを使っていて、一方は wrap の挙動に問題がないのだから、これはどう考えても Atom Editor や Pulsar の開発者に Electron を扱う能力がないと見做されてもしょうがないだろう。

だいたい、Electron を開発したもともとの GitHub のスタッフからして、Atom Editor で自分たちが開発したフレームワークを正しく扱えなかったわけである。そら、プロジェクトを放棄することになるのもしょうがない。これは、或る意味では非常に珍しい事例だとも言える。だが、こんなことは「シンギュラリティ（自分たちで開発した AI が自分たち自身で制御できなくなる特異点という意味での）」の話を持ち出すまでもなく、十分にありえることなのである。たとえば、Ruby の開発者である Matz 氏が Ruby であらゆるシステムを正しく開発・実装できるかというと、そんなことはない。