Systemspace Network List Network Enhancement Idea 2 Yori 11 July 2021 [Affected by NEIs: 3, 4] # THE ENHANCED TEXT FORMAT DRAFT Yori's 1st text format proposal and proposed specification. ## Introduction The Enhanced Text Format is meant to augment the displaying and formatting of text documents while making the format easy to interact with in plain text editors without any extra tools. Why dose this exist, with formats like markdown or gemtext existing? This fills a niche that I believe markdown, gemtext and friends do not fill. Markdown is too powerful and usually only works well in a web centered or graphical settings. Being able to inline links or formatting makes readability harder for plain text only usage. Markdown is also plagued with many extensions so not all markdown renders are made equal, one of the worst examples is the ability on some tools to "escape to html" requiring a rendered to be a full web browser now. Gemtext is closer to what i'd like to see from a minimal text format, but its intended purely for use in the Gemini protocol and lacks important features to make a good format for other uses. ## Purpose of this document Its to introduce and explain a format I'd like to introduce and this is to be seen as a "draft", I would like input on this specification and then a later NEI will be the final specification. ## The Format ### Lines A document is composed of one or more lines, a line is split using the line feed character '\n'(ASCII 10), the carriage return character '\r'(ASCII 13) dose not split lines nor ideally should it be contained in a valid document. To be compliant you must treat carriage returns('\r') in one of the following two ways. The first option is to ignore them and treat it as just a normal but invisible character. The second and best option is to strip them out if that is possible especially if your program is transmitting, transforming or saving the document. Blank lines can never be omitted or not displayed. When documents are converted or displayed, each line must be rendered as its own line, short lines can never be concatenated into one line(like in markdown). White space and the content of the line must be shown "as is" on the display. The document converter and displayer may and should 'wrap' or break long lines into smaller ones by default, but if the line is formatted, then it should only do so if the format of the line allows line warping. In general for most text, one line usually should equal one paragraph. When parsing a line to check if its a formatted line or not you only need to scan the first couple of characters, formatted lines may not start with white space and must start with the format code. ### Links >The format code for links is: '=>'(ASCII 61, 62) Then a full or "limited" URI containing no white space must be included, the protocol must be defined in the URI to be valid. You then optionally may have one or more white space after the URI, if the line then ends you must display the URI as the link text, if text is found after the white space, you must display the text, the text can have white space in it. ### Headings There is 3 levels of headings. >The format codes are '# ', '## ', '### '(ASCII '#'=35, ' '=32) The space is required after the pound sign. ### Metadata >The format code is ';;'(ASCII 59, 59) If the target is a displayer do not include the line, if its a converter that is converting to a different format, if the format supports comments or meta data then include the content of the line as a comment or metadata. If the format only supports comments, then first include an ';'(ASCII 59) char and you may encode it as an escape in the target format requires it. this is meant for information used as a input to programs, this is NOT for meant for the user or the author. ### Comments >The format code is '; '(ASCII 59, 32) works the same as the Metadata format code, but its for non machine interpreted metadata or comments and is only there for humans. If the target format dose not support metadata and only comments, this comment dose not need to be prefixed like the Metadata format code. ### Subtext >The format code is '~ '(ASCII 126, 32) Unlike Comments or Subtext format codes, this is displayed to the user. I recommend using less prominent color when rendering this text, the point of it is to be commentary or secondary text usually following the primary text, this can be thought of like an "anti blockquote" meant to de-emphasis text. ### Blockquotes >The format code is '>'(ASCII 62) You may render it in bold or another color, I recommend green or red. The point of it is to bring attention to a line or to quote something. ### Preformatted >The format code is '```'(ASCII 96) when parsing lines for format codes, you should only be parsing lines from top to bottom and with the formatting state set toggled on. Formatting is toggled on by default at the start of a document. When a line has the Preformatted format code. You toggle the formatting state on the parser and the content of the line must still be displayed.