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

[Juan Manuel Macías]

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 general and should apply e.g. to HTML attributes 
> as well. Consider
>
> --- 8< ---
>
> #+options: inline-special-block-aliases:(("kbd" :export "html*" 
> :html-tag kbd))
>
> @kbd{Default} and @kbd[:export "latex*"]{LaTeX}
> --- >8 ---
>
> It exports to
>
>  \nDefault and LaTeX
>
> I would expect that "html*" is inherited from the parent declaration and 
> "latex*" does not override it, so
>
>  \nDefault and LaTeX

But it is the expected result in all attributes. If an attribute of the
same type as the one declared in the alias is added, the value is
overwritten.

In any case, since in this case the attribute allows cumulative values,
I think the approach should be at the level of the attribute name itself
and not the code to manage the export rules. For example:

:export [or whatever new name we give it] ==> normal behavior, overwrites the 
values

:export+ ==> adds the new values to the values defined in the alias

This syntax could also be extended to other cases. Perhaps we want
attributes like :prelatex, :postlatex, or :html to support accumulating
values. It could be easily solved from the functions of each backend. In
other cases, of course, it wouldn't make sense (a block can't have two
languages at the same time), but in that scenario, if someone puts
:lang+, it simply wouldn't be taken into account. Wdyt?

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

[Juan Manuel Macías]

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

Tomorrow I will try to answer all the latest questions related to the
export rules.

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

[Max Nikulin]

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 one becomes too large from my point of view.


For a while a couple of questions related to :export to think on.

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.


Another issue is more general and should apply e.g. to HTML attributes 
as well. Consider


--- 8< ---
#+options: inline-special-block-aliases:(("kbd" :export "html*" 
:html-tag kbd))

@kbd{Default} and @kbd[:export "latex*"]{LaTeX}
--- >8 ---

It exports to

\nDefault and LaTeX

I would expect that "html*" is inherited from the parent declaration and 
"latex*" does not override it, so


\nDefault and LaTeX

On the other hand it should be possible to specify that declared earlier 
rules should be taken into consideration. E.g. "#" might stop further 
processing:


--- 8< ---
#+options: inline-special-block-aliases:(("kbd" :export "html*" 
:html-tag kbd))

@kbd{Default} and @kbd[:export "latex* #"]{LaTeX}
--- >8 ---

makes

\nDefault and LaTeX

result valid.

In the meanwhile I have realized that there is no point in the list of 
parsed rules. You may consider code organized in a bit different way. I 
hope, just a single extra line in these helpers is required to support "#".


