3 ms·

>Why not bold and _italics_. That would make a lot more sense to me. Surely _underline_ would make more sense than _italics_. Somewhere I have seen /italics/ i

>Why not bold and _italics_. That would make a lot more sense to me. Surely _underline_ would make more sense than _italics_. Somewhere I have seen /italics/ in use, but that does look kind of regexpy. >I dislike that trailing commas are not allowed...There is no need for this and it makes writing out valid JSON more complex. Trailing commas as a trend emerged after JSON was standardised. And thank god JSON is as well and truly standard as it is.

philipwhiuk 1y ago
The trailing comma trend is almost entirely down to line-based diff tools as far as I can tell.
- perching_aix 1y ago
  Git is generally insufferable when it comes to these. Diffing YAMLs is even worse, and it gets downright hideous when the specific document you're working with betrays YAML's rules about orderedness (the document is order invariant, while YAML is ordered). In that case, even most semantic diffing tools become unusable. This is a thing with JSON too, arrays are ordered. I've been recently using dyff [0] to diff YAMLs in an order invariant way, and it's been absolutely liberating. Couldn't help with version control, but it's still night and day. [0] https://github.com/homeport/dyff https://github.com/homeport/dyff
- arccy 1y ago
  it's also annoying to edit, copy a line, add it to the end of a block. now you need to add a comma to the previous line, and strip off the comma on the new one you added (if you copied it from not the previous line).
- ithkuil 1y ago
  I wonder how much json aware diff representation and merge conflict resolution would remove the need of having the trailing comma
  - usrusr 1y ago
    I'd rather have a format supporting a friendly truth on the ground (on the filesystem) than adding yet another "almost like standard behavior" quirk to tooling.
- dspillett 1y ago
  It can also help eliminate some editing errors, when copying entries to extend a list or reordering entries. I prefer leading commas to having a final comma with an empty clause, though some people hate that and they don't really solve all the final-entry issues (they address some of them, but others are just moved to being first-entry issues).
- stevage 1y ago
  Huh, I don't know about that. I find it much more convenient for editing because it means the last item in a list doesn't behave differently when it comes to cut/copy/paste.
  - deleted 1y ago
    [deleted]
- wahern 1y ago
  Trailing commas were common in language design long before JSON or even JavaScript existed as it simplifies machine generation of code while being comparatively trivial to handle in a parser, so a net win. The convenience it offers for diffing is just a manifestation of the positive interaction with grammars and language tools. The convention of humans using trailing commas in lists, along with one item per line, is relatively new, though. Stylistically, this used to be frowned upon as long definition lists made source files longer, slower to scroll through, and worsened code locality from the perspective of someone using, e.g., a 25 row terminal.
