Re: Experimental public branch for inline special blocks

Juan Manuel Macías writes: > ... until > September I will not be able to participate actively or continuously on > the list. No problem. I just wanted to make sure that this is not forgotten. > Of course, if someone wants to actively collaborate in the development > of this branch, I have no pr

Re: Experimental public branch for inline special blocks

Ihor Radchenko writes: > Juan Manuel Macías writes: > >> Well, next week I will continue commenting. I will try to stay up to >> date with everything that is being discussed here. By the way, if >> someone wants to collaborate on the branch, I can add them as a >> contributor (I'm afraid it is ne

Re: Experimental public branch for inline special blocks

Juan Manuel Macías writes: > Well, next week I will continue commenting. I will try to stay up to > date with everything that is being discussed here. By the way, if > someone wants to collaborate on the branch, I can add them as a > contributor (I'm afraid it is necessary to have a GitLab accoun

Re: Attributes on images (was:: Experimental public branch for inline special blocks)

"Rick Lupton" writes: >> #+attr_html: :height 300 >> [[file:image.png]] has a height of 300, but what if we want a >> different height in @@[:html-height 300]{[[file:another-image.png]]}? >> >> Note how @@{...} markup assigns attributes to objects inside - the >> attribut

Attributes on images (was:: Experimental public branch for inline special blocks)

Thanks for taking the time to comment thoroughly on this which seems generally like it would be a good improvement. On Tue, 9 Apr 2024, at 9:52 AM, Ihor Radchenko wrote: > 2. Allow attaching auxiliary attributes to the on object level, as an >equivalent of affiliated keywords on element level

Re: Experimental public branch for inline special blocks

Ihor Radchenko writes: > Juan Manuel Macías writes: > >> The latest added to the branch are Maxim's proposals (and code) for >> backend control. See this thread: >> >> https://list.orgmode.org/?t=20240321102752 >> >> And this other thread, continuation of the previous one: >> >> https://list.orgm

Re: Experimental public branch for inline special blocks

Juan Manuel Macías writes: > The latest added to the branch are Maxim's proposals (and code) for > backend control. See this thread: > > https://list.orgmode.org/?t=20240321102752 > > And this other thread, continuation of the previous one: > > https://list.orgmode.org/877ciavnwo.fsf...@posteo.ne

Re: Experimental public branch for inline special blocks

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: Next part of this thread: Max Nikulin. inline-special-block: part2. Thu, 11 Apr 2024 1

Re: Experimental public branch for inline special blocks

Ihor Radchenko writes: > Max Nikulin writes: > >> On 09/04/2024 15:52, Ihor Radchenko wrote: >>> Aside: It looks like your public branch is not up-to-date as the time >>>of writing this email - I do not see commits changing the syntax to >>>@foo{...} and @@{...} yet, >> >> Do you have in

Re: Experimental public branch for inline special blocks

Max Nikulin writes: > On 09/04/2024 15:52, Ihor Radchenko wrote: >> Aside: It looks like your public branch is not up-to-date as the time >>of writing this email - I do not see commits changing the syntax to >>@foo{...} and @@{...} yet, > > Do you have in your local copy the following? >

Re: Experimental public branch for inline special blocks

On 09/04/2024 15:52, Ihor Radchenko wrote: Aside: It looks like your public branch is not up-to-date as the time of writing this email - I do not see commits changing the syntax to @foo{...} and @@{...} yet, Do you have in your local copy the following? latest commit ba2fc870c 2024-03-1

Re: Experimental public branch for inline special blocks

Juan Manuel Macías writes: > Finally, I have made public on GitLab my experimental branch for the new > (possible) inline-special-block element: > > I have finally finished my review of the previous related discussions. See my comments and proposals

inline-special-block: export rules (was: `:export' attribute?: Re: Experimental public branch for inline special blocks)

Max Nikulin writes: > I am afraid that :export will cause confusion with :exports for source > code blocks. Its name differs by just "s" but possible values have > nothing common. I agree. At the moment two alternative names come to mind: :backends or :export-rules > Another issue is more gene

Re: `:export' attribute?: Re: Experimental public branch for inline special blocks

Max Nikulin writes: > Would you mind against new thread as an umbrella for next bunch of > topics? Current one becomes too large from my point of view. Ok, I agree. I suggest that from now any new thread related to the new object have as subject: "inline-special-block: specific topic to discuss

Re: `:export' attribute?: Re: Experimental public branch for inline special blocks

On 19/03/2024 02:42, Juan Manuel Macías wrote: As I mentioned in a past email, these days I will be somewhat busy, but I will try to keep up to date with your comments. Although it may take a while to respond. Would you mind against new thread as an umbrella for next bunch of topics? Current o

Re: `:export' attribute?: Re: Experimental public branch for inline special blocks

Max Nikulin writes: > An update with a couple of bugs fixed. Now it is possible to specify > different export rules for a backend and all its derivatives: I have implemented your code in the last commit. I think it is a great improvement, thanks a lot. As I mentioned in a past email, these days

Re: `:export' attribute?: Re: Experimental public branch for inline special blocks

On 15/03/2024 23:26, Juan Manuel Macías wrote: Tomorrow I will make a new commit with your code. An update with a couple of bugs fixed. Now it is possible to specify different export rules for a backend and all its derivatives: (ignore (pp (let ((rules (org-export--inline-special

Re: `:export' attribute?: Re: Experimental public branch for inline special blocks

On 15/03/2024 20:10, Juan Manuel Macías wrote: Max Nikulin writes: 1. "-" is a valid backend name and valid last character of backend name I had not thought of it. Can + also be a valid character? https://orgmode.org/worg/org-syntax.html#Affiliated_Keywords BACKEND A string consisting o

Re: `:export' attribute?: Re: Experimental public branch for inline special blocks

Max Nikulin writes: > (ignore > (pp > (let ((rules > (org-export--inline-special-block-make-backend-alist > (org-split-string "latex/ html./ ascii+ *" > (mapcar (lambda (backend) > (list backend > (org-export--inline-special-block-exp

Re: `:export' attribute?: Re: Experimental public branch for inline special blocks

Thank you for your comments. Max Nikulin writes: > On 15/03/2024 09:19, Juan Manuel Macías wrote: >> The attribute supports one or more elements separated by a space. Each >> element can be any of the following signs: "*" (export only the >> content), "-" (do not export), "=" (export the rest nor

Re: `:export' attribute?: Re: Experimental public branch for inline special blocks

Max Nikulin writes: >> I am not following this branch of the discussion closely, but what about >> not inviting a new DSL here and instead using Elisp sexps here? >> Something like (latex body) (html none) ((not (or latex html)) contents) > > I do not mind in general. Just a couple of questions:

Re: `:export' attribute?: Re: Experimental public branch for inline special blocks

On 15/03/2024 21:00, Ihor Radchenko wrote: Max Nikulin writes: 1. "-" is a valid backend name and valid last character of backend name I am not following this branch of the discussion closely, but what about not inviting a new DSL here and instead using Elisp sexps here? Something like (latex

Re: `:export' attribute?: Re: Experimental public branch for inline special blocks

Max Nikulin writes: > 1. "-" is a valid backend name and valid last character of backend name I am not following this branch of the discussion closely, but what about not inviting a new DSL here and instead using Elisp sexps here? Something like (latex body) (html none) ((not (or latex html)) co

Re: `:export' attribute?: Re: Experimental public branch for inline special blocks

On 15/03/2024 09:19, Juan Manuel Macías wrote: The attribute supports one or more elements separated by a space. Each element can be any of the following signs: "*" (export only the content), "-" (do not export), "=" (export the rest normally), "=*" (export the rest, but only the content), "=-" (

Re: `:export' attribute?: Re: Experimental public branch for inline special blocks

To summarize the latest improvements and modifications to the `:export' attribute... The attribute supports one or more elements separated by a space. Each element can be any of the following signs: "*" (export only the content), "-" (do not export), "=" (export the rest normally), "=*" (export th

Re: `:export' attribute?: Re: Experimental public branch for inline special blocks

Juan Manuel Macías writes: > It was necessary with the previous implementation, which excessively > abused regexp. Not now (I want to do a few more tests and I'll make a > new commit with the changes). With the new implementation, now: > > - do not export > > * export only the content > > = rest

Re: `:export' attribute?: Re: Experimental public branch for inline special blocks

Max Nikulin writes: >> how about the following: >> - "--" :: do not export >> - "**" :: export only the content >> - "==" :: rest (full) >> - "=*" :: rest (only the content) >> - "!backend-name+ :: export this backend (full) >> - "!backend-name*" :: export this backend (only the content) >> - "!ba

Re: `:export' attribute?: Re: Experimental public branch for inline special blocks

On 13/03/2024 00:41, Juan Manuel Macías wrote: Max Nikulin writes: It is not clear for me how to achieve the following. Add a link [[https://youtube.com/...][Org mode in action demo (video)]] for all backends (EPUB, LaTeX, ODT, text, etc.) besides HTML because there is an #+export_html block

Re: `:export' attribute?: Re: Experimental public branch for inline special blocks

Max Nikulin writes: > It is not clear for me how to achieve the following. Add a link > > [[https://youtube.com/...][Org mode in action demo (video)]] > > for all backends (EPUB, LaTeX, ODT, text, etc.) besides HTML because > there is an #+export_html block with player embedded using an iframe. S

Re: `:export' attribute?: Re: Experimental public branch for inline special blocks

On 12/03/2024 20:45, Juan Manuel Macías wrote: backend-name = full export backend-name* = only contents And the "rest" option is introduced, with the same syntax as before. Examples: It is not clear for me how to achieve the following. Add a link [[https://youtube.com/...][Org mode in action

Re: `:export' attribute?: Re: Experimental public branch for inline special blocks

In the last commit I have introduced some changes. Now this new feature is no longer hardcoded in each backend but is controlled by an external function in ox.el. I think this can simplify the implementation for other backends. As Stefan Nobis proposed, the "+" sign is now not necessary: backend-

Re: `:export' attribute?: Re: Experimental public branch for inline special blocks

Juan Manuel Macías writes: >>> :export "latex+ html+ rest*" >> "rest" might be a valid backend name. > I will try to implement the "rest" option. What about "others" or even ":others" as a placeholder for any not explicitly mentioned export backend? Another quick thought crossing my mind: May

Re: `:export' attribute?: Re: Experimental public branch for inline special blocks

Max Nikulin writes: > Your example uses a closed list of backends while "not (html or > latex)" may be applicable to ascii, rst, some wiki dialects, etc. Makes sense. > Backend-specific markup may be more complex and content of fallback > option may be different from text used in export snippets

Re: `:export' attribute?: Re: Experimental public branch for inline special blocks

On 11/03/2024 20:59, Juan Manuel Macías wrote: I have a bit different expectations in respect to export predicates. It should be possible to express that some content should be exported by all backend except the given list. The use case is fallback for backends not covered by export snippets:

Re: `:export' attribute?: Re: Experimental public branch for inline special blocks

Max Nikulin writes: > On 10/03/2024 09:08, Juan Manuel Macías wrote: >> I'm thinking about adding a new global attribute, `:export', that >> would granularly control whether or not to export the object and how to >> export it. > > I have a bit different expectations in respect to export predicates

Re: `:export' attribute?: Re: Experimental public branch for inline special blocks

On 10/03/2024 09:08, Juan Manuel Macías wrote: I'm thinking about adding a new global attribute, `:export', that would granularly control whether or not to export the object and how to export it. I have a bit different expectations in respect to export predicates. It should be possible to expr

Re: `:export' attribute?: Re: Experimental public branch for inline special blocks

Juan Manuel Macías writes: > I'm thinking about adding a new global attribute, `:export', that > would granularly control whether or not to export the object and how to > export it. > > Possible values: "noexport", "contents" (it would export only the content) > or the backends to which you want t

Re: false positives: Re: Experimental public branch for inline special blocks

On 09/03/2024 22:24, Juan Manuel Macías wrote: Well, I hope that in the last commit the two bugs that you mentioned have been fixed. Please check: Albha@Beta[ @sp@n{lorem ipsum} {lorem ipsum} Thanks, Juan Manuel. I do not see issues any more. I would still consider unit tests to not bre

`:export' attribute?: Re: Experimental public branch for inline special blocks

I'm thinking about adding a new global attribute, `:export', that would granularly control whether or not to export the object and how to export it. Possible values: "noexport", "contents" (it would export only the content) or the backends to which you want to export, separated by spaces. Each bac

Re: false positives: Re: Experimental public branch for inline special blocks

Juan Manuel Macías writes: > Max Nikulin writes: > >> However it is still gives >> >> (org-export-string-as "Alpha@Beta[" >> 'html >> '(:export-options (body-only))) >> Debugger entered--Lisp error: (wrong-type-argument >> number-or-marker-p nil) > > I think the p

Re: false positives: Re: Experimental public branch for inline special blocks

Max Nikulin writes: > However it is still gives > > (org-export-string-as "Alpha@Beta[" > 'html > '(:export-options (body-only))) > Debugger entered--Lisp error: (wrong-type-argument > number-or-marker-p nil) I think the problem is the contents-begin variable. Wh

Re: false positives: Re: Experimental public branch for inline special blocks

On 09/03/2024 01:57, Juan Manuel Macías wrote: Ok, I think you and Maxim are right. This is a clear bug. I hope it was fixed in the last commit. (org-export-string-as "Alpha@Beta{" 'latex t)) ==> Alpha@Beta\{ (org-export-string-as "Alpha@Beta{gamma}" 'latex t)) ==> Alpha\Beta{gamma}

Re: false positives: Re: Experimental public branch for inline special blocks

Juan Manuel Macías escribió: > Ok, I think you and Maxim are right. This is a clear bug. I hope it > was fixed in the last commit. Now: (org-export-string-as "Alpha@Beta{" 'latex t)) ==> Alpha@Beta\{ (org-export-string-as "Alpha@Beta{gamma}" 'latex t)) ==> Alpha\Beta{gamma} -- Juan Manu

Re: false positives: Re: Experimental public branch for inline special blocks

Ihor Radchenko writes: > Juan Manuel Macías writes: > >>> Debugger entered--Lisp error: (wrong-type-argument >>> number-or-marker-p nil) >> >> Maybe in that case you could add a zero width space character. >> >> In any case, if someone has reasons to write "Alpha@Beta{" they may also >> have

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

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. Ma

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

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 facili

Re: false positives: Re: Experimental public branch for inline special blocks

Juan Manuel Macías writes: >> Debugger entered--Lisp error: (wrong-type-argument >> number-or-marker-p nil) > > Maybe in that case you could add a zero width space character. > > In any case, if someone has reasons to write "Alpha@Beta{" they may also > have reasons to write "Alpha_Beta": 1.

Re: false positives: Re: Experimental public branch for inline special blocks

On 08/03/2024 22:44, Juan Manuel Macías wrote: Max Nikulin writes: (org-export-string-as "Alpha@Beta{" 'html '(:export-options (body-only))) "\nAlpha{\n" (org-export-string-as "Alpha@Beta[" 'html '(:export-options (body-only)

Re: false positives: Re: Experimental public branch for inline special blocks

Max Nikulin writes: > (org-export-string-as "Alpha@Beta{" > 'html > '(:export-options (body-only))) > "\nAlpha{\n" > > (org-export-string-as "Alpha@Beta[" > 'html > '(:export-options (body-only))) > Debugger entered--Lisp error: (wron

Re: false positives: Re: Experimental public branch for inline special blocks

On 08/03/2024 01:21, Juan Manuel Macías wrote: Ihor Radchenko escribió: I am wondering if @@[...]{...} would be better than @_... It should be slightly easier to type. Anyway, in the last commit I replaced _ with @. Let's see how it goes... Now the anonymous variant is @@[...]{...}. Unfortu

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

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

Re: false positives: Re: Experimental public branch for inline special blocks

Juan Manuel Macías writes: > Ihor Radchenko escribió: > >> I am wondering if @@[...]{...} would be better than @_... >> It should be slightly easier to type. > > Another possibility would be @:[...]{...}, which is somewhat shorter. > > (I don't have any special preference, although @@ visually re

Re: false positives: Re: Experimental public branch for inline special blocks

Ihor Radchenko escribió: > I am wondering if @@[...]{...} would be better than @_... > It should be slightly easier to type. Another possibility would be @:[...]{...}, which is somewhat shorter. (I don't have any special preference, although @@ visually reminds me a bit of the export snippet).

Re: false positives: Re: Experimental public branch for inline special blocks

Juan Manuel Macías writes: > I have modified the syntax in the last commit. Now: > > @type[...]{...} (or @_[...]{...}) I am wondering if @@[...]{...} would be better than @_... It should be slightly easier to type. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode

Re: false positives: Re: Experimental public branch for inline special blocks

Ihor Radchenko writes: > I suggest @type[...]{...}. Akin Texinfo constructs. > > (Texinfo because of > previous RMS' request to implement better support for markup used in > software manuals - keeping things close to Texinfo syntax will make life > easier if we ever reach the point when Org mode i

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

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

Re: false positives: Re: Experimental public branch for inline special blocks

Ihor Radchenko writes: > Juan Manuel Macías writes: > >>> (org-export-string-as "Alpha&Beta{" >> ... >> mmm, right. And there may also be a problem with the subscripts: >> &_{subscript}... >> >> Perhaps we should think about a structure less prone to ambiguities. For >> example: >> >> &:type[a

Re: false positives: Re: Experimental public branch for inline special blocks

Juan Manuel Macías writes: >> (org-export-string-as "Alpha&Beta{" > ... > mmm, right. And there may also be a problem with the subscripts: > &_{subscript}... > > Perhaps we should think about a structure less prone to ambiguities. For > example: > > &:type[attrs]{text} / &:_[attrs]{text} I su

Re: false positives: Re: Experimental public branch for inline special blocks

Max Nikulin writes: > It seems the parser finds new objects where syntactical constructs are > incomplete: > > (org-export-string-as "Alpha&Beta{" > 'html > '(:export-options (body-only))) > "\nAlpha{\n" mmm, right. And there may also be a problem with

false positives: Re: Experimental public branch for inline special blocks

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: It seems the parser finds new objects where syntactical constructs are incomplete:

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

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-purpo

Re: To avoid zero width space: Re: Experimental public branch for inline special blocks

Max Nikulin writes: > However to produce clean export result elements should not be > added if no attributes are specified. My expectation is > > " > Example of intraword markup > " With the latest commit now the anonymous variant without attributes simply returns the content (in LaTeX, HTML and

Re: To avoid zero width space: Re: Experimental public branch for inline special blocks

Max Nikulin writes: > However to produce clean export result elements should not be > added if no attributes are specified. My expectation is > > " > Example of intraword markup > " It seems like a good idea to me. Currently, in LaTeX: &_{lorem ipsum dolor} ==> LaTeX ==> lorem ipsum dolor It c

To avoid zero width space: Re: Experimental public branch for inline special blocks

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: The new feature is promising as an alternative for U+200B zero width space as an esca

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

Max Nikulin writes: > OK, just consider it as my dissenting opinion. I believe that it should > be possible for the same Org document > >#+options: inline-special-block-aliases:(("definition" :smallcaps t)) > >&definition{Example} or &_[:smallcaps t]{ad-hoc} > > to export it as > >Exam

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

On 06/03/2024 00:28, Juan Manuel Macías wrote: Max Nikulin escribió: I think that the current implementation is very flexible and gives rise to many possible variations, and the combination of direct formatting and styles to suit the user. OK, just consider it as my dissenting opinion. I believ

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

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 a

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

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 somethin

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

Max Nikulin escribió: > If some type is used through the document multiple times then it is > better to avoid style="font-variant:small-caps" and use a CSS class > instead. Even for LaTeX it may be better to define a dedicated command > to be closer to semantic markup. > > Moreover different d

smallcaps: Re: Experimental public branch for inline special blocks

On 02/03/2024 03:34, Juan Manuel Macías wrote: │ Caesar's famous quote: &latin![:smallcaps t :color blue]{Alea iacta est} ==> LaTeX: │ Caesar's famous quote: {\scshape{}\color{blue}\foreignlanguage{latin}{\textit{Alea iacta est}}} == HTML: │ Caesar's famous quote: Alea iacta est I am in doubts

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

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 >

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

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

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

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 fra

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

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

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

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 ma

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

[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 justic

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

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

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

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-o

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

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 "inl

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

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

naming: Re: Experimental public branch for inline special blocks

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 la

Re: Experimental public branch for inline special blocks

Hi, Stefan, Stefan Nobis writes: > first of all: Thank you for your great work. Looks really good. You're welcome! :-) > Just out of curiosity: Why a special syntax for alias expansion? > > From a syntax and user point of view, I think I would prefer a simpler > syntax. So > > &alias{text}

Re: Experimental public branch for inline special blocks

Hi Juan, first of all: Thank you for your great work. Looks really good. Just out of curiosity: Why a special syntax for alias expansion? >From a syntax and user point of view, I think I would prefer a simpler syntax. So &alias{text} would check if an alias is registered and if yes use it.

Experimental public branch for inline special blocks

Hi, Finally, I have made public on GitLab my experimental branch for the new (possible) inline-special-block element: The code incorporates fixes and modifications and I have also added some ideas from Maxim Nikulin. The LaTeX and HTML backends are c