Raw Org AST snippets for "impossible" markup

[Max Nikulin <manikulin@gmail.com>]

On 05/12/2021 01:37, John Kitchin wrote:
> Along these lines (and combining the s-exp suggestion from Max) , you 
> can achieve something like this with links.
> 
> #+BEGIN_SRC emacs-lisp :results silent
> (defun italic (s)
>    (pcase backend ;; lexical
>      ('latex (format "{\\textit{%s}}" s))
>      ('html (format "<i>%s</i>" s))
>      (_ s)))
> 
> (defun @@-export (path desc backend)
>    (eval `(concat ,@(read path))))
> 
> (org-link-set-parameters
>   "@@"
>   :export #'@@-export)
> #+END_SRC

John, thank you for the reminding me of Juan Manuel's idea that
everything missed in Org may be polyfilled (ab)using links.
It is enough for proof of concept, special markers may be introduced
later. After some time spent exercising in monkey-typing,
I have got some code that illustrates my idea.

So the goal is to mitigate demand to extend current syntax.
While simple cases should be easy,
special cases should not be impossible.

- Raw AST snippets should be processed without ~eval~ to give
   other tools such as =pandoc= a chance to support the feature.
   If you desperately need ~eval~ then you can use source blocks.
- The idea is to use existing backends by passing structures
   similar to ones generated by ~org-element~ parser.
- I would prefer to avoid "@@" for link prefix since such sequences
   are already a part of Org syntax. In the following example
   export snippet is preliminary terminated by such link:

   #+begin_src elisp :results pp
     (org-element-parse-secondary-string
      "@@latex:[[@@:(italics \"i\")]]@@"
      (org-element-restriction 'paragraph))
   #+end_src

   #+RESULTS:
   : ((export-snippet
   :   (:back-end "latex" :value "[[" :begin 1 :end 13 :post-blank 0 
:parent #0))
   :  #(":(italics \"i\")]]@@" 0 18
   :    (:parent #0)))

Let's take some link prefix that makes it clear that the proposal
is a draft and a sane variant will be chosen later when agreement
concerning details of such feature is achieved. Till that moment
it is named "orgia".

#+begin_src elisp :results silent
   (defun orgia-export (path desc backend)
     (if (not (eq ?\( (aref path 0)))
	path
       (let ((tree (read path))
	    (info (org-export-get-environment backend nil nil)))
	(org-no-properties
	 (org-export-data-with-backend tree backend info)))))

   (org-link-set-parameters
    "orgia"
    :export #'orgia-export)
#+end_src

Either [[orgia:("inter" (bold () "word"))]]
or <orgia:((italic () "inter") "word")>
links may be used. Certainly plain text may be outside:

#+begin_src elisp
   (org-export-string-as "A <orgia:(italic () \"inter\")>word" 'html t)
#+end_src

#+RESULTS:
: <p>
: A <i>inter</i>word</p>

- Error handling is required.
- Elements (blocks) should be considered as an error
   in object (inline) context.
- Passed tree should be preprocessed to glue strings split to
   avoid interpreting them as terminating outer construct or link itself
   (=]]= =][= should be ="]" "]"= ="]" "["= inside bracket links).
   It is especially important for property values.
- For convenience =parse= element may be added to parse a string
   accordingly to Org markup.
- There should be a similar element (block-level markup structure).
- Symbols and structures used by ~org-element~ becomes a part of
   public API, but they are already are since they are used
   by export backends.
- ~org-cite~ is likely will be a problem.