> On Jun 14, 2026, at 11:04, Ihor Radchenko <[email protected]> wrote:
>
> Perry Smith <[email protected]> writes:
>
>> I want to add to the emphasis possibilities. Currently there are six and I
>> believe I want / need a few more. I have looked at the code a little and
>> found some old messages about the topic. There was a suggestion of
>> something being added to the third party contributions but I didn’t see
>> anything.
>>
>> I’m looking for any advice, suggestions, dangers, etc.. before diving into
>> this experiment.
>
> I am not sure if I understand you correctly, but are you suggesting to
> add additional emphasis syntax to Org mode itself? Or just ox-html?
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.
For example, in org.el, org-emphasis-alist is defined with a defcustom and each
attribute has the option to be verbatim. But it really doesn’t. org-emph-re
and org-verbatim-re are set in org-set-emph-re but "*/_+” is hard coded in the
first case and “=~” in the latter. Somewhere in the export to html chain, the
same assumptions are made and org-emphasis-alist is not referenced anywhere
outside of org.el.
So… I got rather disenchanted and assumed no one really wanted to dig into it.
I think making the changes I dreamed about will surely lead to some breaks
along the way. And… in the bigger picture of things, I honestly don’t know
what the target audience of Org mode is meant to be. But… for what it is
worth, here is my dreams and arguments.
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.
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.
As I said, I dug into the code for a day or two and decided the disruption
(code breakage, etc) would be more significant than people would want to take
on and I currently don’t know enough about the export process nor all the way
Org mode is used to do this by myself.
