[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
- Re: Org-syntax: Intra-word markup, (continued)
- Re: Org-syntax: Intra-word markup, Max Nikulin, 2021/12/03
- Re: Org-syntax: Intra-word markup, Juan Manuel Macías, 2021/12/03
- Re: Org-syntax: Intra-word markup, Denis Maier, 2021/12/04
- Re: Org-syntax: Intra-word markup, Tom Gillespie, 2021/12/04
- Re: Org-syntax: Intra-word markup, John Kitchin, 2021/12/04
- Re: Org-syntax: Intra-word markup, Juan Manuel Macías, 2021/12/04
- Raw Org AST snippets for "impossible" markup, Max Nikulin, 2021/12/06
- Re: Raw Org AST snippets for "impossible" markup,
Juan Manuel Macías <=
- Re: Raw Org AST snippets for "impossible" markup, Juan Manuel Macías, 2021/12/06
- Re: Raw Org AST snippets for "impossible" markup, Max Nikulin, 2021/12/08
- Re: Raw Org AST snippets for "impossible" markup, Juan Manuel Macías, 2021/12/08
- Re: Raw Org AST snippets for "impossible" markup, John Kitchin, 2021/12/08
- Re: Raw Org AST snippets for "impossible" markup, Juan Manuel Macías, 2021/12/09
- Re: Raw Org AST snippets for "impossible" markup, Max Nikulin, 2021/12/09
- Re: Raw Org AST snippets for "impossible" markup, Juan Manuel Macías, 2021/12/09
- Re: Raw Org AST snippets for "impossible" markup, Juan Manuel Macías, 2021/12/09
- Re: Org-syntax: Intra-word markup, Timothy, 2021/12/04
- Re: Org-syntax: Intra-word markup, Tom Gillespie, 2021/12/04