3 ms·

In Org-Mode you have a separate syntax for footnotes, for properties(`#+FOO`), for heading properties(`:FOO:`), for results of code executions, for time trackin

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.
    - Jtsummers 5y ago
      They called out the results of source blocks, which you can already get in a variety of formats so JSON wouldn't be a bad option to add. But yes, we are in agreement. It wouldn't be much better for someone typing directly into org files. It's the same reason markdown and other formats get translated into HTML, heavyweight markups are annoying to type, even if consistent. It might be better for tooling around org-mode, but at that point you're pushing away from org files as plaintext entities meant to be directly edited and towards them being serialization formats you interact with through other programs.
      - taeric 5y ago
        Ah, so they did. Reading for the win. :)

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.
  - Jtsummers 5y ago
    They called out the results of source blocks, which you can already get in a variety of formats so JSON wouldn't be a bad option to add. But yes, we are in agreement. It wouldn't be much better for someone typing directly into org files. It's the same reason markdown and other formats get translated into HTML, heavyweight markups are annoying to type, even if consistent. It might be better for tooling around org-mode, but at that point you're pushing away from org files as plaintext entities meant to be directly edited and towards them being serialization formats you interact with through other programs.
    - taeric 5y ago
      Ah, so they did. Reading for the win. :)