(defun org-export--parse-export-rule
(spec)
  (and (string-match

"\\`\\([-_a-zA-Z0-9]*\\)\\(?:\\([/+*]\\)\\([=.]\\)?\\|\\([=.]\\)\\([/+*]\\)?\\)?\\'"
spec)
   (let ((name (match-string 1 spec))
 (inherit (or (match-string 3 spec)
  (match-string 4 spec)))
 (what (or (match-string 2 spec)
   (match-string 5 spec
 (cons
  (if (string-equal "" name) '@ (intern name))
  (cons (or (not inherit) (string-equal inherit "="))
(pcase (and what (string-to-char what))
  ((or ?+ (pred null)) 'full)
  (?* 'content)
  (?/ nil)))
;; (org-export--parse-export-rule "html+=")

(defun org-export--backend-hierarchy (backend)
  "Result may be cached in INFO."
  (let ((hierarchy))
(when (not (symbolp backend))
  (setq backend (org-export-backend-name backend)))
(while backend
  (push backend hierarchy)
  (setq backend (org-export-backend-parent
 (org-export-get-backend backend
hierarchy))
;; (org-export--backend-hierarchy 'md)

(defun org-export--inline-special-block-export-decision
(spec-list hierarchy  default-rule)
  "Returns (backend inherit . what).
so use `cddr' to get decision."
  (let ((decision '(@ t . full))
(hierarchy (cons '@ hierarchy)))
(while (and hierarchy spec-list)
  (let* ((rule (org-export--parse-export-rule (pop spec-list)))
 (tail (and rule (memq (car rule) hierarchy
(if (not rule)
(message "invalid :export specification %S" (car spec-list)))
(when (and tail
   (or (not (cdr tail)) ; Current backend.
   (cadr rule))) ; Inherits.
  (setq hierarchy (cdr tail))
  (setq decision rule
(if (and default-rule (memq (car default-rule) hierarchy))
default-rule
  decision)))



(ignore
 (pp
  (let ((rules (org-split-string "latex/ html./ html+= ascii+ *")))
(mapcar (lambda (backend)
  (let ((hierarchy
 (org-export--backend-hierarchy backend)))
(list backend
  (cddr
   (org-export--inline-special-block-export-decision
rules hierarchy)
'(odt latex beamer html md ascii)

((odt content)
 (latex nil)
 (beamer nil)
 (html nil)
 (md full)
 (ascii full))

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

[Juan Manuel Macías]

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

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

[Max Nikulin]

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-block-make-backend-list
  (org-split-string "latex/ html./ html+= ascii+ *"
(mapcar (lambda (backend)
  (let ((hierarchy
 (org-export--backend-hierarchy backend)))
(list backend
  (org-export--inline-special-block-export-decision
   rules hierarchy
'(odt latex beamer html md ascii)

((odt content)
 (latex nil)
 (beamer nil)
 (html nil)
 (md full)
 (ascii full))



(defun org-export--inline-special-block-make-backend-list
(rules)
  (let (result)
(dolist (spec rules)
  (if (string-match

"\\`\\([-_a-zA-Z0-9]*\\)\\(?:\\([/+*]\\)\\([=.]\\)?\\|\\([=.]\\)\\([/+*]\\)?\\)?\\'"
   spec)
  (let ((name (match-string 1 spec))
(inherit (or (match-string 3 spec)
 (match-string 4 spec)))
(what (or (match-string 2 spec)
  (match-string 5 spec
(push (cons
   (if (string-equal "" name) '@ (intern name))
   (cons (or (not inherit) (string-equal inherit "="))
 (if what (string-to-char what) ?+)))
  result))
(message "invalid :export specification %S" spec)))
(nreverse result)))

(defun org-export--backend-hierarchy (backend)
  "Result may be cached in INFO."
  (let ((hierarchy))
(when (not (symbolp backend))
  (setq backend (org-export-backend-name backend)))
(while backend
  (push backend hierarchy)
  (setq backend (org-export-backend-parent
 (org-export-get-backend backend
hierarchy))

(defun org-export--inline-special-block-export-decision
(rule-list hierarchy)
  (let ((hierarchy (cons '@ hierarchy))
(decision ?+))
(while (and hierarchy rule-list)
  (let* ((rule (pop rule-list))
 (tail (memq (car rule) hierarchy)))
(when (and tail
   (or (not (cdr tail)) ; Current backend.
   (cadr rule))) ; Inherits.
  (setq hierarchy (cdr tail))
  (setq decision (cddr rule)
(pcase decision
  (?+ 'full)
  (?* 'content)
  (?/ nil)
  (_ 'full

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

[Max Nikulin]

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 of alphanumeric characters, hyphens, or 
underscores (-_).



2. From the description it is not clear to me what is effect of "rest"
specified for more than one backend.


'rest' (=) is equivalent to the rest of the backends that have not been
explicitly set. What happens is that, with my current approach, if you
want to export only one backend, you must enter:

:export backend =- (that is, export this backend and not the rest)


At first I thought it may be used as [:export backend=-] and it is the 
reason why I was confused. However I still do not see difference between 
[:export backend -] and [:export backend =-].



This is not ideal. It should be enough to just put:

:export backend

but I am not able to achieve it.


I agree, it is intuitive, but it makes formal rules more complicated.


   = full, this and derived backends (default)


I would prefer to modify code to handle
[:export latex.+ latex=/]
to apply first declaration (content only) to latex and second one (skip) 
to derived backends. Anyway the code requires optimization. Walk through 
parent backends is likely inefficient.



These days I'm going to be a little short on time, due to work, and I
don't know if I'll be able to attend to the list.


Then I will postpone other questions (mostly unrelated to :export).

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

[Juan Manuel Macías]

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-export-decision
> rules backend)))
> '(odt latex beamer html md ascii)
>
> Gives
>
> ((odt content)
>  (latex nil)
>  (beamer nil)
>  (html nil)
>  (md content)
>  (ascii full))
>
> Function definitions:
>
> (defun org-export--inline-special-block-make-backend-alist
> (rules)
>   (nconc
>(let (result)
>  (dolist (spec rules)
>(if (string-match
>
> "\\`\\([-_a-zA-Z0-9]*\\)\\(?:\\([/+*]\\)\\|\\([=.]\\)\\([/+*]\\)?\\)?\\'"
> spec)
>(let ((name (match-string 1 spec))
>  (inherit (match-string 3 spec))
>  (what (or (match-string 2 spec)
>(match-string 4 spec
>(push (cons
> (if (string-equal "" name) '@ (intern name))
> (cons (or (not inherit) (string-equal inherit "="))
>   (if what (string-to-char what) ?+)))
>  result))
>(message "invalid :export specification %S" spec)))
>  result)))
>
> (defun org-export--inline-special-block-export-decision
> (rules-alist backend)
>   (when (symbolp backend)
> (setq backend (org-export-get-backend backend)))
>   (let* ((rule (assoc (org-export-backend-name backend) rules-alist))
>(decision (and rule (cddr rule
> (while (and (not decision)
>   (setq backend (org-export-backend-parent backend)))
>   (setq backend (org-export-get-backend backend))
>   (when (and (setq rule (assq (org-export-backend-name backend)
>   rules-alist))
>  rule
>  (cadr rule))
> (setq decision (cddr rule
> (unless decision
>   (setq rule  (assq '@ rules-alist))
>   (setq decision (and rule (cddr rule
> (pcase decision
>   (?+ 'full)
>   (?* 'content)
>   (?/ nil)
>   (_ 'full

I've been testing your code and it works very well. It is certainly
finer than the current approach. I think it could be implemented, and we
are testing that.

Tomorrow I will make a new commit with your code.

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

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

[Juan Manuel Macías]

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 normally), "=*"
>> (export the rest, but only the content), "=-" (do not export the rest).
>> Additionally, backend names can be given explicitly, alone or
>> accompanied by the "*" or "-" signs, that is (where "backend" equals the
>> name of the backend):
>
> 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? 

> 2. From the description it is not clear to me what is effect of "rest"
> specified for more than one backend.

'rest' (=) is equivalent to the rest of the backends that have not been
explicitly set. What happens is that, with my current approach, if you
want to export only one backend, you must enter:

:export backend =- (that is, export this backend and not the rest)

This is not ideal. It should be enough to just put:

:export backend

but I am not able to achieve it.

> I have had into the code. I would expect something like the following
> (characters may be changed, the code is not heavily tested). Two
> characters from the following groups may be appended to backend name:
>
> + full (default)
> * content
> / skip
> (these ones may be used without backed name to specify fallback action)
>
> = this and derived backends (default)
> . this, but not derived backends
> Perhaps it is necessary to add possibility that
> these rules may coexist (use loop instead of assoc)

OK. How about the following?

- Single characters (they affect everything, if backend name is not
  specified, or the rest, if backend name is specified:
  
  * content
  / skip
  . never export derived backends
  = full, this and derived backends (default)

- And in combination with backend names (some examples):

  :export latex* > content to LaTeX, normal to the rest
  
  :export latex/ > do not export to LaTeX

  :export latex. > do not export to LaTeX derived backends

  :export latex . > export normally to LaTeX but do not export the derived 
backends in the rest of the cases

  etc.

These days I'm going to be a little short on time, due to work, and I
don't know if I'll be able to attend to the list. I want to calmly take
a look at the code you share.

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

[Ihor Radchenko]

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:
> - How to specify whether the rule should be applied to derived backends?
> - Is there a ready to use function that can interpret such expressions?

Good question. I guess that what I propose is still a new DSL at the
end... Oh well.

I guess that the closest existing DSL would be what `buffer-match-p'
function uses.

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

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

[Max Nikulin]

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 body) (html none) ((not (or latex html)) contents)


I do not mind in general. Just a couple of questions:
- How to specify whether the rule should be applied to derived backends?
- Is there a ready to use function that can interpret such expressions?

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

[Ihor Radchenko]

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)) contents)

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

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

[Max Nikulin]

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), "=-" (do not export the rest).
Additionally, backend names can be given explicitly, alone or
accompanied by the "*" or "-" signs, that is (where "backend" equals the
name of the backend):


1. "-" is a valid backend name and valid last character of backend name
2. From the description it is not clear to me what is effect of "rest" 
specified for more than one backend.


I have had into the code. I would expect something like the following 
(characters may be changed, the code is not heavily tested). Two 
characters from the following groups may be appended to backend name:


+ full (default)
* content
/ skip
(these ones may be used without backed name to specify fallback action)

= this and derived backends (default)
. this, but not derived backends
Perhaps it is necessary to add possibility that
these rules may coexist (use loop instead of assoc)

(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-export-decision 
rules backend)))

'(odt latex beamer html md ascii)

Gives

((odt content)
 (latex nil)
 (beamer nil)
 (html nil)
 (md content)
 (ascii full))

Function definitions:

(defun org-export--inline-special-block-make-backend-alist
(rules)
  (nconc
   (let (result)
 (dolist (spec rules)
   (if (string-match

"\\`\\([-_a-zA-Z0-9]*\\)\\(?:\\([/+*]\\)\\|\\([=.]\\)\\([/+*]\\)?\\)?\\'"
spec)
   (let ((name (match-string 1 spec))
 (inherit (match-string 3 spec))
 (what (or (match-string 2 spec)
   (match-string 4 spec
 (push (cons
(if (string-equal "" name) '@ (intern name))
(cons (or (not inherit) (string-equal inherit "="))
  (if what (string-to-char what) ?+)))
   result))
 (message "invalid :export specification %S" spec)))
 result)))

(defun org-export--inline-special-block-export-decision
(rules-alist backend)
  (when (symbolp backend)
(setq backend (org-export-get-backend backend)))
  (let* ((rule (assoc (org-export-backend-name backend) rules-alist))
 (decision (and rule (cddr rule
(while (and (not decision)
(setq backend (org-export-backend-parent backend)))
  (setq backend (org-export-get-backend backend))
  (when (and (setq rule (assq (org-export-backend-name backend) 
rules-alist))

 rule
 (cadr rule))
(setq decision (cddr rule
(unless decision
  (setq rule  (assq '@ rules-alist))
  (setq decision (and rule (cddr rule
(pcase decision
  (?+ 'full)
  (?* 'content)
  (?/ nil)
  (_ 'full

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

[Juan Manuel Macías]

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 the rest, but only the content), "=-" (do not export the rest).
Additionally, backend names can be given explicitly, alone or
accompanied by the "*" or "-" signs, that is (where "backend" equals the
name of the backend):

  backend: export normally for that backend and its derived backends;

  backend-: do not export for that backend or its derived backends.

  backend*: export only the content for that backend and its derived
  backends.

Some examples with valid combinations:

@foo[:export *]{lorem ipsum}

==> export only the content

@foo[:export -]{lorem ipsum}

==> do not export

@foo[:export latex-]{lorem ipsum}

==> do not export to LaTeX

@foo[:export latex- html* =]{lorem ipsum}

==> do not export to LaTeX, export only the content to html and export the
rest normally.

@foo[:export latex =*]{lorem ipsum}

==> export normally to LaTeX but export only the content to the rest

@foo[:export latex =-]{lorem ipsum}

==> export normally to LaTeX and not export to the rest

And below is a complete example based on a possible use case that Max
had exposed:


 To see a demo of the Fairlight CMI, watch @@[:export html =-]{this
 video} @@[:export
 html-]{[[https://www.youtube.com/watch?v=am0GBuS_7cE][this video]]}
 with Peter Vogel.
 
 #+begin_export html
 https://www.youtube.com/embed/am0GBuS_7cE?si=X7pghJhtdfOT1hby;
 title="YouTube video player"
 frameborder="0"
 allow="accelerometer;
 autoplay; clipboard-write; encrypted-media; gyroscope;
 picture-in-picture; web-share"
 allowfullscreen>
 #+end_export

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

[Juan Manuel Macías]

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 (full)
>
> =* rest (contents only)
>
> backend- do not export this backend (and the backends derived from it)
>
> backend+ (or, perhaps, just "backend") export this backend (idem)
>
> backend* export this backend (contents only) (idem)
>
> I think your example with the video link would also be possible with the
> new implementation.

Please try the latest commit:

@@[:export html-]{Watch [[https://youtube.com/...][Org mode in action demo]] 
video.}

#+begin_export html
https://youtube.com/embed/...;
  title="Org mode in action demo"
  width="..." height="...">
#+end_export

It would not be exported to html or its derived backends.

(In your example you used `-html' instead of `html-'. I have no
preference for one variant or another).

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

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

[Juan Manuel Macías]

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)
>> - "!backend-name- :: do not export this backend
>
> I do not see why operator should be duplicated for backends that are not 
> specified explicitly. Single "+" (default) or "-" should be enough. I 
> have not got your idea with leading "!". From my point of view it is 
> redundant.

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 (full)

=* rest (contents only)

backend- do not export this backend (and the backends derived from it)

backend+ (or, perhaps, just "backend") export this backend (idem)

backend* export this backend (contents only) (idem)

I think your example with the video link would also be possible with the
new implementation.

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

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

[Max Nikulin]

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 with player embedded using an iframe.


Sorry, I don't quite understand this. Could you please elaborate?


--- 8< ---
&_[:exports -html]{Watch [[https://youtube.com/...][Org mode in action 
demo]] video.}


#+begin_export html
https://youtube.com/embed/...;
 title="Org mode in action demo"
 width="..." height="...">
#+end_export
--- >8 ---

should be exported to HTML without the sentence with the link
--- 8< ---
https://youtube.com/embed/...;
 title="Org mode in action demo"
 width="..." height="...">
--- >8 ---

however only the sentence with the link is exported to LaTeX or any 
other format

--- 8< ---
Watch \href{https://youtube.com/...}{Org mode in action demo} video.
--- >8 ---


Instead of "noexport" and "rest" that may be confused with backend
names I would consider "+" and "*" without any name. I would consider
some characters like "-", "_", "!", "~" to express "do not export to
this and derived backends" and "do not export for specified backend
only".


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)
- "!backend-name- :: do not export this backend


I do not see why operator should be duplicated for backends that are not 
specified explicitly. Single "+" (default) or "-" should be enough. I 
have not got your idea with leading "!". From my point of view it is 
redundant.

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

[Juan Manuel Macías]

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.

Sorry, I don't quite understand this. Could you please elaborate?

> Instead of "noexport" and "rest" that may be confused with backend
> names I would consider "+" and "*" without any name. I would consider
> some characters like "-", "_", "!", "~" to express "do not export to
> this and derived backends" and "do not export for specified backend
> only".

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)

- "!backend-name- :: do not export this backend

?

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

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

[Max Nikulin]

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


Instead of "noexport" and "rest" that may be confused with backend names 
I would consider "+" and "*" without any name. I would consider some 
characters like "-", "_", "!", "~" to express "do not export to this and 
derived backends" and "do not export for specified backend only".

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

[Juan Manuel Macías]

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-name = full export

backend-name* = only contents

And the "rest" option is introduced, with the same syntax as before.

Examples:

@foo[:export noexport]{lorem ipsum dolor}

==> does not export anything

@foo[:export contents]{lorem ipsum dolor}

==> only contents

@foo[:export latex]{lorem ipsum dolor}

==> exports only to LaTeX

@foo[:export latex odt* html*]{lorem ipsum dolor}

==> exports everything to LaTeX, but to odt and HTML only the content

@foo[:export latex* rest]{lorem ipsum dolor}

==> content to LaTeX but full export to the rest of the backends

@foo[:export latex rest*]{lorem ipsum dolor}

==> the opposite of the above.

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

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

[Stefan Nobis]

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 make "+" the default (so
"latex" means "latex+" and only use a marker char like '*' for
"content only")?

-- 
Until the next mail...,
Stefan.

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

[Juan Manuel Macías]

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. Perhaps I
> shouldn't give so simple example.

I think I have understood the essentials, but perhaps it would be good
to see a slightly more complex scenario.

> Side note: I expect that the new object will be more convenient than
> export snippets in most cases.

I think so. In any case, although this object is proving pleasantly
versatile for us, I think we should not lose sight of the fact that its
main purpose is to be an inline text container with export properties.
Exports snippets are more for literal code inclusion. There can be
border uses between both objects, as there can also be with macros and
links. I suppose the ideal is to always choose the feature that best
suits a given context. One can put, for example @esindex[:export
latex+]{some word}, but in this case it would be more comfortable to put
@@latex:\esindex{some word}@@ or even use a macro.

>> :export "latex+ html+ rest*"
>
> "rest" might be a valid backend name.

I will try to implement the "rest" option.

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

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

[Max Nikulin]

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:

 @@latex:\textbf{\LaTeX() formatting}html:HTML
 formatting@@@[...]{*for other backends}


I think that in your example (if I understand the intentions correctly)
it would not even be necessary to use export snippets:

#+options: inline-special-block-aliases:(("strong" :latex-command textbf
:html-tag strong :export "latex+ html+ odt*" ))


Your example uses a closed list of backends while "not (html or latex)" 
may be applicable to ascii, rst, some wiki dialects, etc. 
Backend-specific markup may be more complex and content of fallback 
option may be different from text used in export snippets. Perhaps I 
shouldn't give so simple example.


Side note: I expect that the new object will be more convenient than 
export snippets in most cases.



:export "latex+ html+ rest*"


"rest" might be a valid backend name.

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

[Juan Manuel Macías]

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.
> 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:
>
> @@latex:\textbf{\LaTeX() formatting}html:HTML
> formatting@@@[...]{*for other backends}

I think that in your example (if I understand the intentions correctly)
it would not even be necessary to use export snippets:

#+options: inline-special-block-aliases:(("strong" :latex-command textbf
:html-tag strong :export "latex+ html+ odt*" ))

@strong{formatting}

or even:

@strong{@@latex:\latex{}: html:HTML: @@ formatting}

As defined, it is exported to LaTeX and HTML with all the formatting,
but only the content is exported to odt. The rest are not exported.
Maybe an "rest" option could be added, to avoid verbosity:

:export "latex+ html+ rest*"

(the complete format is exported to LaTeX and html and only the content to the 
rest).

However, I think that exporting this object to 'format-agnostic' backends,
such as plain text, would have to be implemented in a way that always
exports the content.

> Earlier I raised this issue during discussion of @@:...@@ syntax extension:
> Max Nikulin. Re: Org-syntax: Intra-word markup. Fri, 28 Jan 2022
> 21:52:17 +0700.
> https://list.orgmode.org/868df76e-69e0-1d14-ae8a-13b746982...@gmail.com
>
> Another case for backend predicates is whether it should be applicable
> to derived backends or just to explicitly specified ones.

I don't have a definite opinion. Maybe it would be nice to also take
into account derived backends...

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

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

[Max Nikulin]

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


@@latex:\textbf{\LaTeX() formatting}html:HTML 
formatting@@@[...]{*for other backends}


Earlier I raised this issue during discussion of @@:...@@ syntax extension:
Max Nikulin. Re: Org-syntax: Intra-word markup. Fri, 28 Jan 2022 
21:52:17 +0700. 
https://list.orgmode.org/868df76e-69e0-1d14-ae8a-13b746982...@gmail.com


Another case for backend predicates is whether it should be applicable 
to derived backends or just to explicitly specified ones.

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

[Juan Manuel Macías]

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 to export, separated by spaces. Each
> backend should be followed by a "+" sign (= export all) or "*" (export
> content only). For example:
>
> @foo[:color red :export latex+ odt* html*]{lorem ipsum dolor}
>
> This means that "lorem ipsum dolor" would be exported with color format
> to LaTeX, but only the content would be exported to odt and html.

I have implemented the new :export attribute in the last commit, to
experiment (in any case, it can always be reverted). The syntax and
usage are as described in the previous message. An example, where we
define an alias for inline comments and another for highlighted text: It
will only be exported as highlighted text to LaTeX (using the lua-ul
package for LuaLaTeX); only the content will be exported to HTML; and it
will not be exported to the rest of the backends.

#+options: inline-special-block-aliases:(("comment" :export "noexport")("hl" 
:export "latex+ html*" :latex-command "highLight"))
#+latex_header: \usepackage{xcolor,luacolor,lua-ul}
#+latex_compiler: lualatex

@hl{this is highlighted text, only in LaTeX} @comment{this is a comment}

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

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

[Juan Manuel Macías]

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
backend should be followed by a "+" sign (= export all) or "*" (export
content only). For example:

@foo[:color red :export latex+ odt* html*]{lorem ipsum dolor}

This means that "lorem ipsum dolor" would be exported with color format
to LaTeX, but only the content would be exported to odt and html.

Wdyt?

Best regards,

Juan Manuel