Perry Smith <[email protected]> writes:
> I was asking about adding emphasis syntax to Org mode itself. I dug into the
> Org code shipped with Emacs and I found that in many places, the mapping of a
> character, e.g. “*” to a particular emphasis like bold is hard coded into
> several places in the code.
I see.
This has been discussed, and adding extra markup similar to */~= is not
planned. We do have plans to add custom markup in a form of
@custom{...}, but that is intentionally made generic and does not
introduce new single-character marks.
> Today is 2026. Keyboards are no longer constrained to 95 characters — at
> least most keyboards. I’m sure there are still some typing away on real
> terminals somewhere. So, why not use characters from Unicode like the
> dagger, double dagger to make emphasis instead of * and +. I don’t know much
> about Unicode. Perhaps there are characters specifically designed for such
> use. No matter what characters are used, simple keymaps can be set up so
> that all the emphasis markers are just a keystroke away.
We have discussed similar ideas. In general, syntax spec is rather
fixed. It is unlikely that we *change* things, although new syntax may
be added. The reason is simple - Org markup is used beyond Emacs, and we
do not want breaking third-party parsers.
Adding new markup is theoretically possible, but I'd rather not use
single-character marks. If we keep adding new such markups, people will
simply get lost. Imagine we use something like †foo† for small
caps. That will be one more thing to learn for users and reduce plain
text readability of the Org document.
> The pain point I experienced was all of my text was cluttered with
> {{{foo(some text)}}} and it was ugly, unreadable, and unmaintainable. I also
> had a lot of “concepts” that I wanted to mark at least in the source text.
> For example variables or output from the process or input to a process. And
> I wanted some simple way that after the fact I could go in and make the
> variables have one font, output another font, etc. Again… Emacs, HTML, EPUB,
> PDF — almost everything today has incredible and beautiful access to fonts,
> weights, color, serif or sans-serif, etc. We should be able to supply so
> much rope to authors that they could make publications as ugly as modern
> architecture!!! :-)
>
> The mechanism to do all this, I fear, would require a lot of changes. I
> guess they are called “transcoders” — the second argument to
> org-export-define-backend. Currently it has separate entries for bold, code,
> italic, strike-through, underline, and verbatim. Each of these entries
> points to a function.
>
> It seems plausible that an entry in org-emphasis-alist (or equivalent list)
> could list the character used to delimit the emphasis, the name of the
> emphasis, and an alist mapping backends to a formatting function. Then the
> export process would reference this list whenever it encountered an emphasis
> or whenever it needed to create a regular expression for parsing, etc. When
> a user wanted to define a new style of emphasis they would need to define
> functions for the backends that they intend to use.
We have previously discussed this as a part of inline special block
syntax proposal. The idea was using more verbose names like
@color['red']{...} or @sans{...} + custom expandable exporters, similar
to how we have custom exporters for various link types.
See https://orgmode.org/list/875xwqj4tl.fsf@localhost
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
