ドキュメントでバッククォートでフォーマットされた /commands を文書化しました。しかし、「commands」を検索しても結果が表示されません。トピックが表示されるためには、検索は /commands である必要があります。
これは意図された動作ですか？ユーザーが / を先頭に付けた特定のコマンドを検索するとは思いません。どちらでもトピックが見つかるはずです。
編集：コードフォーマットは関係ありません。「/commands」だけで同じ問題が発生します。
編集2：例えば「.command」ではこれを再現できません。「command」を検索すると、この場合は期待どおりの結果が得られます。
希望的な進捗報告です。
「検索」関連の設定を探しましたが、明白なものは見つかりませんでした。何を探せばよいか、何かヒントはありますか？
いいえ、これは想定される動作だと思います
はい、ユーザーがこれを見つけるために「/」を含める必要があることを事前に知っているとは思いません。この動作が予期されている理由、または可能な回避策はありますか？私のドキュメントの検索可能性に深刻な影響を与えるためです。
検索は複雑な問題です 
これを検索させたいが、もし「コマンド」という単語を含む他の異なるドキュメントがあり、「/コマンド」という単語を含むドキュメントをこの場合は表示させたくないとしたらどうなるでしょうか？
使用できるトリックの 1 つは、投稿にキーワードを含めることです。
<small>キーワード: コマンド</small>
確かに複雑ですよね！ /commands は一例ですが、おそらく100以上のコマンドを文書化しています。そのため、キーワードを使用することも代替案になり得ますが、理想的ではありません。
単語が見つかれば、検索に表示されるはずだと理解しています。例えば：
/testcommand > query: testcommand > 
betacommand! > query: betacommand > 
!betacommand > query: betacommand >
ここで「/」と「!」の違いは何でしょうか？
これは、データのインデックス作成方法によるものです。
「test /command」 → 「‘/command’:11 ‘test’:8A,10 ‘titl’:4A ‘uncategor’:9B」
「test !command」 → 「‘command’:11 ‘test’:8A,10 ‘titl’:4A ‘uncategor’:9B」
2番目のケースで「!」が失われていることに注意してください。句読点は検索において関連性がないと判断しました。
なるほど、私の意見では / も関係ないはずですよね？インデックス作成がどのように機能するかはわかりませんが、これを変更する設定があれば、私にとって非常に役立ちます。
「somequery」が URL の一部としてフォーラムのどこかに存在する場合、結果 https://domain.com/somequery-article-today が返されることに気づきました。これは期待される動作です。これらがどの程度関連しているかはわかりませんが、この場合 / が関係ないのは興味深いと思いました。
さらに詳しく調べて気づいたもう 1 つのことですが、スラッシュで区切られた文字列があります: query1/query2。
query1 は結果を返しますが、query2 は結果を返しません。これも期待される動作と言えるでしょうか？私に言わせれば、それはバグのように思えますが… 
これも検索に大きく影響するとまだ信じているので、再度投稿します。最近私が抱えている不便な点のいくつかです。
GitHubリンク > ユーザー名もリポジトリ名も検索できません。
Xリンク > ユーザー名は検索できません。
他にもたくさんの例があります。検索をあまり利用しない人には、これらの点は見過ごされるかもしれませんが、検索で見えるものだけでなく、見えないものにも影響します。トピックが見つけやすいようにキーワードが必要かどうかを常に考える必要はないはずです。
これは、特にドラフト/スタッフセクションでは顕著です。投稿がまだ完了していなかったり、何年もそこにとどまっていたり、コミュニケーションが短く内部的な形式であったりします。この投稿は、Discourseが関連性がないと判断したため、キーワードのスタッフと内部を追加しなければ見つけられなかったでしょう。なぜでしょうか？
これがバグではないとほとんど同意できません。むしろ、検索インデックスの決定としては非常に珍しいアプローチです。
今日行ったいくつかのテストから、これは修正されたようですが？意図的なのかどうかはわかりませんが、ありがとうございます！
編集；やっぱり…同じ動作です。 
これは実際にはPostgreSQLのstemmer/tokenizerの動作方法です。URLのようなエッジケースに対しては混乱を招く可能性があるため、いくつかの回避策を実装していますが、全体としてはこれらの多くの処理をpgにアウトソースしています。
興味深いことに、数年前には「URLでの追加インデックス作成」のためのハックがありましたが、@tgxworldがインデックスの肥大化を理由に削除しました。
検索におけるこれらのエッジケースについて考えているということは言えますが、pg fulltextの既存のフレームワークを回避するようなハックを実装するには、かなりの労力がかかります。
サム、ご返信ありがとうございます！
これが複雑な技術であることは理解しております。皆さんがいつか良い回避策を見つけられることを願っています。それまでの間、私はこの制限を回避するために、隠しキーワードやクリエイティブな方法を工夫して使用しています！
最初級の市民として隠されたキーワードが面白いと思います