- kragen 1y ago
  Trailing commas avoid having the last item behave differently, but they're easy to accidentally omit when they're optional. [ "or" , "alternatively" , [ "the" , "first" , "item" ] , "could" , "behave" , "differently" ] I feel that, despite its repugnant appearance, this "comma-first" approach is the best tradeoff in languages like JSON where trailing commas are forbidden; the leading `[` is much harder to accidentally omit or insert than the subtle trailing `,`. In Emacs I use js3-mode, a hack of js2-mode to support comma-first syntax. Comma-first syntax is especially convenient in SQL, which has the forbidden-trailing-comma problem and several analogous problems. In C if I have a long Boolean conjunction if (unpleasantly long boolean expression && another unpleasantly long boolean expression && yet another unpleasantly long boolean expression) { there are several ways to fix it, such as nesting ifs or factoring the expressions into variables or functions. The "comma-first" approach is also visually unappealing for spacing reasons, requiring two extra spaces after the parenthesis: if ( unpleasantly long boolean expression && another unpleasantly long boolean expression && yet another unpleasantly long boolean expression ) { In SQL, C's alternative approaches are not available, and the "comma-first" style is much more natural: where unpleasantly long boolean expression and another unpleasantly long boolean expression and yet another unpleasantly long boolean expression I do agree, though, that it's better to design languages to avoid this problem, and I think the way to do that is by using item terminators or item initiators in a list rather than by using item separators. That's what C did for statements with `;`, which was a difference from the ALGOL tradition including Pascal, where `;` was a statement separator, with the unpleasant consequences described in https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pascal.html https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pas.... In Meta5ix http://www.canonical.org/~kragen/sw/dev3/meta5ixrun.py http://www.canonical.org/~kragen/sw/dev3/meta5ixrun.py I experimented with using item initiators for rules in a grammar, like Markdown uses for bulleted lists. I'm not pleased with the rest of the syntactic decisions I tried in Meta5ix, but I do think that one was a good tradeoff; here's about a quarter of the Meta5ix compiler: - terms: term ["," {continue $choice} term] @choice - term: (factor {else $seq}, output) [factor {assert}, output] @seq - factor: string {literal $it} , "(" terms ")" , "[" @many terms {continue $many} "]" Note that, while comma-first layout feels like a gross abuse of a punctuation mark with `,`, it's quite common and natural with `|` in grammars and pattern-matches in languages like ML, where an initial `|` is also permitted; here's an excerpt from my port of μKanren to OCaml (http://canonical.org/~kragen/sw/dev3/mukanren.ml http://canonical.org/~kragen/sw/dev3/mukanren.ml): let rec walk (s : env) = function | Vart (Var x) when Env.mem x s -> walk s (Env.find x s) | u -> u I think that's what I should have used in Meta5ix, and I will if I get around to revising it.
arnsholt 1y ago
Underscore for italics probably has its origins in the use of a solid underline as markup in a manuscript/typescript instructing the typesetter to set that fragment in italics (underscore generally being frowned upon in professionally set material otherwise, I think).
mananaysiempre 1y ago
It’s an old convention that underline in a manuscript (handwritten or typewritten) directs the typesetter to use italics (as underlines are basically nonexistent in professional typesetting before the WWW). I expect that this is where the _italics_ thing (which predates Markdown) comes from. (There is precedent for /italics/ and I don’t think it’s unreasonable, but it is much rarer.)
- chrisldgk 1y ago
  To add to this, when I went to school for design a long time ago, our typography teacher basically told us to never use underlines if we can use italics instead. It tends to mess with the readability of a paragraph and shifts the visual center of gravity downward, making text more difficult to parse. I assume that’s also why italics and underline seem to be used interchangeably from time to time, since they generally achieve the same goal of emphasizing text in the same semantic manner.
andrewingram 1y ago
I always preferred Textile over Markdown for reasons like this, so was a little sad when Markdown won the popularity contest.
otikik 1y ago
Clearly it should be *bold*, _underline_ and /italics/
- stevage 1y ago
  and -strikethrough-
  - oneeyedpigeon 1y ago
    ~strikethrough~ is pretty well established and far less risky than overloading hyphens.

philipwhiuk 1y ago

The trailing comma trend is almost entirely down to line-based diff tools as far as I can tell.

perching_aix 1y ago
Git is generally insufferable when it comes to these. Diffing YAMLs is even worse, and it gets downright hideous when the specific document you're working with betrays YAML's rules about orderedness (the document is order invariant, while YAML is ordered). In that case, even most semantic diffing tools become unusable. This is a thing with JSON too, arrays are ordered. I've been recently using dyff [0] to diff YAMLs in an order invariant way, and it's been absolutely liberating. Couldn't help with version control, but it's still night and day. [0] https://github.com/homeport/dyff https://github.com/homeport/dyff
arccy 1y ago
it's also annoying to edit, copy a line, add it to the end of a block. now you need to add a comma to the previous line, and strip off the comma on the new one you added (if you copied it from not the previous line).
ithkuil 1y ago
I wonder how much json aware diff representation and merge conflict resolution would remove the need of having the trailing comma
- usrusr 1y ago
  I'd rather have a format supporting a friendly truth on the ground (on the filesystem) than adding yet another "almost like standard behavior" quirk to tooling.
dspillett 1y ago
It can also help eliminate some editing errors, when copying entries to extend a list or reordering entries. I prefer leading commas to having a final comma with an empty clause, though some people hate that and they don't really solve all the final-entry issues (they address some of them, but others are just moved to being first-entry issues).
stevage 1y ago
Huh, I don't know about that. I find it much more convenient for editing because it means the last item in a list doesn't behave differently when it comes to cut/copy/paste.
- deleted 1y ago
  [deleted]
wahern 1y ago
Trailing commas were common in language design long before JSON or even JavaScript existed as it simplifies machine generation of code while being comparatively trivial to handle in a parser, so a net win. The convenience it offers for diffing is just a manifestation of the positive interaction with grammars and language tools. The convention of humans using trailing commas in lists, along with one item per line, is relatively new, though. Stylistically, this used to be frowned upon as long definition lists made source files longer, slower to scroll through, and worsened code locality from the perspective of someone using, e.g., a 25 row terminal.
kragen 1y ago
Trailing commas avoid having the last item behave differently, but they're easy to accidentally omit when they're optional. [ "or" , "alternatively" , [ "the" , "first" , "item" ] , "could" , "behave" , "differently" ] I feel that, despite its repugnant appearance, this "comma-first" approach is the best tradeoff in languages like JSON where trailing commas are forbidden; the leading `[` is much harder to accidentally omit or insert than the subtle trailing `,`. In Emacs I use js3-mode, a hack of js2-mode to support comma-first syntax. Comma-first syntax is especially convenient in SQL, which has the forbidden-trailing-comma problem and several analogous problems. In C if I have a long Boolean conjunction if (unpleasantly long boolean expression && another unpleasantly long boolean expression && yet another unpleasantly long boolean expression) { there are several ways to fix it, such as nesting ifs or factoring the expressions into variables or functions. The "comma-first" approach is also visually unappealing for spacing reasons, requiring two extra spaces after the parenthesis: if ( unpleasantly long boolean expression && another unpleasantly long boolean expression && yet another unpleasantly long boolean expression ) { In SQL, C's alternative approaches are not available, and the "comma-first" style is much more natural: where unpleasantly long boolean expression and another unpleasantly long boolean expression and yet another unpleasantly long boolean expression I do agree, though, that it's better to design languages to avoid this problem, and I think the way to do that is by using item terminators or item initiators in a list rather than by using item separators. That's what C did for statements with `;`, which was a difference from the ALGOL tradition including Pascal, where `;` was a statement separator, with the unpleasant consequences described in https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pascal.html https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pas.... In Meta5ix http://www.canonical.org/~kragen/sw/dev3/meta5ixrun.py http://www.canonical.org/~kragen/sw/dev3/meta5ixrun.py I experimented with using item initiators for rules in a grammar, like Markdown uses for bulleted lists. I'm not pleased with the rest of the syntactic decisions I tried in Meta5ix, but I do think that one was a good tradeoff; here's about a quarter of the Meta5ix compiler: - terms: term ["," {continue $choice} term] @choice - term: (factor {else $seq}, output) [factor {assert}, output] @seq - factor: string {literal $it} , "(" terms ")" , "[" @many terms {continue $many} "]" Note that, while comma-first layout feels like a gross abuse of a punctuation mark with `,`, it's quite common and natural with `|` in grammars and pattern-matches in languages like ML, where an initial `|` is also permitted; here's an excerpt from my port of μKanren to OCaml (http://canonical.org/~kragen/sw/dev3/mukanren.ml http://canonical.org/~kragen/sw/dev3/mukanren.ml): let rec walk (s : env) = function | Vart (Var x) when Env.mem x s -> walk s (Env.find x s) | u -> u I think that's what I should have used in Meta5ix, and I will if I get around to revising it.

arnsholt 1y ago

Underscore for italics probably has its origins in the use of a solid underline as markup in a manuscript/typescript instructing the typesetter to set that fragment in italics (underscore generally being frowned upon in professionally set material otherwise, I think).

mananaysiempre 1y ago

It’s an old convention that underline in a manuscript (handwritten or typewritten) directs the typesetter to use italics (as underlines are basically nonexistent in professional typesetting before the WWW). I expect that this is where the _italics_ thing (which predates Markdown) comes from. (There is precedent for /italics/ and I don’t think it’s unreasonable, but it is much rarer.)

chrisldgk 1y ago
To add to this, when I went to school for design a long time ago, our typography teacher basically told us to never use underlines if we can use italics instead. It tends to mess with the readability of a paragraph and shifts the visual center of gravity downward, making text more difficult to parse. I assume that’s also why italics and underline seem to be used interchangeably from time to time, since they generally achieve the same goal of emphasizing text in the same semantic manner.

andrewingram 1y ago

I always preferred Textile over Markdown for reasons like this, so was a little sad when Markdown won the popularity contest.

otikik 1y ago

Clearly it should be *bold*, _underline_ and /italics/

stevage 1y ago
and -strikethrough-
- oneeyedpigeon 1y ago
  ~strikethrough~ is pretty well established and far less risky than overloading hyphens.