Re: naming: Re: Experimental public branch for inline special blocks

[Ihor Radchenko]

Max Nikulin  writes:

> Ihor, I see you intention, however I reserve my vote for some new unique 
> word, preferably a single one.

That's fine. I do not insist on my preferences about naming. Rather see
it as a minor issue that can be resolved at any moment after we
implement the functionality. Maybe using a proper poll.

Let's register that we have some disagreement here. To be resolved
before we finalize things.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: naming: Re: Experimental public branch for inline special blocks

[Max Nikulin]

On 08/03/2024 12:26, Samuel Wales wrote:

cannot follow discussion but is the role and scope of the proposed
semantics settled and agreed upon by those who do?


I think, there are enough issues with the proposed feature to discuss. 
Notice "naming" added to the message subject with hope to facilitate 
tracking of specific aspects.


Ihor, I see you intention, however I reserve my vote for some new unique 
word, preferably a single one.

Re: naming: Re: Experimental public branch for inline special blocks

[Samuel Wales]

cannot follow discussion but is the role and scope of the proposed
semantics settled and agreed upon by those who do?

Re: naming: Re: Experimental public branch for inline special blocks

[Ihor Radchenko]

Max Nikulin  writes:

>> IMHO, the whole point of the discussed construct is exactly being abstract
>> and multi-purpose.
>
> Almost everything in Org syntax may be called "markup", so using this 
> word for a specific object may lead to confusion unless a couple of 
> extra words are added to make it clear what kind of markup is referred to.

Yup. "inline custom markup". I feel that it's enough. Do I miss something?

> I had an idea to name new object "markup macro" since its role is close 
> to existing macro ("substitution macro"), but I discarded it because 
> "markup" is too general.

I do not find "too general" as a big problem.
I am not sure if I like macro. "macro" feels like something replaced
literally, without extra processing. But the proposed object has little
to do with literal replacement.

>>> Decorators sometimes stressed as "inline decorators"?
>> 
>> I dislike "decorators" because it is not a term we use anywhere in Org
>> mode. I'd prefer to reuse an existing term, if at all possible.
>
> I had a hope to find a unique word that will be convenient for usage in 
> discussions, a term that will be uniformly used in the manual and in the 
> syntax specification.

Manual was one of the reasons I chose "markup". Because this word is
used in "Markup for Rich Contents" section of the manual. Further, we
refer to "markup" when talking about emphasis/monospace in "12.2
Emphasis and Monospace" section.

> If others are happy to name "block" instances that are neither solid nor 
> shaped as blocks then I see no point to continue this discussion.

I am slightly in favor of "markup" vs. "block".

> P.S. I am neutral in respect to "span".

I do not like this for the same reason as "decorators" - unfamiliar
terminology.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: naming: Re: Experimental public branch for inline special blocks

[Max Nikulin]

On 06/03/2024 17:56, Ihor Radchenko wrote:

Max Nikulin writes:


Custom inline markup.


"Markup" is something abstract to my taste. I would prefer something
related to concrete instances of such objects.


IMHO, the whole point of the discussed construct is exactly being abstract
and multi-purpose.


Almost everything in Org syntax may be called "markup", so using this 
word for a specific object may lead to confusion unless a couple of 
extra words are added to make it clear what kind of markup is referred to.


I had an idea to name new object "markup macro" since its role is close 
to existing macro ("substitution macro"), but I discarded it because 
"markup" is too general.



Decorators sometimes stressed as "inline decorators"?


I dislike "decorators" because it is not a term we use anywhere in Org
mode. I'd prefer to reuse an existing term, if at all possible.


I had a hope to find a unique word that will be convenient for usage in 
discussions, a term that will be uniformly used in the manual and in the 
syntax specification.


If others are happy to name "block" instances that are neither solid nor 
shaped as blocks then I see no point to continue this discussion.


P.S. I am neutral in respect to "span".

Re: naming: Re: Experimental public branch for inline special blocks

[Ihor Radchenko]

Max Nikulin  writes:

>> Custom inline markup.
>
> "Markup" is something abstract to my taste. I would prefer something 
> related to concrete instances of such objects.

