TPSV, an Alternative to TSV (and CSV)

          Dec      Octal  Hex   Binary

          028      034    01C   00011100       FS    (File Separator)
          029      035    01D   00011101       GS    (Group Separator)
          030      036    01E   00011110       RS    (Request to Send)(Record Separator)
          031      037    01F   00011111       US    (Unit Separator)

https://en.wikipedia.org/wiki/ASCII#Character_groups

https://en.wikipedia.org/wiki/C0_and_C1_control_codes#C0_con...

But CSV represented as JSON is usually accomplished like so:

  {
    "headers": ["name", "habitat", "food"],
    "data": [
      ["Acorn Woodpecker", "forest", "grain"],
      ["American Goldfinch", "grassland", "grain"],
      ["Anhinga", "wetland", "fish"],
      ["Australian Reed Warbler", "wetland", "grub"],
      ["Black Vulture", "forest", null]
    ]
  }

I personally use it to write tabular data manually, used to define our datamodel. Because this format is editor agnostic, colleagues can easily read and edit as well. So in my case it's focus on human read/write and machine read.

If RS and US were in common use, there would be a need to have a visible representation for them in the terminal, and a way to enter RS on the keyboard. Pretty soon, strings that contain RS would become much more common in the wild.

Then, one day somebody would need to store one of those strings in a table, and there would be no way to do so without escaping.

I do think that having RS display in the terminal (like a newline followed by some graphic?) and using it would be an improvement over TSV's use of newline for this purpose, but considering that it's not a perfect solution, I can understand why people are not overly motivated to make this happen. The time for this may have been 40+ years ago when a standard for how to display or type it would be feasible to agree upon.

Notepad++ handles the display and entry of these characters fairly easily. I think they're nowhere as unergonomic as people say they are.

We have them, they're used where appropriate.

> Throw away the text formats.

I would argue that _most_ of the time tsv or csv are used it's because either:

a) the lowest common denominator for interchange. Oh, you don't have _my specific version of $program? How about I give you the data in csv? _everything_ can read that...

b) a human is expected to inspect/view/adjust the data and they'd be using a bin -> text tool anyways. The move to binary based log formats (`journald`) is still somewhat controversial. It would have been a non-starter if the tooling to make the binary "readable" wasn't on-par with (or, in a few cases, better!) than the contemporary text based tooling we've been used to for the prior 30+ years..

It was also my idea of an operating system design, it will have a binary format used for most stuff, similar to DER but different in some ways (including different types are available), which is intended to be interoperable among most of the programs on the system.

More recently though, consider that LLMs are terrible at emitting binary files, but amazing at emitting text. I can have a GPT spit out a nice diagram in Mermaid, or create calendar entries from a photo of an event program in ical format.

This is why you should almost always use text formats.

> 3. The first row defines the number of columns