kemitchell
(Kyle E. Mitchell)
1
現在の Markdown タイポグラファ（「スマート句読点」とも呼ばれる）の設定を調整して、引用符やダッシュなどの Unicode 句読点記号を有効にしつつ、(c) や ™、およびそれと同種の他の特殊なグリフは無効化することは可能でしょうか？
私は弁護士です。商標や著作権について、Discourse フォーラムを含むあらゆる場面で助言を行っていますが、これまで著作権記号や商標記号を追加するために投稿を修正するよう助言したことはありません。また、法律の専門でない人々は、これらの記号がどれほど有用または必要であるかを過大評価する傾向があります。逆に、私が編集した投稿は数えきれないほどありますが、その多くは Markdown レンダラーが © 記号をレンダリングしないように「工作」するために行いました。
この問題は、特に箇条書きリストで頻繁に発生します。例えば：
(a) りんご
(b) バナナ
(c) 著作権？
(d) デート
このような箇条書きの形式は、法律、契約、ポリシー、および法律様式の影響を受けたその他の正式な文書で非常に一般的です。また、非常に一般的なアウトライン形式でもあります。これは、私が米国で小学校時代に習った「標準的な」アウトライン形式の一部でした。
現在の設定では「句読点」に関する柔軟性が提供されていますが、私が知る限り、スマート句読点を有効にしつつスマート記号を無効にする方法はないようです。
「いいね！」 9
これについては特に強い意見はありません。著作権記号を入力する「必要性」は非常に稀なので、このショートカットを削除しても問題ないと思います。極めて稀な有用性と、やや一般的だが見栄えの悪い (a) (b) (c) という形式のバランスを考えると、@sam さん、この特定のショートカットを完全に削除することに賛成です。
「いいね！」 6
kemitchell
(Kyle E. Mitchell)
3
単に (c) を削除することに賛成です。
「著作権記号」と検索してコピー＆ペーストするのは簡単です。ネットリテラシーの高い人なら \u0026copy; と入力できます。
使いやすさの観点から言えば、すべての展開例をリスト化すべきだと考えます。それらは役立つというより、むしろ驚きを与える可能性が高いと強く疑っています。
「いいね！」 5
さて、これについては、メリット（ごくごくわずかなもの）がリスク（かなり大きいもの）を上回るようです。
「いいね！」 5
sam
(Sam Saffron)
5
この設定の柔軟性は高くないようです。この柔軟性をサポートするには markdown.it をパッチ適用するか、markdown.it をベースに独自に prettify を実装する必要があります。
唯一の簡単な対応策は、この機能全体を無効化することです。
「いいね！」 5
ふむ、全く設定できないなんて奇妙ですね。残念です。なので
(c) (tm) (r) (p) → (c) ™ (r) (p)
「いいね！」 3
sam
(Sam Saffron)
7
良い点は、エンジンが非常に設定可能であることです。markdown.it のルールを無効にし、コードをコピーして、@Roman が実装したように独自のリプレイスを実装できます。
これを整理するための数日間のエンジニアリングは惜しいですが、フォークする場合は同じコードを二度配送せざるを得ない状況です。
「いいね！」 3
kemitchell
(Kyle E. Mitchell)
8
markdown-it の master ブランチにおけるコミット 7b8969ce5cb2edc54f2c1aa39a85a3a08076337d 時点では、関連するソースファイルは lib/rules_core/replacements.js、関連するテストフィクスチャは test/fixtures/markdown-it/typographer.txt です。
すべての置換はハードコードされています。これには、スコープ付き省略形としてグループ化されている (c) → ©、(tm) → ™、(r) → ®、(p) → ℗ が含まれます。
参考までに申し上げますと、§ に対して (p) が出力されることはありません。これはおそらく ℗、すなわちフォノレコード記号であるべきでしょう。
少しこの問題を掘り下げて、「typographer」機能をより設定可能にするパッチを作成できないか試してみます。
「いいね！」 7
HAWK
(Hawk)
9
これには私もうんざりします。少なくとも週に一度は遭遇します。
「いいね！」 9
kemitchell
(Kyle E. Mitchell)
10
「いいね！」 7
kemitchell
(Kyle E. Mitchell)
11
「いいね！」 3
kemitchell
(Kyle E. Mitchell)
12
メンテナーの対応は非常に迅速で、私のプルリクエストは数分以内にクローズされます 
私が読み取れるのは、彼が破壊的変更を非常に、非常に嫌っているということです。メジャーバージョンの更新時であっても、(P) が § としてレンダリングされるようなケースであっても同様です。また、typographer: true が機能し続ける場合であっても、複雑さが増すと見なされるため、typographer: {A: true, B: false} のようなスタイルのオプションを認めることにも強い抵抗を示しています。
行間を読む限り、彼は英語で書くロシア人ですが、markdown-it は「完成されたもの」と見なしているように感じられます。
感謝を込めて申し上げますが、実装をフォークし、ES モジュールとして書き直し、現在バンドルされているプラグイン的な機能（リンキフィケーションと置換、タイポグラファーの句読点置換を含む）をすべて削除することを検討する価値があるかもしれません。
「いいね！」 3
kemitchell
(Kyle E. Mitchell)
13
メンテナーは、バンドル内の重複コードに関する点数付けには関心を持っていません。また、「100% のユーザーに必須」であったりプラグインの実装を阻害したりしない限り、API の非破壊変更に対しても関心を持っていません。これはある種の板挟みを生みます。なぜなら、リンク化やスマート句読点のための非常にプラグイン的な 2 つのサブモジュールを配送しているからです。その哲学によれば、これらは本来、それぞれ独立した小さな npm パッケージとして提供されるべきものです。しかし、現実はそうはなっていません。
参考までに、markdown-it には比較的近い過去に大きなリリースがありました。特に、昨年の 11 月に Alex Kocharin によるパフォーマンス向上が顕著でした。
(c) の修正、(p) への対応、そして矢印などの他の処理を行うには、最も確実な方法は、コアからリンク化とスマート句読点のサブモジュールを削除し、Discourse 側でプラグインとして読み込むパッチを提案することです。GitHub Action や cron ジョブを使用して markdown-it の master ブランチを監視し、自動リベースを試行します。メンテナーがこのように変更に対して保守的であり続ける限り、そのパッチは相当長い間きれいに適用されるはずです。CommonJS ではなく ES モジュールへの書き換えのような大きな飛躍をしない限り、ですが。
「いいね！」 6
sam
(Sam Saffron)
14
内部で議論した結果、typographer をハードフォークすることになりました。
基本的には markdown.it 内の typographer を無効化し、Discourse 内でその実装をコピーして導入します。markdown.it は非常に拡張性が高いため、これは主に「コピー＆ペースト」で済みます。
コピー＆ペーストが完了したら、テストを追加し、いくつかのルールをカスタマイズして変更していきます。
「いいね！」 9
Lorthirk
(Claudio Mezzasalma)
15
こんにちは、この話題を持ち上げてすみません。... -> … を無効にする方法を探しているので、この機能の進捗状況や、将来的に個別のルールを有効・無効にできるかどうか知りたいです。
ありがとうございます！
「いいね！」 2
sam
(Sam Saffron)
16
これはサイト設定です。タイポグラファーを無効にするだけです。
「いいね！」 2
Lorthirk
(Claudio Mezzasalma)
17
ええと、それ試したんですが、どうやら動いていないようです。タイポグラファーを有効にしても無効にしても、置換は常に実行されてしまいます（それに、(c) もどうやら機能していないようです）。
「いいね！」 2
sam
(Sam Saffron)
18
対象の投稿で HTML を無効化し、その後再構築してください。
「いいね！」 5
