[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
sound.
> 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.
- About 'inline special blocks', Juan Manuel Macías, 2022/05/23
- Re: About 'inline special blocks', Kaushal Modi, 2022/05/23
- Re: About 'inline special blocks', Juan Manuel Macías, 2022/05/23
- Re: About 'inline special blocks',
Tim Cross <=
- Re: About 'inline special blocks', Ihor Radchenko, 2022/05/23
- Re: About 'inline special blocks', João Pedro, 2022/05/24
- Re: About 'inline special blocks', Ihor Radchenko, 2022/05/26
- Re: About 'inline special blocks', João Pedro, 2022/05/26
- Re: About 'inline special blocks', Ihor Radchenko, 2022/05/26
- Re: About 'inline special blocks', João Pedro, 2022/05/26
- About opening issues vs email [Was: About 'inline special blocks'], Kaushal Modi, 2022/05/26
- Re: About opening issues vs email [Was: About 'inline special blocks'], Ihor Radchenko, 2022/05/27
- Re: About opening issues vs email [Was: About 'inline special blocks'], João Pedro, 2022/05/27
- Re: About 'inline special blocks', Juan Manuel Macías, 2022/05/25