[Top][All Lists]

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

Re: About 'inline special blocks'

From: Kaushal Modi
Subject: Re: About 'inline special blocks'
Date: Mon, 23 May 2022 11:20:08 -0400

On Mon, May 23, 2022 at 10:33 AM Juan Manuel Macías
<maciaschain@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?


> 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


More than the visual inaccuracy of seeing curved quoted where straight
quotes should be,
if someone copies that code to try it out, it will
not work

Another example:

By the way, I submitted a patch for fixing the escaping of straight
quotes in ~shortdoc-add-function~ documentation string
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
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;


> 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

reply via email to

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