↑

Diskussion 🐛
Autokorrekturen statt Fehlermeldungen

Für Fälle, in denen ein Dokument nicht der Aneamal-Syntax entspricht, könnte man definieren, wie diese interpretiert werden sollen, ohne eine Fehlermeldung auszugeben. Beispielsweise könnte in einem Textabsatz bei einem einzigen *, welcher den Beginn eines hervorgehobenen Abschnitts markiert und wozu eigentlich ein weiterer * als Endmarke erwartet wird, definiert werden, dass das Ende des Absatzes dann das Ende des hervorgehobenen Abschnitts ist. Oder es könnte definiert werden, dass ein einziger * in einem Textabsatz gleich \* nur für sich selbst und nicht für einer Hervorhebung steht.

  1. Statt des Vorschlags in @4 könnte man das Fehlerverhalten über eine Metadeklaration zum Beispiel in @meta.nml konfigurieren. So könnte

    @errors: ->/foo.log

    bedeuten, dass Fehlermeldungen in die Datei /foo.log geschrieben werden, während

    @errors: off

    bedeuten würde, dass keine Fehlermeldungen ausgegeben würden – weder auf der Seite, noch in eine Datei. Und

    @errors: auto

    oder "on", "public", "in-page", … statt "auto" würde das aktuelle = Standard-Verhalten beschreiben, bei dem Fehlermeldungen in der HTML-Seite ausgegeben werden.

  2. Die Fehlermeldung 56 habe ich doch wieder zurückgeholt, vergleiche @5. Grund: Verwechslungsgefahr von Hinweisen und Multiple-Choice-Optionen, bei denen auch kein Text vor der linken geschweiften Klammer steht.

    Die in @6 beschriebene Änderung bleibt jedoch, ebenso die am Ende von @5 beschriebene Vereinheitlichung.

  3. Durch @5 ändert sich auch die Interpretation eines merkwürdigen Randfalles:

    #{foo}->bar

    wurde bisher so etwas wie

    <span id='foo'></span><a href='bar'>bar</a>

    und wird nun, was konsequenter im Sinne der sonstigen Aneamal-Interpretation ist:

    <a href='bar'><span id='foo' title='foo'></span></a>

  4. Die Fehlermeldung „56: Annotated text missing: text expected before {“ habe ich entfernt. Sie trat auf, wenn man so etwas schrieb:

    foo {bar}

    Die Motivation für die Fehlermeldung war, dass der dementsprechende HTML-Code

    foo <span title='bar'></span>

    im Browser typischerweise nicht hilfreich ist, da das title-Attribut aufgrund einer Breite von 0 Pixeln bei Standarddarstellung des <span>-Elementes durch Mouse-over-Ereignisse nicht sichtbar gemacht werden kann. Ich denke, der Fehler ist überflüssig, weil

    1. der HTML-Code dennoch gültig ist
    2. das <span>-Element per JavaScript oder CSS durchaus nutzbar gemacht und zum Beispiel per span:empty[title] ganz gezielt selektiert werden kann
    3. der Hinweis im Aneamal-Quelltext auch sinnvoll lesbar ist und nicht dem vorstehenden Wort zugeordnet werden muss

    Vereinheitlichend wird in diesem Zuge auch das bereits gültige

    #{baz}

    nicht mehr als

    <span id='baz'></span>

    sondern als

    <span id='baz' title='baz'></span>

    interpretiert.

  5. Das Fehlerreport-Verhalten könnte in .htaccess in einer Umgebungsvariablen festgelegt werden, ähnlich wie das Cache-Verhalten mit der Variablen AneamalCache.

  6. Man sollte dann aber zumindest im HTML Quelltext einen Kommentar <!-- … --> hinterlassen, der darauf hinweist, dass es hier ein Problem gibt, was im Fehler-Logbuch notiert ist: <!--see-log--> oder so etwas.

  7. Statt eine Fehlermeldung offen auf der Webseite auszugeben, könnte man sie auch optional in eine nur dem Webmaster zugängliche Datei schreiben. Siehe die Anregung hier:
    https://prlbr.de/projekt/aneamal/diskussion/bilder-nicht-als-text-laden#K8

    Ich stelle mir das so vor, dass die Fehlermeldungen weiterhin ausgegeben werden, wenn eine bestimmte Datei, zum Beispiel /aneamal/error.log nicht existiert oder nicht beschreibbar ist. Wenn die Datei existiert, werden Fehler hingegen nicht öffentlich ausgegeben, sondern in jene Datei gespeichert.

    Es wäre wichtig zu verhindern, dass die Datei unendlich groß wird, wenn ein Fehler vom Aneamal-HTML-Konverter immer wieder bemerkt wird, aber nicht behoben wird. Beispielsweise könnte geschaut werden, ob dieser Fehler schon einmal berichtet wurde (also bereits in der Datei /aneamal/error.log steht) – in diesem Fall würde er nicht erneut vermerkt. Das wiederum würde aber bedeuten, dass die Datei /aneamal/error.log nicht mehr aktualisiert wird, obwohl ein Fehler weiterhin besteht. Besser wäre, wenn man der Datei am Änderungsdatum ansieht, dass es aktuell noch ein Problem gibt. Eine Lösung wäre, stattdessen ein Verzeichnis /aneamal/log/ anzulegen, in das dann Fehlermeldungen in täglichen Dateien abgespeichert werden, zum Beispiel /aneamal/log/20181103.txt. Damit würde ein und derselbe Fehler nur, aber immerhin einmal täglich gemeldet.

  8. In der Praxis liefe die Definition, wie Fehler ohne Fehlermeldung abgefangen werden, darauf hinaus, dass die Syntax gelockert wird und, was bislang Fehler waren, nun nutzbare Möglichkeiten sind. Die Sprache würde dadurch komplexer und das Bauen von Konvertern schwieriger.

    Zu bedenken ist auch, dass Fehlermeldungen einen Autor auf ein Versehen hinweisen können und ihm so hilfreich sind. Oft wird der Versuch, dies automatisch zu korrigieren, nicht dem entsprechen, was der Autor wollte. Eine Erklärung, wieso das Ergebnis dann anders aussieht als so, wie er es beabsichtigte, erhält er nicht und kann sein Versehen daher schwerer identifizieren und korrigieren.

    Ebenfalls zu bedenken ist, dass eine Fehlermeldung aufgrund ungültiger Syntax manchmal erlaubt, genau jene bislang fehlerhafte Syntax später für eine andere Funktion einzusetzen. Die Fehlermeldung stellt sicher, dass die Syntax nicht schon verwendet wird. Beispielsweise ist Sandwich-Markup so aufgebaut /foo/bar. Fehlt „foo“, also //bar, dann gibt das eine Fehlermeldung. Das ermöglicht, zwei Schrägstriche am Anfang einer Zeile später mit einer anderen Funktion als gültiges Markup einzuführen. Würde //bar bislang keine Fehlermeldung erzeugen (und sie wäre tatsächlich verzichtbar, auch wenn //bar derzeit keine sinnvolle Funktion hat), dann würde man mit der Einführung einer neuen Funktion für // riskieren, dass alte Dokumente plötzlich anders als bislang interpretiert werden.

    Aufgrund solcher Überlegungen ist das Abschaffen von Fehlermeldungen sehr behutsam und nur dort vorzunehmen, wo möglichst keine missverständlichen Situationen dadurch entstehen und man sich keine Möglichkeiten für zukünftige Erweiterungen verbaut.