From: "Juan Manuel Macías" <maciaschain@posteo.net>
To: Max Nikulin <manikulin@gmail.com>
Cc: orgmode <emacs-orgmode@gnu.org>
Subject: Re: Raw Org AST snippets for "impossible" markup
Date: Mon, 06 Dec 2021 15:45:37 +0000 [thread overview]
Message-ID: <87k0gh68ke.fsf@posteo.net> (raw)
In-Reply-To: <sokqa3$e8s$1@ciao.gmane.io> (Max Nikulin's message of "Mon, 6 Dec 2021 17:57:04 +0700")
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
next prev parent reply other threads:[~2021-12-06 15:46 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-02 10:50 Org-syntax: Intra-word markup Denis Maier
2021-12-02 11:18 ` Ihor Radchenko
2021-12-02 11:30 ` Juan Manuel Macías
2021-12-02 11:36 ` Denis Maier
2021-12-02 12:01 ` Ihor Radchenko
2021-12-02 11:42 ` Marco Wahl
2021-12-02 11:50 ` Denis Maier
2021-12-02 12:10 ` Ihor Radchenko
2021-12-02 12:40 ` Denis Maier
2021-12-02 12:54 ` Ihor Radchenko
2021-12-02 13:14 ` Juan Manuel Macías
2021-12-02 13:28 ` Denis Maier
2021-12-02 12:48 ` Max Nikulin
2021-12-02 12:02 ` Ihor Radchenko
2021-12-02 12:00 ` Ihor Radchenko
[not found] ` <87r1avtdjy.fsf@ucl.ac.uk>
2021-12-02 12:27 ` Denis Maier
2021-12-02 13:06 ` Eric S Fraga
2021-12-02 12:28 ` Denis Maier
2021-12-02 12:55 ` Ihor Radchenko
2021-12-02 11:58 ` Timothy
2021-12-02 12:26 ` Denis Maier
2021-12-02 13:07 ` Ihor Radchenko
2021-12-02 15:51 ` Max Nikulin
2021-12-02 18:11 ` Tom Gillespie
2021-12-02 19:09 ` Juan Manuel Macías
2021-12-04 13:07 ` Org-syntax: emphasis and not English punctuation Max Nikulin
2021-12-04 16:42 ` Juan Manuel Macías
2021-12-02 20:47 ` Org-syntax: Intra-word markup Denis Maier
2021-12-02 22:44 ` Samuel Wales
2021-12-03 14:53 ` Max Nikulin
2021-12-03 23:51 ` Tim Cross
2021-12-04 15:01 ` Max Nikulin
2021-12-05 23:34 ` Russell Adams
2021-12-05 23:37 ` Russell Adams
2021-12-06 1:39 ` Samuel Wales
2021-12-02 19:03 ` Nicolas Goaziou
2021-12-02 19:34 ` Juan Manuel Macías
2021-12-02 23:05 ` Nicolas Goaziou
2021-12-02 23:24 ` Juan Manuel Macías
2021-12-03 14:24 ` Max Nikulin
2021-12-03 15:01 ` Juan Manuel Macías
2021-12-04 15:57 ` Denis Maier
2021-12-04 17:53 ` Tom Gillespie
2021-12-04 18:37 ` John Kitchin
2021-12-04 21:16 ` Juan Manuel Macías
2021-12-06 10:57 ` Raw Org AST snippets for "impossible" markup Max Nikulin
2021-12-06 15:45 ` Juan Manuel Macías [this message]
2021-12-06 16:56 ` Juan Manuel Macías
2021-12-08 13:09 ` Max Nikulin
2021-12-08 23:19 ` Juan Manuel Macías
2021-12-08 23:35 ` John Kitchin
2021-12-09 7:01 ` Juan Manuel Macías
2021-12-09 14:56 ` Max Nikulin
2021-12-09 16:11 ` Juan Manuel Macías
2021-12-09 22:27 ` Juan Manuel Macías
2022-01-03 14:34 ` Max Nikulin
2021-12-04 19:04 ` Org-syntax: Intra-word markup Timothy
2021-12-04 21:48 ` Tom Gillespie
2021-12-06 10:59 ` Max Nikulin
2022-01-28 14:52 ` Max Nikulin
2022-01-29 3:13 ` Ihor Radchenko
2022-01-29 13:05 ` Juan Manuel Macías
2022-02-02 15:28 ` Max Nikulin
2022-02-02 20:01 ` Juan Manuel Macías
2022-02-03 12:10 ` Max Nikulin
2021-12-06 11:01 ` Denis Maier
2022-01-28 12:12 ` [PATCH] Intra-word markup: \relax Max Nikulin
2022-01-28 13:13 ` Juan Manuel Macías
2022-02-02 15:42 ` Max Nikulin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k0gh68ke.fsf@posteo.net \
--to=maciaschain@posteo.net \
--cc=emacs-orgmode@gnu.org \
--cc=manikulin@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).