現実逃避ぎみに… 徒然と

ConQuery 1.7.3 改造版のコメント欄にあるバグつぶしをやっているのですが… これが、なかなかはかどっていません。mod-4b4 で対応した {searchTerm}+Optional String のパターンでエンバグした状態なのですが、これと複数のテンプレートパラメータ {searchTerms}+{template parameter} なパターンとの両立に結構頭を悩ませています。
オリジナルの ConQuery 1.7.3 はどちらのパターンも「一見」正しく動作しているように見えるのですが、実はサイトに応じた非ASCII(URI)文字のパーセントエンコードを考慮していないため(ぶちゃけると、正しく処理していない)、たまたま ASCII 言語圏でうまく動作しているだけです。
固定された Optional String の場合と({searchTerm}、{selection}、[:selection] 以外の)テンプレートパラメータでの分離、個別パーセントエンコードが結構面倒くさい処理になりそうです。

で、なぜかほぼ同時に(以前、複数検索エンジンによる同時検索を提案してきた)ロシア人から「同時検索が動作しないパターンがある」との報告がメールであったのですが、こちらが「そんなはずはない、こちらでは再現しない。他の拡張を全無効、新規プロファイルでチェックしてみ」と返信したところ… 「ゴメン、こっちの勘違いやった。ちゃんと動くわ」って… 最初の問題の対策を考えつつ、この問題の調査にも結構時間を割いたのに「それはないやろ」状態。

更に、また別の方からメールで「Firefox 3.1(Minefield) 上で Quick Context と一緒に使いたいけど、文字列をドラッグして Quick Context で自働的にポップアップするコンテキストメニューから検索できない。正しく選択した文字列が渡されていない」との報告が… (結構切れる寸前) Quick Context ってそもそも Firefox 1.0 - 1.5 用で作者もメンテナンスを放棄しているシロモノ。
更に言うと、ConQuery 内部での選択文字列の取得、および内部動作用の処理が結構トリッキーというか、またもや global 変数てんこ盛り状態で弄りたくない部分の一つ。この手の連動型拡張の場合は、一般的には互いの処理を把握していないと上手く動作しない。ぶっちゃけると、ここを弄りだすと根本部分から ConQuery の処理を書き直さないといけないので「ごめんやけど、Quick Context への対応はしません」と返答。

余力があれば、やってみたいところではあるけど、以前に選択文字列取得部分を一読した限りであれば、連動型拡張とは明らかに相性が悪そうな作りになっていた。

以前に書いたとおり、そろそろこういった「元々の ConQuery の不手際に起因する問題修正が、負担になりつつある」ので、スクラッチから検索系拡張を作成したいと思っているのですが、こっちもなかなか進みません。

更に間の悪いことに… (以前痛めた腰の方は快調なのですが)、コンピュータというものに初めて触れてからかれこれ２５年、それを飯の種にし始めてから１５年ほどが経過するのですが、長年の酷使に耐えかねたのか、単に年をとったからか(苦笑)、ひと月ほど前から右肘が痛みを発しております。腱鞘炎ではなさそうなのですが、痛みが日常生活に支障を及ぼしはじめております。つらつらと考えてみるに、ここ数年の腹筋、背筋の弱体化とともに、マウスを操作する際に右腕を突っ張るようにして上体をささえる姿勢がよろしくないみたいなのですが… 現在、市販の湿布を張りつつ、姿勢の矯正に努めています。