[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Org-syntax: Intra-word markup

From: Max Nikulin
Subject: Re: Org-syntax: Intra-word markup
Date: Wed, 2 Feb 2022 22:28:55 +0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0

Ihor Radchenko writes:
Keeping in mind the above analogy, note that export blocks do not have
fallbacks, while special blocks do (for example, see

Ihor, I am sorry, but I missed your point. That project provides some set of defined link+block pairs and some macros to define new links/pairs. I do not see relation to export snippets or blocks that are used when their content is not intended to be reusable.

Maybe we should introduce an equivalent of special blocks, but for
inline use? Or should we modify _both_ inline export snippets and export
blocks to allow fallback mechanism?

I suppose, it should be consistent to consider adjacent export blocks as alternatives and to allow "fallback" or "default" block. Again, similar to @@:...@@ snippets, block content should be parsed as Org markup.

On 29/01/2022 20:05, Juan Manuel Macías wrote:
I find the idea of inline special blocks very interesting, but I think
there are a couple of drawbacks: since special blocks support ATTR_X,
how would that be implemented in the inline version? The most obvious
thing I can think of is to mimic inline code blocks:

my_special_block[attributes list]{content}

ATTR_X attributes are supported for links as well, see
info "(org) Links in HTML export"
However it is rather verbose, may have problems with LaTeX, and I am unsure if they can be accessed from export link handlers

Actually I do not like src_something[...]{...} syntax since there is no clear mark (such as "\") at the beginning that it is a special construct.

In any case, for things like that, aren't links and macros enough?

Ad hoc code for particular backends (and discussed fallback for other backends) is a bit different thing. It may be used in macros, but macros can not replace it. Moreover @@:...@@ construct proposed by Tom would allow e.g.
to be half-word bold and half-word italics without invisible zero width spaces and filters to remove them.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]