‚ÜĎ

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.