コメントを検索する機能を要望したけど，スルーでした。

何千件もコメント書いてて，その中には（自分的に）けっこう重要で，しかもあとで参照したいものがいくつもあるんですが，どの記事にそれを書いたのか思い出せない。
せめて自分のコメントだけでも検索可能だったらありがたいんですよね。

いろいろと思いつくたびにご意見フォームから送っているのですがたぶん直接反映されたことはないですね。
「あった方がいい」レベルの提案だと片っ端から実装するのもサービスの規模感上難しいでしょうから、いろいろな意見を吸い上げた上でサービスの利便性が上がる結果になればいいなくらいの感じで送っています。

スタイルシートについての以下の二つの問題について指摘しましたが，一向に直りませんね。

一つは，インラインでバッククオートを使うとリンクがリンクだと分からなくなる問題。
例えば Ruby に Enumerable#sort_by というメソッドがあります。このメソッド名は今バッククオートで囲っています。
公式リファレンスへのリンクを張りたいと思って

[`Enumerable#sort_by`](https://docs.ruby-lang.org/ja/2.7.0/method/Enumerable/i/sort_by.html)

と書くと，「Enumerable#sort_by」みたいな体裁になります。さっきと同じですよね。リンクであることが全く分からない。
マウスをかざすと下線が出ますけど。

仕方がないので，リンクを張りたいときだけバッククオートで囲まないで「Enumerable#sort_by」としています。

もう一つもやはりバッククオートによるコードの表示の問題ですが，以下の表を見てください。

これ，「open」と「close」はいずれもバッククオートで囲っています。
しかし，「open」のほうは表の行の背景色に溶け込んでしまって，コードであることがわかりません。

私は，少なくとも前者は深刻な問題だと思います。
いずれもスタイル設計ができれば修正自体は簡単だと思うんですけどねえ。

コメント検索機能ですね。
コメントには様々な知見が埋め込まれているのに、検索できないのはもったいない。
知識を売りとしたサービスでいまだにコメント検索できないのは何故なのか、とは思います。

Qiitaは検索機能が弱いですね。
自分はesa.ioも使っていて、そちらだと様々な検索ができて便利です。
非公開の記事についてはesa.ioを使います。公開記事はQiitaを使っていますが、esa.ioが公開記事をQiitaほど便利にしたときには利用変更も考えるかもしれません。

なんだかんだで Qiita は好きだし、助かってるので、思いついた時に「ご意見」申しあげています。ただ「返信は行ってない」と書かれているので返信も期待していません。

それでも気をつけている点は、稟議にあげやすいように要望を書いています。概要、考えうる要因、提案・改善案、謝辞といったところでしょうか。（たぶん「まぁーた、長いの来たよ」と担当さんからは思われていると思いますがw）

私も、検索機能強化は重要な課題だと思います。

Qiita の検索機能より Google 検索で Qiita のサイトに絞った方が精度が高いのですが、逆に言えばクロールされていない記事はヒットしません。

スパム投稿にはウェーブがあり、その時間帯の正常な投稿もクロールから削除される傾向があると感じています。そのため Google 検索も万全ではありません。

過去の良記事（LTGM 数でなく内容として良いもの）を掘り起こしやすく、そしてさらにブラッシュアップされた記事ができることが、Qiita 資源の有用な再活用だと思うからです。このままではジリ貧になるのでは、と肌でしっとりと感じる今日この頃です。夏だからでしょうか。

@ycv57u6y さん，なるほど，<code> </code> で囲むという手があったのですね。
「sort_by メソッド」みたいにリンクテキストの一部をコードにしたいときは使えませんが，当面はそれでいくしかないのかなあ。

指摘していたテーブルの崩れも１年後くらいには改善されたし、ゆっくりであっても改善はされているので、要望をあげていくのが近道なんでしょうね。

インラインコードのリンクは、私も「読者さん見つけづらいだろうなぁ」と思ってました。

タグでの対処治療は有効ですが、いざ記事の引っ越しが必要になったときにも困るので Markdown で完結したいところですよね。

Patreon なりで支援ユーザー募って、サポーターはタスクの優先リストが見えるとかだといいのに。

コメント検索、今はGoogle検索を駆使して代用しているけど、やっぱり完全にはうまく行かないのでほしいよなぁ・・・。
ナレッジ共有サービスは検索できてなんぼな側面はあると思うので。

Qiita > 要望 > コード左側に行番号を表示
https://qiita.com/7of9/items/e65f2f36c817ab965284

28LGTMしかないから多くの人の要望ではないのですが。
自分としてはあるといいな、と思っています。

PS.
ガイドラインに「Qiitaへの意見は記事でなく問い合わせにして」とあるので、Qiitaに関する記事はもう書いていません。

要望タグ
https://qiita.com/tags/%e8%a6%81%e6%9c%9b

@yumetodo さん

ナレッジ共有サービスは検索できてなんぼな側面はあると思うので。

それ，それ，まさにそれ！

@7of9 さん

私もサイトがQ&Aに対応したので、ソースコードに行番号を表示して欲しいという要望をごく最近出しました。
以下がQiitaからの回答になります。

ご意見をお送りいただきありがとうございます。
行番号の表示は過去に検討したのですが、下記の理由より実装に至っておりません。

• GitHubでは指定行数番目へのリンクが便利であり、ファイル閲覧ページのみコード行番号がついているが、Qiitaの記事においては利便性が無い
• dev.to や Github Issue ページ内においても、コードブロックには行番号が無い
• 不要なコード行番号によって視認性が悪い（シンプル性が無くなる）
• コードブロックが大量にある記事の場合、JSの処理の負荷が相当掛かる

多くのユーザー様から行番号の表示をご希望いただいた場合は再度検討いたします。
なお、質問機能についてはまだベータ版ですので、通常版に反映後同様のご意見が出るかどうかの様子見もさせていただければと思います。

どうぞよろしくお願いいたします。

個人的には、今まではあれば便利くらいな感覚でしたが、Q&Aになると質問者と回答者のやり取りで必須だと思います。

みなさんはどう思われるでしょうか？

私はソースコードの一部を強調する機能を願っていましたが、残念ながら追加されないみたいです。
しかし、この質問機能が追加されたため、それ以上にうれしい結果です。

@takahasinaoki

Q&Aになると質問者と回答者のやり取りで必須だと思います。

私も、回答者の無駄を少なく、的確な指示をするには必要だと思います。コピペピピックでわけわかめな内容にならないためにも。

• dev.to や Github Issue ページ内においても、コードブロックには行番号が無い

上記運営さんの言い分ですが「Github がそうだから」と引き合いに出すのもちょっと違う気がします。

GitHub Issue の場合、「コードブロックに行番号は必要ない」のではなく、コミットの URL を貼り付けると、コードスニペットが表示され行番号が表示されるから必要ないだけですよね。

例えば、以下の URL を開くと指定行が色付き（ハイライト）になります。

これを Issue もしくは Issue のコメントに貼り付けると行番号のスニペットが表示されます。

例えばこんな感じです Issue に行番号付きで表示されているのがわかると思います。

この「URL 先が gist や GitHub のコミット URL だったらスニペットでコードを表示する」だけでも変わると思うんですがねぇ。

２年くらい前に同じ「ご意見」をしたのですが、どうなんでしょう。

質問・応答のやり取りで行番号が必要，というのはなるほどと思いました。
ただ，ここで悩ましいのは「コードを書き換えちゃうと行番号がズレる」問題にどう対処するかですね。

現状でも，記事の著者がコメントを受けて記事のコードをどんどん書き換えちゃうので，あとから見に来た人がコメントの意味を理解できない，という問題があるんですけどねえ。

競合サービスであるteratailでそれなりの件数回答している身として発言します。

行番号

自分は行番号はいらないと思っています。 @KEINOS さんの言ってるGithub Issueにコード埋め込みしたら行番号出るやんけ、というのはあくまで特定のcommitを指しているからこそできる話であって、Yahoo!知恵袋と違い質問文を編集できる以上は使い物にならないと考えます。

なんなら質問者のリテラシーが下がっていったとき、質問文をまるごと消すとか、全く別の質問に書きかえるなんて行為を想定するべきです。現実にteratailでは規約違反にも関わらず発生しています。まああれは運営がやる気がないからなめられてる面もありますが・・・。

欲しい機能

それよりも欲しい機能があります。

1. 質問文の編集機能

これはStackOverflowのようなシステムではなくて、編集リクエストに一定数のvoteが付いたら反映されるようなものをイメージしています。質問者は適切に質問文を書けるという仮定が誤りなのはYahoo!知恵袋やteratailを見ても明白です。一方で質問文書き換え攻撃のリスクを考える必要があります。かといってStackOverflowのようなシステムは十分なユーザー数なしには実現しません。編集リクエストを発展させるような解が適切と考えます。

2. 質問を作りやすくするStep-by-Stepの入力補助システム

teratailだと

こんな感じのテンプレートがありますが、割と多くの人がこれをうまく使えていません。そもそも質問者にMarkdownを適切に使えるリテラシーを要求するのが間違いなわけです。Step-by-Stepでフォームに入れていくといい感じのMarkdownが吐かれるようなシステムが必要です。

行番号

• 悩ましいのは「コードを書き換えちゃうと行番号がズレる」問題にどう対処するか
• Yahoo!知恵袋と違い質問文を編集できる以上は使い物にならない

やはり「編集できる」というところがネックでしょうね。既存のコードブロックは維持させて、リンクが GitHub の特定コミットの場合はスニペットで表示する、くらいが妥当な線かもしれませんね。

質問文の編集機能

「タイトルから内容が判断できないタイトル」付け、「問題のあるコードをドバッとコピペ」して再現性のある形でシンプルなコードで提示しない、といった「あるある」に対して、質問そのものをブラッシュアップできた方がいいのには賛成です。

私の中で Qiita が Qiita らしいのは、聞いたり調べたりした結果を一旦咀嚼そしゃくして「記事として吐き出すことで消化している」ことだと思っています。

そのため、Q&A 自体はいいのですが、やはりそこで得た意見・知見などから、最終的に「質問者が咀嚼した内容を記事としてまとめられる導線が欲しい」という要望は出しました。

こんなイメージ。

どの Q&A サイトでもそうですが、「聞いたら聞きっぱなし」「お礼しない」「その後の結果を報告しない」ことが多くあります。そのため、適切なアドバイスであったか、わからないのです。回答者としての質の向上にも繋げられません。

質問者は「質問のプロ」ではないし、回答者も「回答のプロ」ではありません。

しかし**「編集できる」というのは、質をレベルアップさせることができるということ**でもあります。Q&A が記事につながるなら、質問者も回答者もレベルアップできる可能性があり、Qiita のコンテンツのポテンシャルになると思っています。

他の Q&A サイトにはない、「閲覧者の時短」「情報のクオリティ」「情報量」が Qiita が生き残る道だと思います。（これには検索強化も含む）

といった要望も出しました。

結局、運営からのレスポンスなんでしょうか。Q&A の正式リリースのように「いま●●●に取り組んでますよー」的なものがあれば、ユーザーも「（あーそれは大変だわ。わかるわかる。頑張れっ）」と思えるのかもしれません。

@takahasinaoki さん

行番号！ これ、私も質疑応答になった場合にソースの特定の場所を指し示すのに断然便利だろうと思っていて、teratailでも提案してみたことがあります。

ところが予想に反して、他の人の反応はあんまり芳しいものではなかったんですよね。

コードを示す際に行番号が使えたらいいと思いませんか？｜teratail

qiitaは質疑応答がメインではないので、なおさら優先度は下に位置付けられてしまうかもしれません。

でもやっぱりあったほうが便利だと私は思います。あとで本文を編集されるとズレるというのが主流の反論のようですが、それは行番に限らずあらゆる編集に付きまとう問題で、それを反論材料にするのはちょっと違うんじゃないかと思うんですがね。

それは行番に限らずあらゆる編集に付きまとう問題

確かに。Teratail に限らず StackOverflow でも「何かコメント、とんちんかんなこと言ってるな」と思ったら、質問者が質問内容を書き換えてたことは多く見かけますものね。

行番号欲しいですが「なくても大丈夫だけど、あったら便利なもの」なので、やっぱりプライオリティ低めなのかもしれませんね。(´・ω・｀)

行番号

行番号と一緒にDiff差分のように変更箇所も表示できれば、後から閲覧した方でも「行番号がズレてる」事を認識できそうですが、システムでやるにしろ執筆者がやるにしろコスト掛かりそうですね

大事なことを思い出した。

編集リクエストを送るとき，念のため他の人が既に同じ内容を送ってないか確認したいことがありますよね。
そういうとき，記事の右上の「…」をクリックしてメニューを出し，「編集リクエスト一覧」にジャンプします。
確認後に編集リクエストを作ろうと思っても，そのページから直に行けません。
いったん記事に戻って，あの小さい「…」から「編集リクエストを送る」とやらなくちゃいけない。
め，めどい！

「編集リクエスト一覧」ページに「編集リクエストを送る」ってリンクを置くだけなのに，要望は採用されませんでした。

風呂に入るのに，居間から「脱衣室」に行って服を脱ぎ，また居間に戻って，それから反対側にある風呂に行く，とかいう家があったら「どんな家やねんっ！」と思いますよねえ。

Qiita API v2に指定されたユーザのlgtm一覧を返すAPIがありません。
ウェブページをスクレイピングしてlgtm一覧を取得していいか問い合わせました。

サーバーの負荷上昇への懸念からQiitaへのスクレイピングは許可していない、
APIで出来ないから問い合わせてるのにAPIで出来る範囲で利用するように回答が来て
このタイトルのように昨日は少しでした。
今後要望が多く寄せられた場合にはAPIでも出来るように検討されるそうです。

まあ意図として後で見たいものはストックしてくれってことなんだとは思いますが・・・。