Wäre es schwierig, den Standard-Post-Editor textarea durch einen Markdown-Syntax-Highlighter zu ersetzen?
Oder übersehe ich die Option irgendwo?
Sie haben dies bereits wunderschön für CSS im Admin-Stil-Editor implementiert:
3 „Gefällt mir“
Wird das nicht bereits durch die Verwendung des Codeblocks erreicht, der Ihnen Syntaxhervorhebung im Vorschaufenster bietet?
1 „Gefällt mir“
Das ist eine interessante Idee. Das Ziel wäre, eine Syntaxhervorhebung im Textfeld (d. h. auf der linken Seite des Komponisten) zu haben, damit man sehen kann, ob man Fehler in der Markdown-Syntax macht. Ja, Codeblöcke machen dasselbe in der Vorschau, aber man sieht keine Markdown-Fehler, zum Beispiel. Und einige komplexe Markdown-Elemente wären leichter zu scannen, Beiträge mit vielen Tabellen, Uploads, Links, Überschriften.
Ich bin mir jedoch nicht sicher, ob das einfach zu machen ist. Unsere Admin-Bildschirme verwenden den ACE Editor, und ich glaube nicht, dass wir den einfach in den Beitragseditor ziehen und ablegen können.
4 „Gefällt mir“
Ja, das ist genau mein Anwendungsfall.
Es gibt ein sehr direktes Feedback zu Ihrer Syntax: Sie müssen nicht alle paar Sekunden in die rechte Seitenleiste schauen, um zu prüfen, ob Sie keine trivialen Syntaxfehler machen.
Es würde etwas mehr Struktur für diejenigen bieten, die mit Markdown weniger vertraut sind (für jeden Anfänger).
Natürlich haben Sie auf der rechten Seite des Composer-Fensters immer noch das gerenderte HTML.
Ich sehe keine unmittelbaren Nachteile, besonders wenn es eine Option ist.
PS: Anscheinend ist nicht einmal ein Markdown-Syntax-Highlighter für Codeblöcke installiert 
:
# Markdown-Codeblock-Syntax...
... leider ...
- ist
- nicht
- hervorgehoben
**überhaupt nicht**!
EDIT 2 Stunden später: Behoben von @pmusaraj
4 „Gefällt mir“
Oh, gut bemerkt! Es sieht so aus, als würden uns einige Stile für den Markdown-Highlighter fehlen.
2 „Gefällt mir“
Ist die Verwendung eines vollwertigen Editors für „nur“ Markdown nicht ein bisschen übertrieben?
Meiner Meinung nach ist die Verwendung eines Markdown-Semi-WYSIWYG-Editors besser auf die Bedürfnisse des OP abgestimmt, wie zum Beispiel https://ui.toast.com/tui-editor, Playground | Milkdown usw.
3 „Gefällt mir“
Die beiden sehen großartig aus!
Ich könnte mir jedoch vorstellen, dass das einfachere Milkdown besser geeignet wäre, da es in Ordnung ist, wenn der Editor ein eher „Unterwasserbildschirm“-[1] Gefühl vermittelt, da Sie die Vorschau sowieso auf der rechten Seite haben.
Ja, ich erinnere mich lebhaft an WordPerfect
↩︎
3 „Gefällt mir“
Ja, jeder von ACE, TUI, Milkdown wäre eine sehr große Änderung, sie alle müssten die Textarea durch contenteditable ersetzen. Sicherlich ein Experiment wert, aber im Kern ein großes Projekt.
4 „Gefällt mir“
PR ist mit einem Fix für das fehlende Markdown-Highlighting verfügbar: UX: Update highlight.js styles by pmusaraj · Pull Request #23999 · discourse/discourse · GitHub
6 „Gefällt mir“
Nur um das zu erweitern, erstens, dass dies etwas ist, das ich wirklich im Kern unterstützt haben möchte, aber auch erwähnenswert ist, die Komplexität zu erweitern.
Der Discourse-Kern verwendet viele, viele APIs direkt gegen TEXTAREA, @mentions, die Werkzeugleiste fügt Dinge in die TEXTAREA ein, Uploads, Ausschneiden und Einfügen von Bildern und mehr.
Dies ist alles nicht abstrahiert und geht davon aus, dass es mit einer TEXTAREA spricht. Das direkte Hinzufügen eines contenteditable dort würde bedeuten, dass es auch eine TEXTAREA richtig und sehr genau simulieren müsste, etwas, das wahrscheinlich fehlschlagen wird. Wir brauchen eine beträchtliche Menge an Arbeit, um eine Art Provider-Framework zu erstellen, damit wir Dinge austauschen können.
Siehe auch:
Highlighter ist sicherlich ein großartiger erster Schritt in diese Richtung, da Sie sich keine Gedanken über die bidirektionale Abbildung von Markdown zu Text machen müssen.
Es mag einen Ninja-Hack geben, bei dem Sie die TEXTAREA ausblenden und dann ein contenteditable darüber rendern können, wobei Ereignisse an das Original weitergeleitet werden, aber selbst das würde eine Neuimplementierung der @mention-Positionierung erfordern.
9 „Gefällt mir“
Ich muss hier ehrlich sein: Jetzt, wo ich den Trello-Editor gesehen habe, fühlt sich Discourse in Bezug auf den Editor ein wenig nach 2000er Jahre an:
Ich denke, so etwas ist wichtig.
Hinweis: Es akzeptiert immer noch zu 100 % die Markdown-Syntax.
1 „Gefällt mir“
Persönlich bin ich kein Fan davon. Er ist viel zu überladen. Ich liebe es, dass der Editor in Discourse visuell sauber ist. Alles, was ich wirklich sehe, ist Text, und das gerenderte Zeug ist an der Seite, wo es hingehört.
Zurück zum Hauptpunkt der Syntaxhervorhebung: Das ist etwas, das ich mir auch sehr wünschen würde. Zumindest würde ich mir wünschen, dass # Überschriften und ## Unterüberschriften auf irgendeine Weise hervorgehoben werden. Ich kann Ihnen gar nicht sagen, wie oft ich meine längeren Beiträge durchsuche, bei denen die Vorschau und der Editor nicht übereinstimmen, und es ewig dauert, bis ich finde, wo meine entsprechende # Überschrift ist.
Für mich wäre es eine massive Verbesserung, wenn # Überschriften einfach fett oder in einer bestimmten Farbe auf der Editorseite des Komponisten hervorgehoben würden.
2 „Gefällt mir“
Das ist es, nicht wahr?
Diese Editoren sind für Entwickler und Programmierer gemacht und für normale Benutzer wirklich verwirrend.
Aber es ist, wie es ist und steckt zu tief im Kern, um es zu ändern. Wie die Entwurfsfrage 
Wie auch immer – vom Thema abgekommen usw.
1 „Gefällt mir“
Ist das schon näher an der Realisierung?
Kontext:
1 „Gefällt mir“
Wir haben die Arbeit in diesem Bereich begonnen. @lindsey wird uns über den Fortschritt auf dem Laufenden halten.
9 „Gefällt mir“
Das ist sehr gut zu hören – die Verwendung von Markdown ist großartig für unsere Power-User, aber eine ziemliche Lernkurve für die Mehrheit unserer weniger erfahrenen Benutzer und würde viel dazu beitragen, unsere Community zugänglicher zu machen.
4 „Gefällt mir“
Hallo @lindsey, ich möchte dich in keiner Weise drängen, aber ich dachte, ich frage einfach mal, ob du Folgendes teilen könntest:
-
Ob die Änderungen Interoperabilität / ein Framework beinhalten werden, das Plugins die Entwicklung von Editorlösungen ermöglicht.
-
In diesem Zusammenhang, ob du die Entwicklung deines eigenen Rich-Text-Editors, z. B. in einem Plugin, in Betracht ziehst.
-
Eine grobe Vorstellung davon, welchen Zeitrahmen du für 1 und/oder 2 anstrebst.
Der Kontext für mich ist der Ansatz und der Zeitrahmen dieses potenziellen Projekts
@Rohail_Altaf und ich versuchen zu überlegen, wie wir dies am besten angehen können, insbesondere im Hinblick auf den Zeitplan. Nichtsdestotrotz habe ich volles Verständnis, wenn du dies zu diesem Zeitpunkt nicht mitteilen kannst.
5 „Gefällt mir“
Hallo Angus — Entschuldigung für die Verzögerung, wir waren auf dem jährlichen Firmen-Retreat in Tokio!
Ich kann im Moment nicht zu viele Details beantworten, da wir noch die Implementierungsdetails festlegen. Ich denke, wir werden das in den kommenden Wochen herausgefunden haben, zumindest gut genug, um diese Fragen zu beantworten, daher werde ich mich wieder melden, sobald wir mehr wissen.
6 „Gefällt mir“
Discourse liefert jetzt einen experimentellen WYSIWYG-Editor 
Diese Infrastruktur ermöglicht es uns langfristig auch, Syntaxhervorhebung auf Markdown anzuwenden, wenn wir diesen Weg einschlagen wollen. Mit dem neuen Editor wird dies jedoch viel weniger notwendig.
Zum Beispiel ermöglicht der neue Editor jetzt, Code während der Eingabe mit Syntaxhervorhebung zu versehen!
5 „Gefällt mir“