1. 26
    1. 7

      I like the idea of having a standard around Org’s markup, but I hate the proposed name. It’s obviously derived from Markdown, but for Markdown the name makes a lot of a sense (a markup with less syntax, hence a markdown on markup). Orgdown seems like a meaningless name.

      1. 1

        Err doesn’t it have the same meaning? Orgdown1 is similar level of syntax as markdown.

        1. 6

          I meant simply the word play between “markdown” (which also means “discount”) and “markup” (which also means increase in price). :-) Naming is hard!

    2. 3
    3. 2

      I like org mode syntax a lot. I use an orgmode plugin for neovim, so I generally support the idea of bringing the syntax outside of emacs.

      However, my main gripe with org syntax is not addressed here, and I think it’s a real obstacle to wider adoption.

      The problem: it’s really hard to type literal characters instead of invoking their formatting.

      For example, this/that results in everything after the slash to be italic, and x * y makes everything after the star bold. The solution (in emacs) is to insert a zero width character as an escape.

      This is unreasonably difficult to expect users to do on a regular basis, and is actually something that markdown’s permissive formatting mostly addresses.

      While the author specifically deries markdown for this syntax style as inconsistent, I would love to see Orgdown take more from it’s second namesake in this regard.

      1. 1

        FWIW, it’s been a while since your examples would trigger org mode formatting. I vaguely remember having such issues a decade ago, but nothing in recent memory. In relatively current Org Mode (9.4 on my machine), neither of this/that or x * y trigger formatting.

        The current formatting rules are such that spaces are explicitly forbidden as inner-border characters, and only a small subset of characters is allowed on either side of the would-be emphasis. Meaning that foo *bar* baz makes bar bold, but foo * bar* baz does not; x/y/z does not italicize y, etc. It behaves as one would expect - about the only exception I encounter in practice is that /foo/bar/baz/ will render as italicized foo/bar/baz (but if you’re typing in folder paths or sed expressions, you want to wrap them in = or ~ verbatim/code markers anyway).

        (If you’re interested in details, check out org-emphasis-regexp-components variable and associated docstring.)

        I think the current behavior is pretty sane, and enshrining it in a standard like the author wants would help alleviate concerns like this.

        1. 2

          This is really good to know, thanks for taking the time to reply! I’m not using the native Emacs implementation, it’s

          1. Good to know this has been addressed there for a while
          2. Supports your point that standardizing will help external implementations, like the one I’m using
    4. 2

      I do think that org-mode markup would be a perfectly cromulent thing to serve over Gemini. Currently, I write Gemini pages in org-mode (mainly so that my drafts can live in org-roam) and export with ox-gemini. If I wrote a client, I might well include support for org-mode text.

    5. 1

      Every time someone creates a new Markdown variant, a kitten dies :(

      1. 3

        You monster!