emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Raw Org AST snippets for "impossible" markup


From: Juan Manuel Macías
Subject: Re: Raw Org AST snippets for "impossible" markup
Date: Mon, 06 Dec 2021 15:45:37 +0000

Max Nikulin writes:

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

Hi Maxim,

I understand that with this method the emphases could be nested, which
it seems also very productive. I like it.

I would suggest, however, not to use the term 'italics', since is a
'typographic' term, but a term that is agnostic of format and
typography, something like as 'emphasis' or 'emph'. For example, in a
format agnostic environment like Org, which is concerned only with
structure, an emphasis is always an emphasis. But in a typographic
environment that emphasis may or may not be be in italics. That is why
in LaTeX you can write constructions like:

#+begin_src latex
\emph{The Making Off of \emph{Star Wars}}
#+end_src

In this context 'Star Wars' would appear in upright font. Naturally,
these things are only possible in LaTeX, but it's nice to keep in Org a
typographic agnosticism.

Anyway, I find all this very interesting as proof of concept, although
in my workflow I prefer to use macros for these types of scenarios (yes,
a rare case where I don't use links! :-D):

#+begin_src emacs-lisp
  (defun my-macro-emph (arg)
    (cond ((org-export-derived-backend-p org-export-current-backend 'latex)
           (concat "@@latex:\\emph{@@" arg "@@latex:}@@"))
          ((org-export-derived-backend-p org-export-current-backend 'html)
           (concat "@@html:<em>@@" arg "@@html:</em>@@"))
          ((org-export-derived-backend-p org-export-current-backend 'odt)
           (concat "@@odt:<text:span text:style-name=\"Emphasis\">@@" arg 
"@@odt:</text:span>@@"))))

  (setq org-export-global-macros
        '(("emph" . "(eval (my-macro-emph $1))")))
#+end_src

{{{emph(The Making Off of {{{emph(Star Wars)}}})}}}

Best regards,

Juan Manuel 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]