Max Nikulin writes:
>> No, not zero-width space. Literally, {{...}}. The idea is to define
>> delimiters as "[{]+" the matching number of "}". This way, we do not
>> need to worry about escaping "}" inside and can get nested markup for
>> free. It is more or less how Org parser works for special
On 16/12/2023 21:44, Ihor Radchenko wrote:
Max Nikulin writes:
@wrap{{outer wrap; @wrap{{inner wrap allowing } as well}}; back}}.
Are you assuming invisible zero-width space as a way to escape literal
{{ or }}? I would prefer some visible characters.
No, not zero-width space. Literally, {{.
Max Nikulin writes:
>> @wrap{{outer wrap; @wrap{{inner wrap allowing } as well}}; back}}.
>
> Are you assuming invisible zero-width space as a way to escape literal
> {{ or }}? I would prefer some visible characters.
No, not zero-width space. Literally, {{...}}. The idea is to define
delimiters
On 14/12/2023 22:23, Ihor Radchenko wrote:
Not necessarily. The current parser also allows balanced brackets inside
an object.
Thanks, I forgot about it. Balancing of brackets alleviates the issue
with nested objects. I am unsure if it is still pure top-down parser,
but it does not matter.
Max Nikulin writes:
>> Nested objects of the same type are not really a limitation of top-down
>> parser. It is the syntax of objects that might but does not have to be.
>> We might come up with a syntax that allow nesting.
>
> I would be glad to learn that I am wrong. The current parser picks fi
On 12/12/2023 20:18, Ihor Radchenko wrote:
Max Nikulin writes:
It is limitation of top-down parser that object of the same time can not
be nested, so I am unsure if special blocks would be solution in all cases.
Nested objects of the same type are not really a limitation of top-down
parser. I
Max Nikulin writes:
>> I believe that the right way to go here is what we previously discussed
>> as inline special block equivalent. That way, we will not need to create
>> workarounds with special link type.
>
> It is limitation of top-down parser that object of the same time can not
> be nest
On 05/12/2023 20:46, Ihor Radchenko wrote:
We definitely need something to fine-tune export properties inline.
However, I am skeptical about using links for this purpose in Org
proper, not individual user configs.
Sometimes links are really links, however some links require some
tuning. Globa
Max Nikulin writes:
> I raised this topic earlier. It seems, there is a rather generic
> workaround that may help.
>
> Sometimes it is necessary to assign specific export attributes to some
> links in a paragraph while others should get another set of them. Inline
> images should have differen
