[Top][All Lists]

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

Re: About 'inline special blocks'

From: Tim Cross
Subject: Re: About 'inline special blocks'
Date: Tue, 24 May 2022 12:36:07 +1000
User-agent: mu4e 1.7.23; emacs 28.1.50

I've not got a lot to add here. I'm not against the idea, but Juan makes
some points below which I think are particularly important and wanted to
add weight to them!

Juan Manuel Macías <maciaschain@posteo.net> writes:

> Hi, Kaushal, thanks for all your interesting comments,
> Kaushal Modi writes:
>> 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}  ?
> It seems to me the most consistent option, if we continue in some way
> the syntax of the inline code blocks, which would be the close relatives
> of the inline special blocks. Perhaps (to shorten the syntax a bit)
> 'inline' could be replaced by some reserved symbol. Something like:
> &_<name>[options]{text}

I agree. Selection of the 'symbol' might be tricky, but the idea is

> I think a major issue would also be how to properly compact <[options]>
> so as not to result in too overloaded syntax. Maybe something like:
> [latex(list of attributes) html(list of attributes)...]
> ?
> But that is an abuse of direct formatting, which I think should always be
> avoided, especially in a format-agnostic environment like Org, which is
> more of a logician than a typesetter :-)

I think this is a really important point. Whenever we add formatting
specific directives, we always end up in a somewhat uncertain situation
with respect to the other back ends. I also feel that in-line blocks
which support large and complex formatting configuration really defeat
the purpose of an in=line block (which I feel should be kept relatively
simple). I also find complex constructs of this form really degrades the
readability of source documents. 

> And, in any case, it is to be expected that the user will not need to
> overload that part, since these hypothetical inline blocks would be
> intended for short segments of text within the paragraph. I think the
> most typical use case would be something like your 'mark' example.

Yes, that was my thinking as well. 

reply via email to

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