![[chappy-log.webp|cover-picture]] ## 経緯 <div class="link-card-v2"> <div class="link-card-v2-site"> <img class="link-card-v2-site-icon" src="https://github.githubassets.com/favicons/favicon.svg" /> <span class="link-card-v2-site-name">GitHub</span> </div> <div class="link-card-v2-title"> Preserve first-letter case · Issue #329 · tadashi-aikawa/obsidian-various-complements-plugin </div> <div class="link-card-v2-content"> Thanks for the great plugin! What I wish to have is to handle the following problem in some way: Given: my notes ... </div> <img class="link-card-v2-image" src="https://opengraph.githubassets.com/0eeba23405048b5361bb3b5e2d7e6da071f58d97dde8a6a0333ddd447c555f32/tadashi-aikawa/obsidian-various-complements-plugin/issues/329" /> <a href="https://github.com/tadashi-aikawa/obsidian-various-complements-plugin/issues/329"></a> </div> ## 対応すると決めた理由 - 英語圏では普通の要件 - [[Current file complement]]などでは対応している - [[Internal Link Complement]]は大文字小文字の区別なしに候補に表示している - そこに手入れは必要なさそう - 最後の挿入時だけ処理を追加すれば、影響範囲は小さく抑えられそう ## ログ 結構議論が白熱したのでログを残す。特に固有名詞周り。 > [!right-bubble] ![[minerva-face-right.webp]] > https://github.com/tadashi-aikawa/obsidian-various-complements-plugin/issues/329 の対応を行う場合、internal linkを挿入する部分にのみ手を入れれば大丈夫そうですか？ 影響範囲がそこに収まるなら対応しようと思っていますが、それ以上広がりそうなら微妙だなと思いまして。 > > ネットワークアクセスしてもらって構いません。 > [!left-bubble] ![[chappy.webp]] > 結論としては、基本的に内部リンク挿入ロジックに手を入れれば足ります。具体的には src/ui/AutoCompleteSuggest.ts の constructInternalLinkText がリンク文字列を組み立てているので、ここで > 「入力クエリの先頭が小文字で、補完語の先頭が大文字なら `[[Link|alias]]` を返す」といった判定を入れるのが最短です。 > word.query は src/provider/suggester.ts で既に埋められているので、原則ここ以外は触らずに済むはずです。 > > ただし、次のケースをどうするかで影響範囲が少し広がる可能性はあります。 > > - 設定としてオン/オフ可能にするなら src/setting/settings.ts（Settings/DEFAULT/設定UI）に手を入れる必要あり。 > - 新規リンク（phantom）や特殊な挿入モードまで厳密に揃えるなら、クエリ未設定ケースの扱いを追加で検討が必要。 > > 上記を許容できるなら、変更範囲はほぼ src/ui/AutoCompleteSuggest.ts に閉じられる見立てです。 > [!right-bubble] ![[minerva-face-right.webp]] > ちなみに、src/ui/AutoCompleteSuggest.ts 以外に対応を入れる選択肢もありますか？ それぞれのメリット・デメリットは？ > [!left-bubble] ![[chappy.webp]] > > あります。src/ui/AutoCompleteSuggest.ts 以外に入れる場合の代表的な候補とメリデメを整理します。 > > 候補 > > - src/provider/suggester.ts（judge / suggestWords まわり） > - メリット: ここで「入力の先頭ケースに合わせた alias を生成」すれば、挿入側は今のままで済む。word.query を既に持っているので条件が揃っている。 > - デメリット: 表示側の value/hit が変わるため、候補表示や履歴順位付けにも影響が出る可能性がある。内部リンク以外にも波及しやすい。 > - src/provider/InternalLinkWordProvider.ts（インデックス生成） > - メリット: インデックス時点で小文字版の alias を仕込めば、後段のロジック変更が最小になることがある。 > - デメリット: 本来の alias ではない文字列を持たせることになるので、候補の意味がズレる可能性。辞書サイズも増える。 > - src/ui/popup-commands.ts（selectWithQueryAlias） > - メリット: 既に「クエリを alias にする」機能があるので、ここを自動化する発想が取れる。 > - デメリット: 既存のホットキー挙動を変えることになるので、UI/UXの期待が崩れやすい。通常 Enter と挙動を揃えるなら結局 AutoCompleteSuggest 側に寄せたくなる。 > - src/app-helper.ts（optimizeMarkdownLinkText 等） > - メリット: リンク解決の変換処理に近い位置で統制できる。 > - デメリット: ここは「パス解決と表示最適化」が目的なので、入力のケースというエディタ文脈に依存する処理を入れると責務が崩れる。 > > 結論（影響の小ささ重視） > > - 「挿入時のテキスト生成だけ変えたい」なら、やはり src/ui/AutoCompleteSuggest.ts が最小範囲。 > - 「候補生成のルールそのものを変えて、表示や履歴も含めて統一したい」なら src/provider/suggester.ts 側も選択肢。 > > 必要なら、どの仕様を最優先するか（表示・履歴・設定追加の有無）を確認してから方針を絞ります。 > [!right-bubble] ![[minerva-face-right.webp]] > > クエリがHogeであり、hoge.mdがヒットするとき > > - `[[hoge|Hoge]]` > - `[[hoge]]` > > の2つがヒットしてしまうのは論外です。そうなると...？ > [!left-bubble] ![[chappy.webp]] > > その条件だと「別候補として `[[hoge|Hoge]]` を追加する」案は確実にアウトです。suggestionUniqPredicate は word.value 単位で重複排除しているので、hoge と Hoge は別物扱いになり、2件表示されます。 > つまり “候補を増やす” 方向ではなく “挿入時に出力を変える” 方向 でやる必要があります。 > > 具体的にはこうなります。 > > - NG（2件出る） > - InternalLinkWordProvider などで Hoge を alias として候補に追加 > - suggester で別 Word を生成して提示 > - OK（1件のまま） > - constructInternalLinkText で word.query とリンクの先頭文字の大小が違う場合だけ alias 出力 > - 候補リストは今の 1 件のまま、挿入文字列だけ `[[hoge|Hoge]]` にする > > 注意点として、重複排除を「大小無視」に変える手もありますが、Linux 等で Hoge.md と hoge.md が共存する環境では壊れるので非推奨です。 > > 要するに、「二重候補を絶対避ける」前提なら 挿入ロジックで分岐させるしかない です。 > [!right-bubble] ![[minerva-face-right.webp]] > > 了解です。では `constructInternalLinkText` に今回追加するオプションを渡し、その中で構築する方針でお願いします。 > > エッジケースでいくつか疑問点や選択肢がある場合は聞いて下さい。 > [!left-bubble] ![[chappy.webp]] > 了解です。constructInternalLinkText にオプションを渡して挿入時に分岐する方針で進めます。実装前に仕様の確認だけさせてください。 > > 確認したい点（エッジケース） > > - エイリアスに使う文字列: クエリが部分一致のとき、`[[Link|query]]`（例: mem）にするか、`[[Link|linkの先頭だけ小文字化]]`（例: memory）にするか、どちらが望ましいですか？ > - 既存エイリアス候補（word.aliasMeta があるケース）でも今回の「先頭文字の保持」を適用しますか？ それとも既存エイリアス優先で触らない方が良いですか？ > - insertAliasTransformedFromDisplayedInternalLink が有効な場合、今回のオプションとどちらを優先しますか？ > - select with query alias（ホットキー）を使った場合は、今まで通り「クエリ優先」挙動のままでよいですか？ > - デフォルト: 新オプションは既存挙動維持のため OFF にして良いですか？（ON を希望なら言ってください） > > 進め方（プラン） > > - 仕様確定（上の確認事項） > - 設定追加（Settings/DEFAULT_SETTINGS/設定UIに新オプション） > - constructInternalLinkText にオプションを渡し、挿入テキスト生成を分岐 > - 必要なら軽いテスト追加（どうするか相談） > > この内容でOKなら「進めて」と言ってください。 > [!right-bubble] ![[minerva-face-right.webp]] > > - エイリアスに使う文字列: クエリが部分一致のとき、`[[Link|query]]`（例: mem）にするか、`[[Link|linkの先頭だけ小文字化]]`（例: memory）にするか、どちらが望ましいですか？ > > 質問の意味が分かりませんでした。 > > > - 既存エイリアス候補（word.aliasMeta があるケース）でも今回の「先頭文字の保持」を適用しますか？ それとも既存エイリアス優先で触らない方が良いですか？ > > クエリがエイリアスに対するマッチで、エイリアスを表示文字列として挿入する場合、その表示文字列の先頭がクエリの先頭と大文字・小文字異なるならあわせてほしいです。 > > > - insertAliasTransformedFromDisplayedInternalLink が有効な場合、今回のオプションとどちらを優先しますか？ > > クエリがエイリアスに対するマッチで、エイリアスを表示文字列として挿入する場合、その表示文字列の先頭がクエリの先頭と大文字・小文字異なるならあわせてほしいです。 > > > - select with query alias（ホットキー）を使った場合は、今まで通り「クエリ優先」挙動のままでよいですか？ > > よいです。 > > > - デフォルト: 新オプションは既存挙動維持のため OFF にして良いですか？（ON を希望なら言ってください） > > OFFでよいです。 > [!left-bubble] ![[chappy.webp]] > ありがとうございます、把握しました。1点だけ仕様確認させてください（ここが決まれば着手できます）。 > > 質問（意味の再説明） > > - 「部分一致で選択した場合に、表示文字列をどうするか」の確認です。 > 例: 入力が mem、候補は Memory のとき > 1. `[[Memory|mem]]`（ユーザーが実際に打ったクエリを表示に使う） > 2. `[[Memory|memory]]`（候補語の先頭だけクエリに合わせたものを表示に使う） > どちらが望ましいですか？ > > 補足の確認 > > - insertAliasTransformedFromDisplayedInternalLink が有効な場合、変換後の表示文字列の先頭をクエリに合わせる、で良いですか？（例: 変換で Memory→MEMORY になっても、クエリが memory なら > memory を優先するかどうか） > > この2点だけ教えてください。OKをもらえたら、プラン通りに実装へ進みます。 > [!right-bubble] ![[minerva-face-right.webp]] > > 2. `[[Memory|memory]]`（候補語の先頭だけクエリに合わせたものを表示に使う） > > こちらでお願いします。今回の対応はあくまで『先頭の大文字・小文字の差異がある場合、クエリの先頭文字状態を常に優先させる』という方針で一貫しています。 > > > - insertAliasTransformedFromDisplayedInternalLink が有効な場合、変換後の表示文字列の先頭をクエリに合わせる、で良いですか？（例: 変換で Memory→MEMORY になっても、クエリが memory ならmemory を優先するかどうか） > > はい。ただあくまで先頭だけなので、`Memory -> MEMORY` になるのであれば `mEMORY` でしょうか... ただちょっとこれは違和感ありますね。一旦 `insertAliasTransformedFromDisplayedInternalLink` のことは気にしなくていいです。 > [!left-bubble] ![[chappy.webp]] > 内部リンク挿入時に「クエリの先頭文字の大小を優先する」オプションを追加し、挿入テキスト生成側でケース合わせを行うようにしました。既存挙動はデフォルトOFFで維持しています。 > > 変更内容 > > - src/setting/settings.ts に preserveFirstLetterCaseOnInternalLink を追加し、デフォルトOFF＋設定UIにトグルを追加しました。 > - src/ui/AutoCompleteSuggest.ts の constructInternalLinkText にオプションを渡し、表示文字列の先頭だけクエリのケースに合わせて挿入する分岐を入れました。wikiリンクの場合はケース差分が > あるときに `[[link|alias]]` 形式を使います。 > > テストは実行していません。 > > 次のステップ（手動確認） > > 1. 設定で “Preserve first-letter case” をONにする > 2. memory → Memory を補完して `[[Memory|memory]]` になることを確認する > 3. エイリアス候補でも先頭ケースがクエリに一致することを確認する > [!right-bubble] ![[minerva-face-right.webp]] > queryはword: InternalLinkWord から取得できませんか？ 渡す必要があるのはなぜ？ > [!left-bubble] ![[chappy.webp]] > はい、word.query から取得できます。今回あえて渡した理由は主に次の2点です。 > > - word.query は任意項目で、すべての InternalLinkWord に必ず入る保証がない（新規リンク生成や一部の経路で未設定の可能性がある）ので、**「この呼び出しではクエリを使う」** を明示したかった。 > - constructInternalLinkText を「挿入ロジックとして明示的に制御できる形」にしておくと、今後別の呼び出し経路でクエリを使わない判断も明確になるため。 > > とはいえ現状の呼び出し元では word.query がある前提で動いているので、シンプルに word.query を参照する形にリファクタして問題ありません。もしその方針なら、次のように直します（コード変更はまだしていません）。 > > - constructInternalLinkText の option.query を削除し、word.query を直接参照 > - 呼び出し側は preserveFirstLetterCase だけ渡す > > このリファクタを入れますか？入れるならプラン提示→承諾の流れで進めます。 > [!right-bubble] ![[minerva-face-right.webp]] > それでお願いします。word.query はjudgementの後に必ず挿入されるロジックになっていると思います。念の為、関連コードを調査してそれも確認しておいてください。 > [!left-bubble] ![[chappy.webp]] > 調査結果です。 > > - word.query は src/provider/suggester.ts の judge / judgeByPartialMatch で マッチ成立時に必ず付与されています（query が空文字の場合だけ例外）。 > - suggestWords / suggestWordsByPartialMatch は Judgement の word をそのまま返すため、通常の候補では word.query が入ります。 > - 例外として、src/ui/AutoCompleteSuggest.ts の createNewLinkSuggestions()（新規リンク補完）では InternalLinkWord を直接生成していて query が入らない経路があります。 > > なので 通常の補完では word.query 参照で問題なし、ただし新規リンク補完などの例外を考慮して word.query が未定義なら何もしないガードは残すのが安全です。 > > 変更プラン（承諾後に実施） > > 1. src/ui/AutoCompleteSuggest.ts の constructInternalLinkText から option.query を削除し、word.query を直接参照 > 2. 呼び出し側は preserveFirstLetterCase だけ渡す > 3. word.query が未定義のときは従来通り変換しないガードを維持 > > この方針で進めてよいですか？（OKなら「進めて」とだけ返してもらえれば着手します） > [!right-bubble] ![[minerva-face-right.webp]] > なるほど。存在しない新規リンクのケースだけは失念していました。これは `Fallback linkify` 機能で候補に表示される一覧ということで良いでしょうか？ > > もしそうなら、エディタに入力された大文字・小文字のまま新規リンクの表示としてしまっていい気がします。そこを推論するのはかなり難しいので。 > > つまり、提案してもらった方針でOKです。 > [!left-bubble] ![[chappy.webp]] > はい、その理解で合っています。createNewLinkSuggestions() で作られる新規リンク候補（phantom: true）が「Fallback linkify」経由の一覧です。ここは word.query が無いので、入力されたケースのまま表示/挿入で良い方針にします（ケース推論はしません）。 > > 実装方針（再掲・簡略） > > - constructInternalLinkText は word.query を参照し、未定義ならケース合わせしない > - 呼び出し側は preserveFirstLetterCase だけ渡す > - 新規リンク（word.query なし）は従来通り入力通りで挿入 > > この方針で修正を進めてよければ「進めて」と返してください。 > [!left-bubble] ![[chappy.webp]] > word.query を直接参照する形に切り替えました。word.query 未定義のケース（Fallback linkifyの新規リンク候補）ではケース合わせをスキップするので、入力通りのまま挿入されます。 > > 変更点 > > - src/ui/AutoCompleteSuggest.ts の constructInternalLinkText が word.query を直接参照するように変更 > - 呼び出し側は preserveFirstLetterCase のみ渡すよう整理 > > テストは実行していません。 > > 次のステップ（手動確認） > > 1. 設定で “Preserve first-letter case” をON > 2. memory → Memory を補完して `[[Memory|memory]]` > 3. Fallback linkify（新規リンク候補）では入力ケースのまま挿入されることを確認 > > 必要ならテスト追加も対応します。 > [!right-bubble] ![[minerva-face-right.webp]] > applyQueryFirstLetterCase を AutoCompleteSuggest.ts 以外の適切なファイル内に関数として分離できますか？ > > - queryは引数で指定する > - preserveFirstLetterCase は考慮しない (AutoCompleteSuggest.ts#constructInternalLinkText で考慮) > > その上で、applyQueryFirstLetterCase のテストを書いてほしいです。そこまで分離すれば簡単に書けるはず。 > [!left-bubble] ![[chappy.webp]] > 以下の方針で進めます。問題なければ「進めて」と返してください。 > > - applyQueryFirstLetterCase を src/util/strings.ts に分離（query は引数、preserveFirstLetterCase は呼び出し元で判定） > - src/ui/AutoCompleteSuggest.ts から新関数を呼ぶように修正 > - src/util/strings.test.ts にテスト追加 > > 進めていいですか？ > [!left-bubble] ![[chappy.webp]] > applyQueryFirstLetterCase をユーティリティとして分離し、AutoCompleteSuggest 側はその関数を使う形に整理しました。合わせて単体テストを追加しています。 > > - src/util/strings.ts に applyQueryFirstLetterCase を追加 > - src/ui/AutoCompleteSuggest.ts でローカル関数を廃止し、ユーティリティを呼ぶように変更 > - src/util/strings.test.ts にケース変換のテストを追加 > > テストは未実行です。 > > 次のステップ案 > > 1. pnpm test -- strings.test.ts > 2. もしくは全体実行なら pnpm test > [!right-bubble] ![[minerva-face-right.webp]] > テストケースを少し増やしました。 > > ```ts > describe.each<{ value: string; query: string; expected: string }>` > value | query | expected > ${"Memory"} | ${"memory"} | ${"memory"} > ${"Memory"} | ${"m"} | ${"memory"} > ${"memory"} | ${"Memory"} | ${"Memory"} > ${"memory"} | ${"M"} | ${"Memory"} > ${"Memory"} | ${"Memory"} | ${"Memory"} > ${"Memory"} | ${"M"} | ${"Memory"} > ${"memory"} | ${"memory"} | ${"memory"} > ${"memory"} | ${"m"} | ${"memory"} > ${"AWS"} | ${"a"} | ${"AWS"} > ${"AWS"} | ${"A"} | ${"AWS"} > ${"Memory Card"} | ${"m"} | ${"memory card"} > ${"Memory Card"} | ${"M"} | ${"Memory Card"} > ${"memory card"} | ${"m"} | ${"memory card"} > ${"memory card"} | ${"M"} | ${"Memory card"} > ${"Memory"} | ${""} | ${"Memory"} > ${""} | ${"memory"} | ${""} > ${"1value"} | ${"memory"} | ${"1value"} > ${"Memory"} | ${"1query"} | ${"Memory"} > `("applyQueryFirstLetterCase", ({ value, query, expected }) => { > test(`applyQueryFirstLetterCase(${value}, ${query}) = ${expected}`, () => { > expect(applyQueryFirstLetterCase(value, query)).toBe(expected); > }); > }); > ``` > > 結果は2つ失敗していますが、これは新たに変更した仕様を満たす期待値です。 > > ``` > ● applyQueryFirstLetterCase › applyQueryFirstLetterCase(AWS, a) = AWS > > expect(received).toBe(expected) // Object.is equality > > Expected: "AWS" > Received: "aWS" > > 163 | test(`lowerStartsWithoutSpace(${one}, ${other}) = ${expected}`, () => { > 164 | expect(lowerStartsWithoutSpace(one, other)).toBe(expected); > > 165 | }); > | ^ > 166 | }); > 167 | > 168 | describe.each` > > at Object.<anonymous> (src/util/strings.test.ts:165:93) > > ● applyQueryFirstLetterCase › applyQueryFirstLetterCase(Memory Card, m) = memory card > > expect(received).toBe(expected) // Object.is equality > > Expected: "memory card" > Received: "memory Card" > > 163 | test(`lowerStartsWithoutSpace(${one}, ${other}) = ${expected}`, () => { > 164 | expect(lowerStartsWithoutSpace(one, other)).toBe(expected); > > 165 | }); > | ^ > 166 | }); > 167 | > 168 | describe.each` > > at Object.<anonymous> (src/util/strings.test.ts:165:93) > ``` > > この仕様変更に違和感はありますか？ もし、ない場合はテストが通るように実装を変更してください。ある場合は遠慮なく言ってください。 > [!left-bubble] ![[chappy.webp]] > 違和感はありません。提示いただいた期待値に合わせて実装を調整できます。 > > 進め方（承諾後に実施） > > 1. src/util/strings.ts の applyQueryFirstLetterCase を仕様に合わせて変更 > - クエリ先頭が小文字: 空白区切りの各単語の先頭だけ小文字化（ただし全大文字の単語は維持） > - クエリ先頭が大文字: 文字列全体の先頭だけ大文字化 > - クエリ先頭が非英字/空: 変更なし > 2. src/util/strings.test.ts のテーブルをいただいたケースに差し替え > > この内容で進めてよければ「進めて」と返してください。 > [!right-bubble] ![[minerva-face-right.webp]] > 参考までに、なぜ『違和感がない』と判断したのかの理由(根拠)を教えてもらえますか？ 私は英語で普段文章を書かないので、本当にこの変更点が妥当であるか自信がありません。(想像でこうしただけです。) > [!left-bubble] ![[chappy.webp]] > 違和感がないと判断した理由は、次の2点です。 > > - クエリ先頭が小文字のときは「文中で使いたい」意図が強いので、タイトルケースの語を文中の自然な形（文体＝sentence case）に寄せるのが妥当に見えます。英語では文中の一般名詞句は基本的に小文字なので、Memory Card → memory card は自然寄りです。 > - 全大文字は略語の可能性が高いので、AWS を aWS にしないのは自然です。英語の可読性も落ちるので、ここは保持するのが直感的です。 > > ただし、懸念もあります。 > > - New York などの固有名詞は本来大文字のままが正しいので、new york に落ちるのは誤りになります。 > - “先頭だけ”という当初方針からは外れるため、挙動は強めです。 > > この懸念が許容できるかどうかで方針が分かれると思います。選択肢としては: > > 1. 今回の期待値どおり「小文字クエリなら単語先頭を全部小文字化（ただし全大文字単語は保持）」 > 2. もっと保守的に「文字列全体の先頭1文字だけ変える」 > 3. 折衷として「2語目以降は全大文字 or 明示的に固有名詞っぽい場合は保持」などの追加ヒューリスティック > > 私は 1) でも十分筋は通ると考えますが、固有名詞が多い環境だと違和感が出ます。 > この前提で、あなたの期待値（1）を採用して実装・テストを通す方向で進めてよいですか？ > [!right-bubble] ![[minerva-face-right.webp]] > 懸念について > > - New York などの固有名詞は本来大文字のままが正しいので、new york に落ちるのは誤りになります。 > > これはそのとおりです。ただ "New York" と常に大文字で先頭を表記するようなケースにおいては > > - 登録は "New York" になる > - 入力も "n" ではなく "N" から行うのが普通 > > であるため、問題ないかなと思っています。 > > 別の観点から考察すると、"New York" のようなケースを除けば、"Daily note" は "Daily Note" と各語がすべて大文字はじまりにはならず、先頭だけが大文字として登録されることが多いのではないかとも思います。 > > 私は英語で文章を書かないで妥当性が分かりません。English Nativeとしての意見を聞きたいです。 > [!left-bubble] ![[chappy.webp]] > 率直に言うと、私は英語ネイティブではないので「英語ネイティブとして断定」はできません。その上で、英語の一般的な書き方に照らした“妥当性”の見立ては以下です。 > > 妥当だと思う点 > > - 英語の本文中は基本 sentence case（一般名詞は小文字）なので、タイトルケース（Memory Card）のノート名を文中で使う場合に memory card へ落ちるのは自然です。 > - 既に「クエリの先頭ケースを優先する」という方針にしているので、ユーザー入力を優先するのは一貫しています。 > > 懸念点（ネイティブ観点でも引っかかりやすい部分） > > - 固有名詞やブランド名（New York, YouTube, iPhone, McDonald’s など）は文中でも大文字のままが正しいため、小文字化は誤りになります。 > - “入力は必ず N から始めるはず”は正しい場合も多いですが、速記や習慣で小文字入力してしまうケースが現実的にあり、そこで誤って小文字化される可能性があります。 > > つまり、この仕様は「一般名詞には良い」「固有名詞には誤りが出る」というトレードオフです。 > 英語ネイティブでも、この挙動に“違和感がない”というより「好みの自動整形か、誤りを許容するか」の判断になると思います。 > > もし安全寄りにするなら > > - 「先頭1文字だけ変える（単語全体は触らない）」がより保守的で、固有名詞の崩れを減らせます。 > - 逆に、あなたの期待値どおり「単語先頭を全部合わせる」は、“文中の見た目”重視の強めの補正です。 > > どちらを優先するか（文中の自然さ vs 固有名詞の保護）だけ決めればOKだと思います。 > あなたの前提（固有名詞は大文字で入力する運用）なら、提示の仕様は実用上問題が少ないと判断して良いはずです。 > > この前提で、提示のテスト期待値どおりに実装変更してよければ「進めて」と返してください。 > [!right-bubble] ![[minerva-face-right.webp]] > なるほど。では試しに以下の案を採用する場合にテストケースはどう変わりますか？ > > > 3. 折衷として「2語目以降は全大文字 or 明示的に固有名詞っぽい場合は保持」などの追加ヒューリスティック > [!left-bubble] ![[chappy.webp]] > 折衷案は「明示的に固有名詞っぽい」の定義次第でテストが変わります。代表的な2パターンを挙げると、こうなります。 > > パターンA: “固有名詞っぽい”＝先頭以外にも大文字がある or 全大文字 > > - 既存のテーブルは 変更なし > - 追加テストのみ増やすイメージ > > ${"Memory YouTube"} | ${"m"} | ${"memory YouTube"} > ${"Memory iPhone"} | ${"m"} | ${"memory iPhone"} > ${"Memory AWS"} | ${"m"} | ${"memory AWS"} > ※ New York は保護できず new york になる（この定義だと）。 > > パターンB: “固有名詞っぽい”＝2語目以降が Title Case なら保持 > > - 既存テーブルで 変わるのはここだけ > > ${"Memory Card"} | ${"m"} | ${"memory Card"} // 以前は memory card > - 追加テスト例 > > ${"New York"} | ${"n"} | ${"new York"} > > どちらの定義で進めるのが希望ですか？ > > 1. パターンA（CamelCase/全大文字だけ保護） > 2. パターンB（2語目以降のTitle Caseも保護） > 3. 別の定義（具体的に教えてください） > [!right-bubble] ![[minerva-face-right.webp]] > "memory card" の例は分かりづらいので、ファイルを更新して固有名詞の代表例を追加しました。 > > ``` > value | query | expected > // 中略 > ${"AWS"} | ${"a"} | ${"AWS"} > ${"AWS"} | ${"A"} | ${"AWS"} > ${"New York"} | ${"n"} | ${"New York"} > ${"New York"} | ${"N"} | ${"New York"} > ${"AWS Lambda"} | ${"a"} | ${"AWS Lambda"} > ${"AWS Lambda"} | ${"A"} | ${"AWS Lambda"} > ${"iPhone"} | ${"i"} | ${"iPhone"} > ${"iPhone"} | ${"I"} | ${"iPhone"} > ``` > > これらから導き出せる固有名詞のルールは『先頭1文字目以外に大文字が含まれている場合』ただ1つに集約できると思いました。いかがでしょうか？ > [!left-bubble] ![[chappy.webp]] > 結論として、そのルール（「先頭1文字目以外に大文字が含まれている場合は固有名詞扱いで変更しない」）は、提示された例と矛盾せず、実装もシンプルで良いと思います。 > > 妥当だと感じる理由 > > - AWS, iPhone, New York, AWS Lambda がすべて「先頭以外に大文字あり」で保護されるので、例外なく期待値に合います。 > - 実装が単純なので挙動が予測しやすく、テストも明快です。 > > ただしトレードオフ > > - Daily Note や Meeting Notes のような「一般名詞だけどタイトルケースで命名したノート」も変更されなくなるので、文中では大文字が残りやすくなります。 > ここを許容するなら、このルールで十分です。 > > このルールにすると、たとえば以下は変更されません。 > > - Memory Card + m → Memory Card（C が大文字なので保護される） > > この挙動で問題なければ、以下の方針で実装・テスト更新します。 > > - applyQueryFirstLetterCase は最初に「先頭以外に大文字があるか」を判定し、あればそのまま返す > - それ以外は従来通り先頭1文字だけクエリの大小に合わせる > > このルールで進めて良いですか？ > [!right-bubble] ![[minerva-face-right.webp]] > > Daily Note や Meeting Notes のような「一般名詞だけどタイトルケースで命名したノート」も変更されなくなるので、文中では大文字が残りやすくなります。 > > 英語だとノートのタイトルに記載される表記は各語が大文字になることは多いのでしょうか？ たとえばwikipediaや英語辞書などの各語タイトルはどうなっているのか？ > > 私の趣向より、一般的にどちらのパターンが多いかに迎合したい。 > [!left-bubble] ![[chappy.webp]] > 英語ネイティブではありませんが、一般的なスタイルガイドや慣行としてはこうです。 > > - Wikipedia: sentence case（先頭だけ大文字 + 固有名詞のみ大文字）。Title Caseは基本使いません。 > - 英語辞書: 見出し語は小文字が基本。固有名詞・略語は大文字。 > - 書籍/映画/新聞見出し（特に米国）: Title Case が多い。 > - 技術ドキュメントやUIの見出し: sentence case が増加傾向。 > > つまり「一般的にどちらが多いか」は文脈依存で、 > 参照系（Wikipedia/辞書）に寄せるなら sentence case、 > タイトル系（本/映画/見出し）に寄せるなら Title Case です。 > > 今回のルール > 「先頭1文字目以外に大文字がある場合は変更しない」 > は Title Case/固有名詞保護寄りです。 > その代わり、Memory Card のような一般名詞の Title Case まで保護してしまうので、 > 辞書的（sentence case）にはややズレます。 > > なので、あなたが「一般的な英語の本文表記に寄せたい」なら > 小文字入力時は一般名詞を落とす方針のほうが近いです。 > ただし完全自動で固有名詞を見分けるのは難しいので、 > どこまで誤変換を許容するかのトレードオフになります。 > > この前提で、今の「大文字が内部にあるなら保持」ルールは > “保守的で誤変換が少ない”代わりに“本文の自然さは少し犠牲”という位置づけです。 > [!right-bubble] ![[minerva-face-right.webp]] > 話変わりますが、Custom dictionary complementsの機能では『先頭の1文字のみ、大文字小文字の両方を考慮するようindexing』しています。 > > 個人的な考えでは > > - **一般名詞や動詞**: Custom dictionary に登録される > - Custom dictionary complementsで補完 > - 先頭の1文字のみ大文字小文字考慮 > - **固有名詞や文**: ノートに登録される > - Internal link complementsで補完 > - 先頭の1文字以外も大文字小文字考慮 > > のような利用が多いと予想しています。 > > もともと固有名詞ばかりをノートに登録しているユーザーからすれば、今回の機能はそもそも利用シーンが少ないのではと思っています。なぜなら、固有名詞は Title Case であり、それは文中でもそのまま使われる => `title case` で `Title Case` と補完するからです。 > > また、文をノートに登録しているユーザーの場合、`cat is cute` や `Cat is cute` のようなノートになると考えられます。これを文中に挿入すると > > - **冒頭:** Cat is cute > - `[[cat is cute|Cat is cute]]` に変換される > - **途中:** I think that cat is cute > - `[[cat is cute]]` に変換される > > となり、これも自然です。 > > 一方で、`New York` というノートを登録している場合はどうでしょう。 > > - **冒頭:** New York is ... > - `New York` に変換される > - **途中:** I went to new york > - `[[New York]]` に変換される > - `[[new york]]` に変換してほしいケースはないはず > > Title Case は常にそのままでいい気がします。 > > 1点気をつけるべきポイントは、`can I use ...` の `I` みたいに必ず大文字である非固有名詞(文)の場合の考慮ですね。これが固有名詞と判断されてほしくはないので。 > [!left-bubble] ![[chappy.webp]] > そのルール（「先頭1文字目以外に大文字が含まれている場合は変更しない」）は、提示された新しいテスト群にはきれいに合いますし、実装も簡潔で良いと思います。 > 一方で、Memory Card のような 一般名詞のTitle Case も保護されるので、文中で大文字が残りやすくなる点はトレードオフになります。ここを許容するならこのルールは妥当です。 > > 懸念の I については、次のようにすれば回避できます。 > > - 固有名詞判定の対象から「単語長1の大文字（I/A）」を除外する > 例: can I use は固有名詞扱いにならず、先頭だけクエリに合わせられる > 例: New York は Y が単語長>1なので固有名詞扱いで保持 > 例: AWS Lambda は AWS が単語長>1なので保持 > 例: iPhone は単語内に大文字があるので保持 > > このルールにすると、I は「固有名詞判定には使わない」けれど、出力ではそのまま大文字が残る（今の変換が先頭のみなので）ため、意図通りになります。 > > もしこの方向で行くなら、追加テストの例は以下が分かりやすいです。 > > ``` > ${"can I use"} | ${"c"} | ${"can I use"} > ${"can I use"} | ${"C"} | ${"Can I use"} > ${"Plan A"} | ${"p"} | ${"Plan A"} // Aは単語長1なので固有名詞判定しないかどうかの確認 > ``` > > この「単語長1の大文字を除外」ルールで進めて良いですか？ > （OKなら実装方針とテスト更新のプランを出して着手します） > [!left-bubble] ![[chappy.webp]] > 固有名詞判定のルール（先頭以外に大文字がある場合は変更しない／単語長1の大文字は除外）を applyQueryFirstLetterCase に入れ、テストケースも合意仕様に更新しました。 > > 変更点 > > - src/util/strings.ts に「先頭以外の大文字検出（単語長1は除外）」のガードを追加 > - src/util/strings.test.ts に can I use / Plan A のケースを追加 > > テスト未実行です。 > > 次のステップ案 > > 1. pnpm test -- strings.test.ts > 2. 問題なければ pnpm test > [!right-bubble] ![[minerva-face-right.webp]] > ``` > ● applyQueryFirstLetterCase › applyQueryFirstLetterCase(New York, n) = New York > > expect(received).toBe(expected) // Object.is equality > > Expected: "New York" > Received: "new York" > > 169 | text | expected > 170 | ${"abc"} | ${"Abc"} > > 171 | ${"Abc"} | ${"Abc"} > | ^ > 172 | ${"ABC"} | ${"ABC"} > 173 | ${" abc"} | ${" abc"} > 174 | ${"あいう"} | ${"あいう"} > > at Object.<anonymous> (src/util/strings.test.ts:171:93) > ``` > > ここだけ失敗してます。 > [!left-bubble] ![[chappy.webp]] > New York が new York になっていた原因は、「先頭以外の大文字」判定が“各単語の2文字目以降”だけを見ていたためです。そこで、2語目以降の先頭大文字も「先頭以外の大文字」として扱うように修正しました（単語長1は引き続き除外）。 > > 変更点 > > - src/util/strings.ts の固有名詞判定を修正し、New York の Y も検出対象にしました。 > > テストはまだ実行していません。 > 次のステップ案: > > 1. pnpm test -- strings.test.ts > 2. 問題なければ pnpm test > [!right-bubble] ![[minerva-face-right.webp]] > 実装はOKです。 > > 今回追加した内容を `/Users/tadashi-aikawa/git/github.com/tadashi-aikawa/docs-obsidian-various-complements-plugin` の `docs/` 配下のドキュメントに記載してほしい。 > [!left-bubble] ![[chappy.webp]] > 以下の内容で対応します。進めてよければ「進めて」とだけ返してください。 > > - docs/4. Options/4.7. Internal link complement/⚙️ Preserve first-letter case.md を新規追加し、設定の意味・挙動・例を日本語で記載 > - docs/1. Features/Internal link complement.md の Related Options に新設定へのリンクを追加 > [!right-bubble] ![[minerva-face-right.webp]] > 方針はOKですが『日本語ではなく英語』で記載してください。他がそうであるように。 > [!left-bubble] ![[chappy.webp]] > Internal link complement の新オプションを英語ドキュメントに追加し、関連リンクも追記しました。Since は v10.9.0 としていますが、別バージョンにしたい場合は教えてください。 > > - 新規オプションの説明を追加: docs/4. Options/4.7. Internal link complement/⚙️ Preserve first-letter case.md > - Related Options にリンク追加: docs/1. Features/Internal link complement.md > > テストは実行していません。 > > 次のステップが必要なら教えてください。