Diskussion ✂️
Verkürzte Syntax für Heredocs

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. Eine einzeilige Lösung wäre wünschenswert.

  1. I will refrain from implementing a nice short one-liner like


    with the same meaning that


    currently has. It complicates processing too much and risks backwards compatibility problems that are too huge already. This is mainly because the general processing of an Aneamal file is

    A. sandwich markup and removal of leading/trailing whitespace in lines
    B. metadata declarations and removal of comments
    C. all the visible content, including files like [a-warnung]

    The order is not arbitrary. For example, metadata declarations obviously cannot be processed before sandwich markup like /@/foo that adds squirrels @ to subsequent lines has been processed.

    Visible content can not be processed before metadata has been processed, for example because visible content may use metadata that is declared later in the document like this:

      We went to Völlinghausen->@1 in 2017.
      @1: ->https://prlbr.de/2017/voellinghausen-moehnesee/

    But in case of [a-warnung]/🐾 there would be sandwich behaviour that depends on [a-warnung] being identified as a file first, which positions processing step C before processing step A within the same file. It's like a dog trying to catch its own tail.

    This does not mean that it's technically impossible to have a one-liner syntax for embedded files + sandwich markup. It just means that there can't be a one-liner syntax that is as nice as [a-warnung]/🐾 would be. A less nice syntax may not be worth it though. Technically feasible candidates could be




    which can be identified in the first processing step by the double slash // at the start of the line already. But this is something that does not need to be decided now. It could be implemented without backwards compatibility issues at a later point in time, if the desire arises, since double slashes are not permitted at the start of the line until then.