Weiterentwicklung

Was

Heredocs bestehen aus einer Anweisung zum Einbinden einer Datei, in der Regel in eckigen Klammern [a-warnung] bzw. als Metaangabe @style, gefolgt von Zeilen die in der Regel alle mit einem | beginnen bzw. bei Metaangaben mit @|. Die wiederholten Zeichen am Zeilenanfang kann man per Sandwich-Markup automatisch setzen lassen, was einem Arbeit erspart. Allerdings erhält man dadurch einen zweizeiligen Start des Heredocs, zum Beispiel:
[a-warnung]
/|/⚠️
Eine einzeilige Lösung wäre wünschenswert.

Wozu

weniger Tipparbeit, mehr Übersichtlichkeit?

Warum

zur Tastenschonung und Freude von Autoren

Woher

David

Wann

?

Wo

html.php

Wer

Martin

Wie

vorzugsweise etwas wie […]/END, doch beachte die unten stehenden Anmerkungen – beim derzeitigen Konverteraufbau wäre etwas wie //…/END leichter umzusetzen

Weitere

–

→ Diskussion

Eine Syntax, die sich wie

[a-gedichtbox]/🐾
...
🐾

an das Gewohnte anlehnt, verkompliziert die Verarbeitung auf technischer Seite, wohingegen so etwas wie das Sandwich-Markup relativ einfach ist. Das hängt damit zusammen, dass Sandwich-Markup /…/… wie Kommentare % und Metadaten @ quasi überall am Zeilenanfang stehen kann, wohingegen eckige Klammern […] nur eine Sonderbedeutung haben, wenn sie am Blockanfang stehen. Daher kann Sandwich-Markup sehr früh bei der Interpretation eines Dokumentes verarbeitet werden. Die Zerlegung eines Dokumentes in Blöcke geschieht derzeit erst später. Das ist momentan zu spät für eine Tippsparsyntax, weil vorher schon Leerzeichen und Tabulatorzeichen von allen Zeilenanfängen getilgt werden. In Aneamal haben sie keine Bedeutung. In anderen Dateitypen wie zum Beispiel in Textdateien mit Quellcode der Programmiersprache Python spielen Leerzeichen aber eine entscheidende Rolle. In /2015/mehrdimensional-kuchen-schneiden/ zum Beispiel habe ich Python-Code eingebunden:

|def find (dimensions):
|    def findr (countdown, step, prod, cuts):
|        diff = step * (cuts[-1] - 1) + prod
|        if diff > 0:
|            cuts[-1] -= diff // step
|            diff %= step
|        if countdown == 1:
|            if diff == 0:
|                print (cuts)
|        else:
|            if diff == 0:
|                cuts[-1] += 1
|                diff += step
|            while cuts[-1] != findr (countdown - 1, diff, prod * (cuts[-1] + 1), cuts + [cuts[-1]]):
|                cuts[-1] += 1
|                diff += step
|        return cuts[-1]
|    if isinstance (dimensions, int) and dimensions > 0:
|        findr (dimensions, -1, 2, [1])

Die | am Anfang jeder Zeile verhindern auch, dass die Leerzeichen zur Einrückung der Befehle vom Aneamal-Konverter entfernt werden. Wenn ich hier Sandwich-Markup nutze

/|/🐾
def find (dimensions):
    def findr (countdown, step, prod, cuts):
        diff = step * (cuts[-1] - 1) + prod
        if diff > 0:
            cuts[-1] -= diff // step
            diff %= step
        if countdown == 1:
            if diff == 0:
                print (cuts)
        else:
            if diff == 0:
                cuts[-1] += 1
                diff += step
            while cuts[-1] != findr (countdown - 1, diff, prod * (cuts[-1] + 1), cuts + [cuts[-1]]):
                cuts[-1] += 1
                diff += step
        return cuts[-1]
    if isinstance (dimensions, int) and dimensions > 0:
        findr (dimensions, -1, 2, [1])
🐾

dann funktioniert das noch immer, denn das Sandwich-Markup wird ganz früh verarbeitet und in die Standardsyntax mit | an jedem Zeilenumfang umgewandelt, bevor Leerzeichen am Zeilenanfang entfernt werden. Aber die Zerlegung in Blöcke passiert erst später, sodass eine Verarbeitung von eckigen Klammern, die nur am Blockanfang eine besondere Bedeutung zur Dateieinbindung haben

[t-python]/🐾
def find (dimensions):
    def findr (countdown, step, prod, cuts):
        diff = step * (cuts[-1] - 1) + prod
        if diff > 0:
            cuts[-1] -= diff // step
            diff %= step
        if countdown == 1:
            if diff == 0:
                print (cuts)
        else:
            if diff == 0:
                cuts[-1] += 1
                diff += step
            while cuts[-1] != findr (countdown - 1, diff, prod * (cuts[-1] + 1), cuts + [cuts[-1]]):
                cuts[-1] += 1
                diff += step
        return cuts[-1]
    if isinstance (dimensions, int) and dimensions > 0:
        findr (dimensions, -1, 2, [1])
🐾

derzeit käme, wenn die Leerzeichen schon alle weg sind und der Python-Code also so aussieht:

def find (dimensions):
def findr (countdown, step, prod, cuts):
diff = step * (cuts[-1] - 1) + prod
if diff > 0:
cuts[-1] -= diff // step
diff %= step
if countdown == 1:
if diff == 0:
print (cuts)
else:
if diff == 0:
cuts[-1] += 1
diff += step
while cuts[-1] != findr (countdown - 1, diff, prod * (cuts[-1] + 1), cuts + [cuts[-1]]):
cuts[-1] += 1
diff += step
return cuts[-1]
if isinstance (dimensions, int) and dimensions > 0:
findr (dimensions, -1, 2, [1])

womit er kaputt wäre. Aber das sind technische Details, die sich grundsätzlich lösen lassen.
Klären muss ich allerdings, ob sich solche Details so lösen lassen, dass das Programm nicht
nennenswert langsamer oder komplexer wird. Das relativ frühe Entfernen der Leerzeichen vom
Zeilenanfang spart nämlich einiges an Verarbeitungsaufwand in der Folge ein.