5 ms·

you cringe at the thought of json but not xml?

taeric 5y ago
Honestly, yeah. But mainly because I don't see xml getting picked. Xml is at least a markup language. Json is not. Encoding a document with it is terrible. Just look at Jupyter some time.
- alpaca128 5y ago
  I never suggested encoding a document in JSON. I would use a similar syntax for annotations of text elements. Both Markdown and Org support similar things(e.g. tagging a heading) but with inconsistent, inflexible syntax. I don't think anything beats JSON in that area, definitely not XML. Specifically I'd prefer something along the lines of JSON5 for the sake of sanity, which is just better for human-readable and editable content.
  - taeric 5y ago
    I don't see what json gets you that a standard delimited tag didn't get. Such that org's footnote tags already work well here. Or just... Hyperlinks in general. What would you use json to encode that https://foo/baz https://foo/baz shouldn't already handle? And, if you ack that links are already links, the standard of either [display](link) or [[display][link]] seems as nice as json could possibly get.
    - alpaca128 5y ago
      In Org-Mode you have a separate syntax for footnotes, for properties(`#+FOO`), for heading properties(`:FOO:`), for results of code executions, for time tracking, and so on. You could express all those metadata in one consistent notation, as an example JSON which would also be more compact and not as clunky. Hyperlinks and text styling can still be done with the usual methods, though I don't quite like how in md/org I constantly forget where the label and the url goes in the hyperlink syntax. Also some of the text styling could use slight modifications to reduce the need for escaping. I'm not saying Org-Mode lacks major features or anything, I'm just the kinda guy who likes to tinker and experiment with new ideas.
      - taeric 5y ago
        Fair. I'm the kind to tinker with the old ideas. :D I'm not really seeing any benefit that json or the like would bring to the table here. I could almost see a benefit to not having different ways to make properties, but only a little. Since it is basically just a mark that is intended to indicate different types of marked up text. As an example, if moved to json, how would you distinguish the likes of an example block? Just a json header with no closing tag? Or a json header with another json close? I guess, put more directly. Orgmode is a bit of an adhoc markup language. The designating tags to start and end a block are typically $+BEGIN_FOO and #+END_FOO. With free text between them, and a lot of magic from emacs to syntax highlight based on FOO. Unless you are just going to change to {"BEGIN":"FOO"} and {"END:"FOO"}, with free text between, you are forcing human edited text into a json field, and that is what makes me cringe. And if that is your end goal, {"BEGIN":"FOO"} is actually a chore to type and read. Yes, it composes somewhat nicely such that #+NAME: Example #+BEGIN_SRC lisp (+ 3 2) #+END_SRC could be: {"NAME":"EXAMPLE", "BEGIN": "src", "lang": "lisp"} (+ 3 2) {"END":"src"} But, quite frankly, that looks worse to me. What is json bringing to the table?
        Jtsummers 5y ago
        I think GP is suggesting it in other places, like replacing: #+STARTUP: indent #+OPTIONS: ^:nil With something more like: { "STARTUP" : ["indent"], "OPTIONS" : { "^":null} } That is, not using it to markup the document proper, but to encode all the various metadata bits in a more uniform notation. I disagree that it's less clunky than the present situation, but it may be more consistent. I mean, you'd still need something to mark that some JSON follows and is separate from the other text in the document. #+CONFIG: <JSON String> S-expressions would make more sense, if we're sticking with emacs lisp anyways. But would still be clunkier than the current system at least for writers. Maybe better for people trying to implement org-mode (fully) in other systems.
        taeric 5y ago
        The gp mentioned source blocks, so I picked up there. It looks like you and I are in agreement? That it may be more consistent, due to it always being json. But it hardly seems any better.

Honestly, yeah. But mainly because I don't see xml getting picked. Xml is at least a markup language. Json is not. Encoding a document with it is terrible. Just look at Jupyter some time.

alpaca128 5y ago
I never suggested encoding a document in JSON. I would use a similar syntax for annotations of text elements. Both Markdown and Org support similar things(e.g. tagging a heading) but with inconsistent, inflexible syntax. I don't think anything beats JSON in that area, definitely not XML. Specifically I'd prefer something along the lines of JSON5 for the sake of sanity, which is just better for human-readable and editable content.
- taeric 5y ago
  I don't see what json gets you that a standard delimited tag didn't get. Such that org's footnote tags already work well here. Or just... Hyperlinks in general. What would you use json to encode that https://foo/baz https://foo/baz shouldn't already handle? And, if you ack that links are already links, the standard of either [display](link) or [[display][link]] seems as nice as json could possibly get.
  - alpaca128 5y ago
    In Org-Mode you have a separate syntax for footnotes, for properties(`#+FOO`), for heading properties(`:FOO:`), for results of code executions, for time tracking, and so on. You could express all those metadata in one consistent notation, as an example JSON which would also be more compact and not as clunky. Hyperlinks and text styling can still be done with the usual methods, though I don't quite like how in md/org I constantly forget where the label and the url goes in the hyperlink syntax. Also some of the text styling could use slight modifications to reduce the need for escaping. I'm not saying Org-Mode lacks major features or anything, I'm just the kinda guy who likes to tinker and experiment with new ideas.
    - taeric 5y ago
      Fair. I'm the kind to tinker with the old ideas. :D I'm not really seeing any benefit that json or the like would bring to the table here. I could almost see a benefit to not having different ways to make properties, but only a little. Since it is basically just a mark that is intended to indicate different types of marked up text. As an example, if moved to json, how would you distinguish the likes of an example block? Just a json header with no closing tag? Or a json header with another json close? I guess, put more directly. Orgmode is a bit of an adhoc markup language. The designating tags to start and end a block are typically $+BEGIN_FOO and #+END_FOO. With free text between them, and a lot of magic from emacs to syntax highlight based on FOO. Unless you are just going to change to {"BEGIN":"FOO"} and {"END:"FOO"}, with free text between, you are forcing human edited text into a json field, and that is what makes me cringe. And if that is your end goal, {"BEGIN":"FOO"} is actually a chore to type and read. Yes, it composes somewhat nicely such that #+NAME: Example #+BEGIN_SRC lisp (+ 3 2) #+END_SRC could be: {"NAME":"EXAMPLE", "BEGIN": "src", "lang": "lisp"} (+ 3 2) {"END":"src"} But, quite frankly, that looks worse to me. What is json bringing to the table?
      - Jtsummers 5y ago
        I think GP is suggesting it in other places, like replacing: #+STARTUP: indent #+OPTIONS: ^:nil With something more like: { "STARTUP" : ["indent"], "OPTIONS" : { "^":null} } That is, not using it to markup the document proper, but to encode all the various metadata bits in a more uniform notation. I disagree that it's less clunky than the present situation, but it may be more consistent. I mean, you'd still need something to mark that some JSON follows and is separate from the other text in the document. #+CONFIG: <JSON String> S-expressions would make more sense, if we're sticking with emacs lisp anyways. But would still be clunkier than the current system at least for writers. Maybe better for people trying to implement org-mode (fully) in other systems.
        taeric 5y ago
        The gp mentioned source blocks, so I picked up there. It looks like you and I are in agreement? That it may be more consistent, due to it always being json. But it hardly seems any better.