3 ms·

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

• tgv 3y ago
  It won't wrap at the record separator, so you'll get a very long line.
  • bryanlarsen 3y ago
    The example seems to use `␞\n` as a separator rather than just `␞`. I assume their proposed standard is more definitive.
    • vidarh 3y ago
      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.
      • shawnz 3y ago
        The escape symbol lets you ignore any non-special character, not just newlines: https://github.com/sixarm/usv?tab=readme-ov-file#escape-esc https://github.com/sixarm/usv?tab=readme-ov-file#escape-esc
        • vidarh 3y ago
          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.
    • theamk 3y ago
      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/30a0324d8ebd1086bae52ab2fc8d3c9abda53c0a/src/lib.rs#L11 https://github.com/SixArm/csv-to-usv-rust-crate/blob/30a0324...
      • bryanlarsen 3y ago
        The examples here have them: https://github.com/SixArm/usv/tree/main/examples https://github.com/SixArm/usv/tree/main/examples
        • theamk 3y ago
          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/30a0324d8ebd1086bae52ab2fc8d3c9abda53c0a/tests/integration_test.rs#L7 https://github.com/SixArm/csv-to-usv-rust-crate/blob/30a0324...
• NoMoreNicksLeft 3y ago
  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.
  • dimask 3y ago
    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.
• eadmund 3y ago
  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.