Chromeが135.0.7049.95に更新されたのだが、これに対して–gtk-version=3を与えると何かが盛大に壊れ、ページのkeydownまわりとか、あるいはコンテンツスクリプトからバックグラウンドへのメッセージングとか、とりとめなく色んなところがおかしくなるようだ。
Emin #4
Reply
Tag Archives: search-cobb
Emin #3
ところでEmacsのキーバインディングを実装すると言っても、当然ながらほんの一部であってそんな大したものではない。ただし実装しておーこれは意外に便利かも？ と思ったものもある。
EmacsはM-/ でdynamic abbrevという機能が働くが、これを似たようなものを実装した。例えば入力中にサジェストが表示されるサイトなんかでM-/を押すとそのサジェスト候補が自動入力される。候補が複数ある場合はそのままM-/を押していけば順繰りに入力される。
それからこれはEmacsとは全然関係ないが、カーソル位置の四則演算式をその結果で置き換える機能をM-cに割り当てた。また、C-mを押すと、入力している要素が属するフォームをサブミットするようにした。
Emin #2
そういうわけで、月末までEmacsバインディングのないChromeで過ごさざるを得なくなったわけなのだが、当然の成り行きながらCtrl+HやCtrl+Wをうっかり押してしまいぎょえー！となるアクシデントが頻発して気が狂いそうになっている。どうにかならないの。
Emacsバインディングと言えば、過去にjavascriptレベルで実装したことがある。赤福プラスは *.2chan.net 上でのみ、Search Cobb は検索文字列入力欄のみEmacsバインディングが有効になっている。ちなみに両者の違いは、前者がフクザツな作り（各ハンドラが非同期でもよいとか、Firefoxでも動くとか）で後者がシンプルということだ。
この実装済みながら、適用範囲が限られているものをwebページ全体に押し広げればなんとかならないだろうか。
ということで、SearchCobbのそれを拡張することにした。
言うまでもないがこのソリューションだとアドレスバー、拡張が管理するドキュメント、Webコンポーネントの中身などには効果が及ばないため完全ではないのだけど、しかしないよりははるかにマシである。
ところでこのgtk4でgtk-key-themeが効かなくなっちゃう問題ってXとかで検索しても特にホットな話題でもなんでもないみたいなんだけど、そういうものなんだなあ…。
Let’s search inside web pages
たいていのブラウザに組み込みのページ内検索機能があり、Chromeにもある。ただし、ブラウザがもっと小規模なアプリケーションだった頃からある機能のせいか微妙に素朴な動きしかしてくれない。例えば標準で正規表現が使えると嬉しいのだけど、できない。ページの密度が高くなってくると単に色でハイライトされたキーワードを見つけづらかったりするのも不便。検索ダイアログをEscapeでしか閉じられないのもめんどう。
そこで必要な機能を備えた拡張を作るかということになる。もちろん正規表現でページ検索できる拡張はすでにたくさんあるのだが…例えば現代だとそこかしこに絵文字が使われてるわけだが、最新の絵文字は複数のコードポイントから形成されてたりする。つまり検索を行う拡張側でも正確な書記素クラスタの認識ができないとハイライト処理などが盛大に壊れたりする可能性があり…実際いくつか試してみたところ盛大に壊れる。
また、正規表現によるページ内検索を実装する場合、要素を走査して要素ごとに検索を行う場合とそれ以外が考えられる。前者だと パンケーキとどら焼きって<b>ぶっちゃけ同じ</b>だよね のようなテキスト全体を検索することができない。既存の拡張は、全て試したわけではないが、だいたい半々くらいに分けられると思う。シンプルな実装の方が堅牢だし応答もよいだろうから明確に優劣があるわけではないのだが、まあできるのなら要素をまたいだ検索が可能な方がよい。
ついでに言うと migemo 検索ができると若干嬉しい。若干というのは、Chrome で migemo 検索というのは10年くらい前にはそういう拡張があったのだが、知らないうちに公開停止になっていて、しかもそれが特に話題にもなってないっぽくて、特に代替の拡張も登場しないまま10年経っているという現実が引っかかるからである。要するに非常にニッチにしか刺さらなくて、あんまり広い需要はないし売りにもならないのかもしれない。まあ個人的にはあれば嬉しい。
以上の要件を勘案すると、じゃあ新しいの作るかーということになる。
＊ ＊ ＊
というわけで、作った。