IMHO, the whole point of the discussed construct is exactly being abstract
and multi-purpose.

> Decorators sometimes stressed as "inline decorators"?

I dislike "decorators" because it is not a term we use anywhere in Org
mode. I'd prefer to reuse an existing term, if at all possible.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: naming: Re: Experimental public branch for inline special blocks

[Max Nikulin]

On 05/03/2024 00:29, Ihor Radchenko wrote:

Max Nikulin writes:


Does anybody have an idea of a better name for a feature? Maybe
something like inline custom objects, snippets. "Objects" are used to
describe syntax, but not used in the manual though.


Custom inline markup.


"Markup" is something abstract to my taste. I would prefer something 
related to concrete instances of such objects.


Decorators sometimes stressed as "inline decorators"?

Re: naming: Re: Experimental public branch for inline special blocks

[Suhail Singh]

Suhail Singh  writes:

> ... due to the similarity with "inline code blocks" (cf. "code
> blocks") as well as "special blocks".

.. due to the /relation/ with "inline code blocks" (cf. "code blocks")
as well as "special blocks".

> But if it were to, I do hope the names of other similar syntactic
> terms are similarly updated.

But if it were to, I do hope the names of other /related/ syntactic
terms are similarly updated.

-- 
Suhail

Re: naming: Re: Experimental public branch for inline special blocks

[Suhail Singh]

Ihor Radchenko  writes:

> In my mind, "fragment" implies no nesting.

FWIW, in the mind of this Org mode user as well.

> But the point of the "inline special blocks" is to allow nesting as
> needed.

Yes, exactly!  As "inline code blocks" are to "code blocks" so too are
"inline special blocks" to "special blocks".

I generally try and abstain from bike-shedding, but as a data point, the
intent of "inline special blocks" was quite clear to me based on the
name alone.  This was, in no small part, due to the similarity with
"inline code blocks" (cf. "code blocks") as well as "special blocks".

I hope the name of this "syntactic object", when incorporated into Org
mode, doesn't change.  But if it were to, I do hope the names of other
similar syntactic terms are similarly updated.

-- 
Suhail

Re: naming: Re: Experimental public branch for inline special blocks

[Juan Manuel Macías]

Max Nikulin writes:

> Special blocks are really block-level elements. I see similarity,
> however with a better term we could avoid "inline" specifier. I think,
> the new beast may serve in some cases currently handled by macros.
> LaTeX snippets are named "fragments" in the manual.
>
> Custom fragment?

I think "custom" is an important part of defining the new object. Unlike
other elements/objects, such as emphasis marks, this one does not add
any (let's say) "logical or semantic" information. I mean, emphasis
marks (to continue with the example) are useful when reading an Org
document as it is. But the new object is rather a segment of text that
must be exported in a certain way to LaTeX, odt, HTML, etc. Something
like "{some text}" does not provide any information to the reader,
but rather to the exporters and the output format. So, how about
something like:

- Custom Export Fragment

- Custom Export Span

- Custom Export "Whatever"

- ...

?

(I especially like "span" because of the similarity with html and family.
Pandoc uses the term bracketed spans for its custom markdown).

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño 
editorial y ortotipografía

Re: naming: Re: Experimental public branch for inline special blocks

[Ihor Radchenko]

Max Nikulin  writes:

> Special blocks are really block-level elements. I see similarity, 
> however with a better term we could avoid "inline" specifier. I think, 
> the new beast may serve in some cases currently handled by macros. LaTeX 
> snippets are named "fragments" in the manual.
>
> Custom fragment?

Not sure if I like it. In my mind, "fragment" implies no nesting. But
the point of the "inline special blocks" is to allow nesting as needed.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: naming: Re: Experimental public branch for inline special blocks

[Max Nikulin]

On 05/03/2024 00:49, Juan Manuel Macías wrote:

Ihor Radchenko writes:

Max Nikulin writes:


Does anybody have an idea of a better name for a feature? Maybe
something like inline custom objects, snippets. "Objects" are used to
describe syntax, but not used in the manual though.


Custom inline markup.


Custom span?

I chose "inline special block" because special blocks, and because of
the parallelism inline code block/code block.


Special blocks are really block-level elements. I see similarity, 
however with a better term we could avoid "inline" specifier. I think, 
the new beast may serve in some cases currently handled by macros. LaTeX 
snippets are named "fragments" in the manual.


Custom fragment?

Re: naming: Re: Experimental public branch for inline special blocks

[Samuel Wales]

[i did not aim that at any particular person!]

On 3/4/24, Samuel Wales  wrote:
> If language is not correct, then what is said is
> not what is meant; if what is said is not what is meant,
> then what must be done remains undone; if this remains
> undone, morals and art will deteriorate; if justice goes
> astray, the people will stand about in helpless
> confusion. Hence there must be no arbitrariness in what is
> said. This matters above everything.  --- analects
>
> On 3/4/24, Juan Manuel Macías  wrote:
>> Max Nikulin writes:
>>
>>> In Org syntax, "elements" are paragraphs and larger parts, while parts
>>> within paragraphs are named objects. I admit that for org-element
>>> everything is element.
>>
>> In my initial message I used 'element' loosely. Note that
>> inline-special-block is included in org-element-all-objects, where
>> inline-src-block is also.
>>
>>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: naming: Re: Experimental public branch for inline special blocks

[Samuel Wales]

If language is not correct, then what is said is
not what is meant; if what is said is not what is meant,
then what must be done remains undone; if this remains
undone, morals and art will deteriorate; if justice goes
astray, the people will stand about in helpless
confusion. Hence there must be no arbitrariness in what is
said. This matters above everything.  --- analects

On 3/4/24, Juan Manuel Macías  wrote:
> Max Nikulin writes:
>
>> In Org syntax, "elements" are paragraphs and larger parts, while parts
>> within paragraphs are named objects. I admit that for org-element
>> everything is element.
>
> In my initial message I used 'element' loosely. Note that
> inline-special-block is included in org-element-all-objects, where
> inline-src-block is also.
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: naming: Re: Experimental public branch for inline special blocks

[Juan Manuel Macías]

Max Nikulin writes:

> In Org syntax, "elements" are paragraphs and larger parts, while parts
> within paragraphs are named objects. I admit that for org-element
> everything is element.

In my initial message I used 'element' loosely. Note that
inline-special-block is included in org-element-all-objects, where
inline-src-block is also.

Re: naming: Re: Experimental public branch for inline special blocks

[Juan Manuel Macías]

Ihor Radchenko writes:

> Max Nikulin  writes:
>
>> Does anybody have an idea of a better name for a feature? Maybe 
>> something like inline custom objects, snippets. "Objects" are used to 
>> describe syntax, but not used in the manual though.
>
> Custom inline markup.

Custom span?

I chose "inline special block" because special blocks, and because of
the parallelism inline code block/code block.

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño 
editorial y ortotipografía

Re: naming: Re: Experimental public branch for inline special blocks

[Ihor Radchenko]

Max Nikulin  writes:

> Does anybody have an idea of a better name for a feature? Maybe 
> something like inline custom objects, snippets. "Objects" are used to 
> describe syntax, but not used in the manual though.

Custom inline markup.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

naming: Re: Experimental public branch for inline special blocks

[Max Nikulin]

On 02/03/2024 03:34, Juan Manuel Macías wrote:


Finally, I have made public on GitLab my experimental branch for the new
(possible) inline-special-block element:


I find the feature name confusing, however I am unsure if others share 
my opinion.


In Org syntax, "elements" are paragraphs and larger parts, while parts 
within paragraphs are named objects. I admit that for org-element 
everything is element.


In CSS "display: inline block" makes an HTML element a rectangular block 
inside a paragraph while new feature is mostly intended for normal text 
flow. I admit that [...]{...} may be used to create an instance 
similar to inline block and that "inline source blocks" are already 
described in the manual.


Does anybody have an idea of a better name for a feature? Maybe 
something like inline custom objects, snippets. "Objects" are used to 
describe syntax, but not used in the manual though.