リンジーさん、こんにちは。
OPを更新してこれを含めていただけますか？自分でやろうかと思いましたが、失礼かと思いまして。 
「いいね！」 3
リッチエディタを有効にするオプションはどこにありますか？マークダウンにリッチテキストを変換するオプションしか見つかりませんでした。
それで設定が見つからなかったわけですね。
GUIトグルで実験的な機能として移動されるべきです。
「いいね！」 1
作曲家は長い道のりを歩んできましたね。
先ほど、長いレポートを作成するために、コンテンツのコピー＆ペーストや調整をたくさん行いながら、いくつか小さな点に気づきました。
-
リンクを単独の行に貼り付け、その後にテキストを続けると、ワンボックス表示のままになります。リンクを、あたかも行の後半に、いくつかの単語の後に表示されるように、ワンボックス表示を削除する方法はないようです。回避策は、まず後続のテキストを入力してから、行の先頭に戻ってリンクを貼り付けることのようです。
-
テキストを選択してからメニューで「詳細を隠す」を選択すると、テキストが上書きされてしまいます。Markdownコンポーザーでは、選択したテキストが単に非表示になるだけです。（以下のスクリーンキャストを参照してください）
-
ここで再度テストしますが、別のトピックで非表示の詳細を使用した際、トグルは機能するものの、デフォルトで展開されて非表示のテキストが表示されていました。デフォルトでは非表示にしたいものです。
Summary
このテキストを隠したいです
「いいね！」 3
これは「意図的」ですが、混乱を招く可能性があることは理解しています。エディタビューにあるものに従って、bbcodeの open 属性が設定されます。
デフォルトで開く
はい
デフォルトで閉じる
いいえ
「いいね！」 3
ああ、その open という bbcode オプションについては知りませんでした。開いた状態にしたかったことは一度もありません。おっしゃる通りに機能することを検証できます。
「いいね！」 1
投稿が既存のトピックにマージされました：Monospace font in the Markdown-only editor
コンポーザータイプの利用可能性はサイト設定で設定できるのが最善だと思います。そして、両方が有効になっている場合は、ユーザーがユーザー設定でコンポーザーを選択できるようにします。
長期的な機能として、コンポーザーのトグルオプションは望ましくありません。現在メタでのテストには最適ですが、コンポーザーエクスペリエンスの簡素化という目標に反する可能性があります。
「いいね！」 3
リッチテキスト版でいくつか問題点を見つけました。
-
投稿を作成する際に、整形済みテキストを追加すると、次のようになります。
そして投稿すると、次のようになり、一致しないため、良くありません。
少なくともMarkdownでは、シングルクォートまたは3つのクォートで、一行または複数行を選択できます。しかし、モノスペースオプション（私は好きではありません）では、少し競合があります…
-
Markdownを使用しようとすると、この場合、シングルクォートと3つのクォートの間に奇妙な動作が発生します。最初にシングルクォートを使用すると機能し、その後3つのクォートを使用しても機能します。
しかし、すぐに3つのクォートを再度使用しようとすると、次のようになります。
ただし、これは頻繁には発生しないため、原因はわかりません。
-
リッチテキストエディタで、テキストカーソルがフォーマットが適用されている場所にある場合、太字と斜体のボタンが「選択/押された」状態のように見えると素晴らしいでしょう。斜体テキストはより明白ですが、太字はそれほどではありません。しかし、最も重要なのは、テキストカーソルが単語の途中ではなく、その後に配置されている場合です。「入力するとフォーマットされますか？」
-
これは単なる提案ですが、現時点ではコンポーザーが中央揃えになっているのが、私には少し「奇妙」に感じられます。サイドバーと右側のウィンドウの端に揃えられたらどうでしょうか？このような感じです。
私にとっては、他のコンテンツとの流れが良くなるように感じます。
すみません、よくわかりません。
これはまもなく実装されます：
「いいね！」 2
コメントをすべて読んでいないため、すでに述べられていることを繰り返している場合はご容赦ください。
一般的にWYSIWYGエディタは少しぎこちないと感じるので、あまり使用しません。とはいえ、すでに気づいた点をいくつか挙げます。
- Markdownエディタの1回の
Enterキーが2回のEnterキーとして扱われるのは、少し違和感があります。このアプローチは初めて見たわけではありませんが、Markdownエディタとリッチエディタを切り替えられる場合、一貫性のなさが混乱を招く可能性があります。すべての人が、Markdownエディタでの1回のEnterと同じように機能するShift + Enterがあることを必ずしも知っているわけではありません。 - ヘッダーセクションを作成し（例：
#の後にスペースを入力）、いくつかの文字を入力してからそれらの文字を削除すると、理由もなくスクロールバーが上にスクロールします。これは、エディタが一番下までスクロールされている場合にのみ発生します。 - バッククォートを逆順に追加できることは非常に重要です。単語をすべて入力してからフォーマットのためにバッククォートを追加することを決めることは珍しくありません。場合によっては、先頭のバッククォートを追加する前に末尾のバッククォートを追加する方がはるかに簡単です。これは現在、リッチエディタでは機能しません。Microsoft Teams（ひどく実装されたWYSIWYGエディタの例です）でこの問題に何度も遭遇しており、非常にフラストレーションが溜まります。
- 番号付きリストまたは箇条書きリストを操作しているときに、カーソルがリストの終わりの行にある場合、
Backspaceキーを押すと新しいリストアイテムが追加されます。これは問題というわけではありませんが、少し予期せぬ動作です。 - コードフォーマットされたテキスト（バッククォート）とそうでないテキストを混在させて作業している場合、すでに書いたものを編集する際に、フォーマットされたテキストの直後にプレーンテキストを入力することは不可能です。これは一般的なケースではありませんが、時々発生します（例：変数名をフォーマットするが、複数形のために
sや、その直後にアポストロフィが必要な場合。これも一般的ではありませんが、複数回遭遇しました）。 - どのフォーマットオプションがアクティブであるかを示す表示がありません。ヘッダーのような一部のものは、カーソルのサイズに基づいてある程度明らかですが、太字、イタリック、コードフォーマットのような他のものはそうではありません。これは私にとって一般的なフラストレーションの原因となっています。なぜなら、何かを入力してから、後でフォーマットを修正したり削除したりする必要がある可能性があるからです。私がちょうど遭遇した具体的なケースは、フォーマットされたコードを入力してから、何を書くか考え直したのでそれをすべて削除したことです。その後、別のバッククォートを追加してフォーマットされたコードで何かを書き込もうとしましたが、すでにそのモードにあったため、実際にはバッククォート文字を入力したいと考えていると判断し、バッククォートが表示されました。
「いいね！」 7
再現できなかったので、おそらくバグだったのでしょう。あるいは、そのように動作するために特定のことが起こる必要があるのかもしれません。基本的に、ご覧のとおり、3つのティックはテキストとして、シングルティック内でレンダリングされ、そのため背景が暗くなりました。次に、前のもの（シングルティック内でテキストとしてレンダリングされた3つのティック）のすぐ下に3つのティックを追加すると、コードブロックが期待どおりに作成されました。これで意味が通じましたか？
また、リッチテキストモードでのマークダウンが期待どおりに機能しないことにも気づきました。シングルティックがテキストに影響を与えない test の例をご覧ください。しかし、3つのティックは機能しています。
エディターはこのオプションについて比較的意見が分かれています。例えば、Google DocsではEnterキーは改行ですが、NotionではEnterキーは段落区切りです。ただし、マークダウンモードとリッチテキストエディター間の一貫性に関するあなたの指摘はもっともだと思います。
あなたの現在の手順では再現できません。ブラウザの詳細と、より詳細な手順または録画を提供していただけますか？ありがとうございます！
エディターでのインラインコードの動作について、この問題を解決するいくつかの修正に取り組んでいます。
よく気づきました。それは予期せぬ動作であることに同意します。修正のためにチームに報告します。
これについては取り組んでいます！
「いいね！」 5
そして、ディスコースにはその 2 つのモードを切り替える設定があります。「Traditional markdown linebreaks」は「Markdown で従来の改行を使用します。改行には末尾に 2 つのスペースが必要です。」という意味です。したがって、両方のエディターがこの設定に従うべきだと思います。
「いいね！」 4
見つけるのが困難になり、5回見つけてもまだ覚えていないので、自己責任でという注意書きとともにOPに追加しました。
「いいね！」 4
この新しいコンポーザーで shared-edits プラグインの既知の問題を再検討する予定はありますか？機能不足（他の人の編集カーソルを表示する、グループベースで機能を有効にするなど）と堅牢性（例：Shared-Edits Improvements - #18 by Ralf_Stockmann を参照）の両方についてです。
「Nice」な共有編集のために、HedgeDoc のような個別の「Etherpad」サービスをインストールするのを避け、代わりにイントラネットに Discourse ベースのソリューションを使用できることをまだ願っています。
また、y.js に基づいて、ゆるやかな同期だけで「オンザフライ」の共有編集エクスペリエンスを提供する新しいプラグインを書くことも検討しています…
「いいね！」 4
「計画」段階というよりは「夢」段階と言えるでしょう。ProseMirrorとリッチテキストエディタは多くのことを可能にしますが、私たちは主にMarkdownのみのコンポーザーとの機能同等性を高めることに注力しており、それをお客様に展開し始めることができます。しかし、それは私たちの念頭にあり、そこには改善の余地がたくさんあることを私たちは知っています。
「いいね！」 6
ラルフ、私も同感です！これはまさに「サクランボのトッピング」のようなもので、新しいコンポーザーが非常によく定着するまで開発するのはあまり楽しくないと思います。
将来的には、公式の ProseMirror bindings for Yjs を使用することを（計画ではなく）夢見ています。その作業の大部分は、MessageBus 用の Connection Provider | Yjs Docs を構築することになるでしょう。
「いいね！」 8
これらの夢を具体的な計画に変える方法を見つけられるかもしれません。私は真剣な資金提供を喜んで行います。Discourse には、プロフェッショナルなイントラネットでの使用に関していくつかの問題点があります（プッシュ通知の安定性もその一つです）が、Atlassian Confluence のようなものに投資するよりも、このオープンソースプロジェクトにお金を投資する方がずっと良いでしょう。
「いいね！」 12