Hacker News Reader

Comment by bryanlarsen | Hacker News Reader

Using a visible character rather than an invisible one makes editing in an editor a lot easier.

The ASCII separators are visible in my editor. If something doesn’t support ASCII text, that sounds like a bug which should be fixed, not a reason to misuse graphical characters for something other than their purpose.

It won't wrap at the record separator, so you'll get a very long line.

The example seems to use `␞\n` as a separator rather than just `␞`. I assume their proposed standard is more definitive.

Their ABNF uses RS, defined as U+241E, not U+241E + '\n' as the record separator. They seem to add an "USV escape" in front of the linefeeds.

My bet is that this will lead to implementations that wrongly treats "␞␛\n" (RS ESC \m) as the real record separator, the same way lots of "CSV" implementations just split on comma and LF.

Seems to me if you're going to add support for something like that you should just bite the bullet and declare an LF immediately following an RS as part of the record separator, or you're falling in the same trap as CSV of being "close enough" to naively splittable that people will do it because it works often enough.

The escape symbol lets you ignore any non-special character, not just newlines: https://github.com/sixarm/usv?tab=readme-ov-file#escape-esc

I'm aware. I don't think that serves a useful purpose - I think the way they've done it is likely to make people more likely to get the parsing wrong for pretty much zero benefit. My guess is you'll end up seeing a lot of "pseudo-USV" parsers the same way we have a ton of "pseudo-CSV" parsers that breaks on escapes or quoted strings with commas, and so I think they fundamentally failed to learn the lessons of CSV.

that's a lie as far as I can see, the csv-to-usv tools does not add any newlines:

[0] https://github.com/SixArm/csv-to-usv-rust-crate/blob/30a0324...

The examples here have them: https://github.com/SixArm/usv/tree/main/examples

the submitted tool does not have produce them, check out the tests - note there is no \n anywhere in USV

https://github.com/SixArm/csv-to-usv-rust-crate/blob/30a0324...

If you're doing spreadsheets, then it should show in a spreadsheet and not in an editor. It's like complaining that he can't edit jpegs in Sublime or something... there's a reason that's working poorly.

Speaking of which, last time I had a control code heavy file open in Sublime, it actually did show the control codes as special characters, and it was possible to copy/paste those. This proposal is so bad I suspect it will become a standard.

There are a lot of cases where I would rather inspect/quickfix a csv file in a text editor rather than open it as a spreadsheet. Especially cases where something is wrong in the format, and it will just not open as a spreadsheet at all. Adding unnecessary levels of obfuscation to your data should never be considered a good idea imo.

Reply on news.ycombinator.com