Wäre es möglich, die aktuellen Konfigurationseinstellungen für den Markdown-Typografen (auch bekannt als „intelligente Zeichensetzung“) so anzupassen, dass Unicode-Zeichen wie Anführungszeichen und Gedankenstriche aktiviert, aber Symbole wie (c), ™ und andere ähnliche spezielle Glyphen deaktiviert werden?
Das tritt besonders häufig bei Aufzählungen auf. Zum Beispiel:
(a) Apfel
(b) Banane
(c) Urheberrecht?
(d) Datum
Diese Aufzählungsform ist in Gesetzen, Verträgen, Richtlinien und anderen formellen Texten, die vom juristischen Stil beeinflusst sind, sehr verbreitet. Sie ist auch eine gängige Gliederungsform. Sie war Teil des „Standard“-Gliederungsstils, der mir als Schüler in den Vereinigten Staaten beigebracht wurde.
Die aktuellen Einstellungen bieten zwar gewisse Flexibilität bei der Zeichensetzung, aber soweit ich sehen kann, keine Möglichkeit, intelligente Zeichensetzung zu aktivieren, ohne gleichzeitig intelligente Symbole zu aktivieren.
Das sieht nicht gerade konfigurierbar aus. Wir müssten markdown.it patchen, um diese Flexibilität zu unterstützen, oder einfach einen eigenen, auf markdown.it basierenden Prettify-Code schreiben.
Die einzige triviale Lösung ist, die gesamte Funktion zu deaktivieren.
Der Vorteil ist, dass die Engine ziemlich konfigurierbar ist: Wir könnten die Regeln in markdown.it deaktivieren, den Code kopieren und unsere eigenen Ersetzungen implementieren, genau wie @Roman es umgesetzt hat.
Ein paar Engineering-Tage, um das aufzuräumen, wären zwar schade, und es wäre auch nicht ideal, denselben Code zweimal auszuliefern, aber das ist bei einem Fork wohl unvermeidbar.
Seit dem Commit 7b8969ce5cb2edc54f2c1aa39a85a3a08076337d im master-Branch von markdown-it ist die relevante Quelldatei lib/rules_core/replacements.js und das zugehörige Test-Fixture test/fixtures/markdown-it/typographer.txt.
Alle Ersetzungen sind hart kodiert. Dazu gehören (c) → (c), (tm) → ™, (r) → (r) und (p) → (p), die als „bereichsspezifische Abkürzungen
Der Maintainer ist sehr reaktionsschnell. Er schließt meine PRs innerhalb von Minuten
Meiner Einschätzung nach ist er äußerst abgeneigt, auch in neuen Major-Versionen irgendwelche Breaking Changes einzuführen, selbst bei Dingen wie der Darstellung von (P) als §. Zudem ist er gegenüber Optionen im Stil von typographer: {A: true, B: false} allergisch, selbst wenn typographer: true weiterhin funktioniert, und das aus Gründen der wahrgenommenen Komplexität.
Ich lese zwischen den Zeilen und er ist ein Russe, der auf Englisch schreibt. Aber ich habe das Gefühl, dass er markdown-it als ausgereift betrachtet.
Mit aller Dankbarkeit könnte es sich lohnen, die Implementierung zu forken, sie als ES Modules neu zu schreiben und alle Plugin-ähnlichen Funktionen, die aktuell gebündelt sind – sowohl die Linkifizierung als auch die Ersetzungen, einschließlich der Satzzeichen-Ersetzungen des Typographers – zu entfernen.
Der Maintainer interessiert sich nicht für Punkte bezüglich duplizierten Codes in Bundles ohne Nummern. Und er interessiert sich auch nicht für nicht-brechende Änderungen an der API, die nicht von 100 % der Benutzer „erforderlich“ sind oder Plugin-Implementierungen blockieren. Das führt zu einer gewissen Zwickmühle, da sie zwei sehr plugin-ähnliche Submodule für Linkifizierung und intelligente Satzzeichen ausliefern, die nach dieser Philosophie eigentlich in eigenen kleinen npm-Paketen landen sollten. Das passiert nun mal.
Zum Kontext: Es gab in der relativ nahen Vergangenheit erhebliche Releases bei markdown-it. Bemerkenswert ist eine Leistungsverbesserung von Alex Kocharin im November des letzten Jahres.
Um (c) zu beheben, (p) zu behandeln und sonstiges mit Pfeilen und Ähnlichem zu erledigen, ist der beste Weg wahrscheinlich, einen Patch vorzuschlagen, der die Submodule für Linkifizierung und intelligente Satzzeichen aus dem Kern entfernt und stattdessen als Plugins in Discourse lädt. Verwende eine GitHub Action oder einen Cron-Job, um den master-Branch von markdown-it im Auge zu behalten und ein automatisches Rebasen zu versuchen. Falls der Maintainer so konservativ bezüglich Änderungen bleibt, sollte der Patch noch lange Zeit sauber anwendbar sein. Es sei denn, sie machen einen großen Schritt, etwa eine Umstellung auf ES Modules statt CommonJS.
Wir haben dies intern besprochen und entschieden, dass wir typographer hard-forken werden.
Wir werden typographer in markdown.it im Wesentlichen deaktivieren und eine Kopie in Discourse implementieren. markdown.it ist unglaublich erweiterbar, dies ist größtenteils „Kopieren und Einfügen".
Sobald das Kopieren und Einfügen abgeschlossen ist, können wir Tests hinzufügen und einige der Regeln anpassen und ändern.
Hey, entschuldige bitte, dass ich diese Diskussion wieder aufgreife. Da ich nach einer Möglichkeit suche, ... -> … zu deaktivieren, wollte ich wissen, ob dieses Feature Fortschritte gemacht hat und ob ich in Zukunft erwarten kann, einzelne Regeln ein- oder auszuschalten.
Nun, ich habe das bereits versucht, aber anscheinend funktioniert es nicht. Egal, ob ich den Typografen aktiviere oder deaktiviere, die Ersetzungen werden immer durchgeführt (und übrigens scheint (c) nicht zu funktionieren).
