On Mon, May 23, 2022 at 10:33 AM Juan Manuel Macías
<maciasch...@posteo.net> wrote:
> I think this idea was suggested by Ihor in a thread from a few months
> ago (I don't remember which one), but since other topics were discussed,
> the idea remained a bit in limbo. I still find the idea very
> interesting, and I think it would be very productive for Org to have a
> multipurpose inline container, so it occurred to me to open this thread
> to invite a possible discussion on the subject.
Thanks for doing this. I missed that thread. I would welcome this
feature addition too.
If I understand correctly, this will mean adding a new element type
that all the Org exporters can then support. Right?
> The question is: Does Org Mode need inline special blocks?
Yes.
> On the one hand, it seems that we can live without them.
Not quite. I developed few hacks in ox-hugo to make regular special
blocks act like special inline blocks :D
Example:
=====
More than the visual inaccuracy of seeing curved quoted where straight
quotes should be,
#+begin_mark
if someone copies that code to try it out, it will
not work
#+end_mark
!
=====
Another example:
=====
By the way, I submitted a patch for fixing the escaping of straight
quotes in ~shortdoc-add-function~ documentation string
#+begin_sidenote
I planned to fix just this straight quote escaping issue, but then I
also ended up slightly improving the documentation of the ~(FUNC :eval
EVAL)~ and other forms used for adding a function's documentation to
~shortdoc~.
#+end_sidenote
in ..
=====
ox-hugo does the job of deleting the newlines and white-space (leaving
just 1) before and after few "special" special Org blocks.
> Therefore, I think that inline special blocks would fill an important
> gap. They could be translated into HTML as a <span></span> container;
+1
> Perhaps the syntax could be a continuation of that of inline code
> blocks. Something like:
>
> <name>_[options]{text}
The challenging part will be deciding the syntax so that there are no
false matches.
May be reserve "inline_" for inline blocks?
e.g. inline_<name>[options]{text} ?
Using my example above, if I want the <mark> elements in HTML, I would do
abc inline_mark{some text} def
and that would export to below for an HTML based exporter:
abc <mark>some text</mark> def
