 |
Zusammenfassung | Ein Klick in das Textfeld im Composer wählt die entsprechende Zeile im Vorschaufenster aus und umgekehrt. |
 |
Repository-Link | \u003chttps://github.com/thijsbrilleman/discourse-click-to-edit\u003e |
 |
Installationsanleitung | So installieren Sie Plugins in Discourse |
Ein Klick in das Textfeld im Composer wählt die entsprechende Zeile im Vorschaufenster aus und umgekehrt.
Sehr schöne Ergänzung zur Kernebeteiligung von Discourse. Vielen Dank, dass Sie es erstellt haben.
Scheint, als ob das etwas wäre, das willkommen geheißen werden sollte, obwohl ich da kein Mitspracherecht habe.
Hallo 
Danke, das ist wirklich cool 
Ich denke nur, es wäre großartig, es als Themenkomponente zu machen. 
Es funktioniert auf dem iPad nicht besonders gut, da es beim Schreiben den gesamten Text auswählt. Das sieht sehr seltsam aus.
Danke, und ich stimme zu. Werde es mir ansehen, sobald ich Zeit habe. Du wärst immer willkommen, einen Pull-Request einzureichen.
Dies ist derzeit das beabsichtigte Verhalten, aber ich bin natürlich offen für bessere Ideen. Welche Art von visueller Rückmeldung würdest du empfehlen?
Es würde als eingefügter Text angezeigt werden, wenn etwas wirklich ausgewählt wurde. Dann gäbe es eine Aktion und eine Reaktion.
Neugierig, warum ist das ein Plugin und keine Theme-Komponente? Alle diese Tokens können clientseitig generiert werden, oder?
Gute Arbeit übrigens, ich finde es toll, dass Sie sich auf die Zeilennummern verlassen, die von der Markdown-Engine eingefügt werden.
Danke, Sam.
Wie Sie vielleicht bemerkt haben, sind die data-ln-Attribute auch im generierten und serverseitig gespeicherten HTML vorhanden.
Ich habe dieses Verhalten implementiert, damit ich das Plugin später erweitern kann, um das zuverlässige Einfügen/Bearbeiten von Fragmenten von der Topic-View-Seite zu ermöglichen, äquivalent zum unten gezeigten Bearbeiten-Button (aber etwas robuster):
Es ist ein Jahr her, seit ich es geschrieben habe, aber wenn ich mich richtig erinnere, ist zu diesem Zweck in plugin.rb die Zeile
register_asset "vendor/javascripts/markdown-it-line-numbers.js", :vendored_pretty_text
erforderlich, um sicherzustellen, dass die MarkdownIt-Erweiterung auch serverseitig ausgeführt wird, wenn das HTML gekocht wird.
Ich habe jedoch noch keine Zeit gefunden, die erweiterte Bearbeitungsfunktion zu implementieren. Wenn diese Anforderung also wegfällt, könnte sie meiner Meinung nach in eine Komponente umgewandelt werden.
@sam Ich versuche, es in eine Theme-Komponente umzuwandeln, aber ich kann nicht herausfinden, wie dieser Code im Kontext eines markdownit-Plugins ausgeführt werden kann:
// javascripts/lib/discourse-markdown/initialize_markdownit_plugin.js:
export function setup(helper) {
helper.registerPlugin(markdownitLineNumbers); // markdownitLineNumbers ist bereits verfügbar
}
Ich habe den Verdacht, dass die Zeile im Plugin, die ich zuvor geschrieben habe, auch clientseitige Magie einstreut:
# plugin.rb
register_asset "vendor/javascripts/markdown-it-line-numbers.js", :vendored_pretty_text
Hast du eine Ahnung?
Ich bin mir nicht sicher, ich werde das Team anpingen.
Ich glaube, das liegt daran, dass es derzeit nur auf den Geltungsbereich von Plugins beschränkt ist. Es würde auch ohne diese Prüfung funktionieren. (Dieser Code wurde in diesem Commit eingeführt)
Ich wollte Zeilennummern für eine andere Komponente integrieren, aber ich wollte kein Plugin erstellen, also habe ich darauf verzichtet. Es wäre super, wenn Markdown-Funktionen in Theme Components unterstützt werden könnten!
Nebenbei bemerkt, eine großartige Funktion, die Sie hier vorgeschlagen haben – sehr gut. 
Ah ja, das klärt die Sache auf.
Wenn ich mir diesen Code ansehe, wäre es vielleicht möglich, das Markdown-Plugin von der Theme-Komponente zur Laufzeit manuell einzuschleusen, aber das wäre ziemlich hacky. Ich werde das Urteil des Kernteams abwarten, bevor ich versuche, es zu implementieren.
Unsere Markdown-Pipeline läuft sowohl auf dem Client (für die Vorschau) als auch auf dem Server (um das HTML für Beiträge vorab zu rendern). Deshalb ist sie nur für Plugins ausgelegt – nur diese können serverseitig Code einschleusen.
Nun… dieser Fall ist ziemlich ungewöhnlich, da die Erweiterung nur im Composer und nicht auf dem Server benötigt wird. Daher sollte es machbar sein, sie von einer Theme-Komponente aus zu realisieren.
Hattest du eine bestimmte Strategie dafür im Sinn?
Das scheint etwas zu sein, das breite Zustimmung finden würde. Es kann schwierig sein, seinen Platz in einem langen Beitrag zu finden. Könnte es pr-welcome sein?
Überschreibe diese Funktion im ursprünglichen Code:
// discourse/app/assets/javascripts/discourse/app/components/d-editor.js
async cachedCookAsync(text, options) {
this._cachedCookFunction ||= await generateCookFunction(options || {});
return await this._cachedCookFunction(text);
}
mit einem Theme-Komponenten-Initialisierer:
export default {
name: "d-editor-cached-cook-async-override",
initialize() {
const dEditor = require("discourse/components/d-editor").default;
dEditor.reopen({
cachedCookAsync(text, options) {
// Duplizierter Code hier, um eine geänderte Cook-Funktion zurückzugeben
},
});
},
};
Es würde ziemlich viel Code-Duplizierung bedeuten, wenn es überhaupt funktionieren würde. Schmutzig, schmutzig.
Hmm ja, stimme zu – definitiv nicht ideal. Das Duplizieren des Codes ist möglicherweise nicht einmal möglich, da die markdown-it-Module asynchron geladen werden und nicht Teil des AMD-Modulsystems sind, auf das Themes/Plugins direkten Zugriff haben. 
Der Aufbau eines Systems, das es Themes ermöglicht, clientseitige md-Transformationen beizusteuern, könnte cool sein, obwohl die Anwendungsfälle ziemlich begrenzt sind. In 99 % der Fälle möchten die Leute, dass md-Transformationen auch serverseitig angewendet werden.
Daher denke ich, dass es vorerst wahrscheinlich am besten ist, bei einem Plugin zu bleiben.
Ich frage mich, ob diese Art von Dekoration trotzdem angewendet werden sollte?
Z.B.:
<p data-source-line="0">.....</p>
Das zusätzliche Datenattribut wird viele unserer internen Implementierungen unterstützen, wie zum Beispiel das Nichtanzeigen von Autovervollständigung, wenn Sie sich in einem Codeblock befinden. Auch das Zitieren und schnelle Bearbeiten wird dadurch viel einfacher.
Die triviale Implementierung bringt fast kein zusätzliches Gewicht mit sich, erlaubt uns aber, einen Haufen Quellcode zu löschen.
Wir hatten das schon einmal (hinter einem Flag), aber es wurde in diesem Commit entfernt. Ich habe diesen Screenshot aus internen Diskussionen über diese Funktion gefunden:
d.h. das Performance-Problem lag im Code für die Scroll-Synchronisation, nicht bei der Einfügung der Zeilennummern 
Also ja, ich habe keine Einwände gegen die Einfügung der data-source-line in den Core, solange sie nur in der Vorschau hinzugefügt wird. Wärst du daran interessiert, einen PR dafür zu erstellen, @pipkin?
Gerne! Ich freue mich, euch etwas zurückgeben zu können.
