統合検索ページの module function 表示を ?. に統一しハイライトも修理する

[znz]

概要

#279 のコメント対応2件です。vendored な Aliki 3本(search_ranker.js / search_controller.js / search_navigation.js)は引き続き無改変です(git diff で確認済み)。

1. /ja/search/ の表示を ?. に統一

同じ module function が版によって Kernel.#open(4.0 より前)と Kernel?.open(4.0 以降)の2行に分かれて表示されていました。SearchIndexGenerator.merge で、match_name を持つエントリ(修飾付きメソッド)の full_name の .# を ?. に畳んでからマージキーを計算するようにしました。

• name/type/path/match_name は表記に依らず同一なので、full_name を畳むだけで1エントリに合流し、バージョンリストも1行にまとまります(例: Kernel?.open の下に旧版〜4.1 が全部並ぶ)
• 旧表記の版にしか存在しないまま消えたメソッドも、統合ページでは ?. 表記に揃えます
• match_name を持たない散文見出し(字面に .# を含み得る)はページ本文の字面と一致していることに意味があるため畳みません
• 各版ページ内の検索ボックス(search_init.js)はその版の表記のまま(build_index は不変更)。.# 表記でのクエリは従来どおり match_name 経由で両表記にヒットします

2. highlightMatch() の対応(search_init.js / search_page.js)

#280 で修飾付きクエリはヒットするようになりましたが、ハイライトが付きませんでした。vendored の highlightMatch() は .→:: 書き換え後の q.normalized を表示用 full_name と比較するため連続一致せず、fuzzy fallback も最初の : で必ず脱落します。

parseQuery/computeScore と同じ feature-detect ラップを highlightMatch にも追加しました:

• vendored がマークを付けられた場合はその結果をそのまま返す(従来動作は不変)
• 付けられなかった場合のみ、q.original(parseQuery ラップが保存している生のクエリ)と表示文字列を .#/?. 同一視で突き合わせ、連続一致にハイライトマーカー(\u0001/\u0002、hlt() が <em> に変換)を挟む
• .# と ?. はどちらも2文字なので、畳んだ文字列で求めたインデックスをそのまま表示文字列に流用できます(ズレなし)
• クロス表記(Kernel.#open のクエリで Kernel?.open の行、またその逆)もハイライトされます
• 将来 Aliki 側がグローバル関数でなくなった場合は静かにスキップして従来動作に退行します(既存ラップと同じフォールバック方針)

テスト

• test_search_index_generator.rb: merge の畳み込み(両表記合流・旧表記のみでも ?. 化・match_name 無し見出しは畳まない)
• test_searchpage_command.rb: 実 DB 2版(3.3/4.0)からの統合で Kernel?.at_exit 1エントリ+出力に Kernel.# 非出現
• test/js/test_search.mjs: highlightMatch の両表記×両方向・部分一致・fuzzy 素通し・非一致時素通し、search_page.js の end-to-end(.# クエリ → ?. 行が全体 <em> ハイライト・最新版リンク+版リスト描画)、ラップ不能時のフォールバック(no-crash)
• 全 Ruby テスト 17799 件・JS テスト・steep check いずれも green
• スモーク: markdowntree から 3.4/4.0 の実 DB を作って bitclust searchpage を実行 → search_data.js に Kernel?.open(versions: 3.4/4.0)の1エントリのみで .# 非出現

refs #279

🤖 Generated with Claude Code