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

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

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.

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

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

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

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:

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 @@[...]{...}.

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

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

Ihor Radchenko writes: > Juan Manuel Macías writes: > >>> (org-export-string-as "Alpha{" >> ... >> 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: >> >>

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

Juan Manuel Macías writes: >> (org-export-string-as "Alpha{" > ... > 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

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{" > 'html > '(:export-options (body-only))) > "\nAlpha{\n" mmm, right. And there may also be a problem with the

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: