3.1 Text Lines

Lines of plain text input, are output between a pair of pipe characters ‘|’, with a final period to indicate the linefeed character. Input:

Hello there

Output:

|Hello there|.

Trailing whitespace is thus made plainly visible to the reader.

|Trailing space:    |.

A blank line is represented as empty content between the pipes.

||.

If the input line is too long to display as one line of output, it will be displayed as follows, with dash characters, ‘-’, to mark continuity at the beginnings and ends of the lines (outside the pipe characters).

|This input line |-
-|was too long to|-
-| fit|.

You might wonder whether pipe characters themselves might have to be escaped, so as to avoid confusion with the surrounding pipes. After all, in a C string literal, denoted by double-quotes, ‘"’, one must escape literal double-quote characters by preceding them with a backslash (and must then also escape literal backslashes): "She said \"no\"". However, no such escaping mechanism is needed in Teseq. Input:

A line with a pipe | in it, and a line with just a pipe
|

Output:

|A line with a pipe | in it, and a line with just a pipe|.
|||.

No special treatment whatsoever!

The reason Teseq can get away with this is that the pipe character only has its special “mark the enclosed as normal text” meaning, when it is the first and the last character on a line of output (aside from a possible prefacing dash to indicate a wrapped line, or a trailing dash or period).

A lot of the output lines you’ve seen so far have all ended with a period, denoting the linefeed character. However, this isn’t always the case. For instance, if the input line contains a control character, Teseq will close the text line (with just a pipe, no period), print a control-character line with the control characters, and then finish up the rest of the text line. The following sample output represents a single line which contains a delete character and a null character:

|Fee fi|
. DEL/^?
|fo|
. NUL/^@
|fum|.

And here’s a line that’s terminated with a carriage-return/line-feed combination, rather than just a linefeed.

|The promised line|
. CR/^M LF/^J

The linefeed character is special: when it’s preceded by control characters or escape sequence, it’s printed as a control character; when it’s preceded by text characters (or by nothing at all), it’s printed as that final dot thing. This behavior is designed to make a newline look like the end of a line or a blank line when it should, and to look like a control character when it should.

And of course, if the final line in the file is missing a newline, the dot won’t appear there either.

Currently, the only characters included in text lines, are those from the printable range of characters from US ASCII ( Ecma-6 / ISO 646)—and sometimes linefeed, represented by the special final-dot notation. This means that if the terminal was using a character set that high-value code points, all high-valued bytes will be represented in hexadecimal on control-character lines, and not displayed on a text line. Future versions of Teseq may provide options allowing for these characters to be represented properly in text lines, but for now, the output format is ASCII characters only. See Future Enhancements.

Note that even characters falling in the normal range of ASCII printable characters may not necessarily be represented correctly: for instance, if escape codes are present in the input that would switch the terminal to a different national variant of Ecma-6 / ISO 646, then the real terminal might display (say, for ISO-646ES) ‘Ñ’ instead of ‘[’; but the output from Teseq will not change based on this (even though it will recognize and identify the control sequences that invoke that character set for use).