From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id aKx2GlYwrmENKgEAgWs5BA (envelope-from ) for ; Mon, 06 Dec 2021 16:46:30 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id SDksFlYwrmFTMwAAB5/wlQ (envelope-from ) for ; Mon, 06 Dec 2021 15:46:30 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 195CE396E6 for ; Mon, 6 Dec 2021 16:46:30 +0100 (CET) Received: from localhost ([::1]:50516 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1muGCC-0002HB-4Z for larch@yhetil.org; Mon, 06 Dec 2021 10:46:28 -0500 Received: from eggs.gnu.org ([209.51.188.92]:45722) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1muGBV-0002H3-OL for emacs-orgmode@gnu.org; Mon, 06 Dec 2021 10:45:45 -0500 Received: from mout02.posteo.de ([185.67.36.66]:59665) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1muGBT-0002Wj-6f for emacs-orgmode@gnu.org; Mon, 06 Dec 2021 10:45:45 -0500 Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id B5D16240104 for ; Mon, 6 Dec 2021 16:45:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1638805540; bh=TVNqJo7ICfdmnfJ+aT7SareOrPBwd+RtOWM+xVlxEJw=; h=From:To:Cc:Subject:Date:From; b=ojHA4DCbWd3AAlZlJa7EVAa1KP16E1Voz8qL+6N6FF7HefaZYKJVye5AirQ1Gdy6D T7nSuNz89j85Bp9QsouHWmfD4ZSd89HmM5KOjw1Qg2SB8QVd/rg48wS9SxwM7frq3a kpip2ti8YXrqjgD0dkrPsTIegdlAgKRAgeNDkBPtIIw/ozcMrXaQYOGHvlLKHvoTM8 gSCP20W4lxfbSSIs5BY3cBxhd28xfglKmHJ81MwTYoE+YGW4aMrCwqXVEbUPeUZECQ WoQlS0qUqelFnBJsl7xmPaEc5GDSUKurpoWtqDl7rerLbJIojGggLUgom4Ro8vVgUd Wh1DVkVKBbIQQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4J77780Fqvz9rxW; Mon, 6 Dec 2021 16:45:39 +0100 (CET) From: =?utf-8?Q?Juan_Manuel_Mac=C3=ADas?= To: Max Nikulin Subject: Re: Raw Org AST snippets for "impossible" markup References: <4897bc60-b74f-ccfd-e13e-9b89a1194fdf@mailbox.org> <87fsrbp673.fsf@gmail.com> <1ef0e093-c165-2a5f-954d-6a33b64c8ee9@mailbox.org> <87r1avgnpi.fsf@localhost> <878rx2bzhw.fsf@nicolasgoaziou.fr> <9525e029-a590-3f48-df64-ffb9176075d9@mailbox.org> Date: Mon, 06 Dec 2021 15:45:37 +0000 In-Reply-To: (Max Nikulin's message of "Mon, 6 Dec 2021 17:57:04 +0700") Message-ID: <87k0gh68ke.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=maciaschain@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: orgmode Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1638805590; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=Q+s2+FquomCMD4xqP3ZgyVkFEk6hblZz2AlmHJ0ZHfs=; b=MvI4Y33FuE7Oj3r0vPKnB2CrFTRXzBgCljldj1FWhKCpfrk9+pFmKse9opc3uroPR8jrow 3dAoa6E72itr9LUH687uP6rgzyMmCEfRH0Ql8tBjrfiJevMJ1EjRSZ4mdbi1CRz8gKs5K0 Pnd5O31UQruqzBqtANAevht04S6DBoG1UvAq9W3e4HsvxqDVTT7Y+ep+Bb1ke5e6ulobiY xlvVXB5wmRrIzMEawPcDSxD/o0vHdiUnahI0ZOUVFgrvwFpHdoc6PyQpJEYVQt2YfQ3+Nd jaWp3QtLkQhEf06driWVtTAHkfQW0Ro3MZftO/X1SPxUSTAXyJI+4yfgT+2QyA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1638805590; a=rsa-sha256; cv=none; b=CLMkbV10MUs1gF28KO1F6Gl6jlGgsHM8kzt0QCnXenqGLwkqpcdu3TJhj42qpK1jX0pSmZ DTt5hSIH+8QEc/TpREYtA2cbHUEQAVlg00isuW94sCvWzbGDqSDk0aa+NSwU3SEQCIf7cy /TkeHtS4+FMKEdW0jE7bduw+0Q0nckS2oEHCmRYerhHs1uxpJpt/yclgxKAt7xcwtJlwxU tz5jWsnvzY8JgMCccFddMSlFfhFXs2oupJZexu0rHS2o4rONMqwGJ8uCqVXbiwO1gFATc5 O7xMcNsa590gpl8RySfKMRur2f9G/A394caTgEMh06mtH4JYkf1yWMgsantUqQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=ojHA4DCb; dmarc=pass (policy=none) header.from=posteo.net; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -4.34 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=ojHA4DCb; dmarc=pass (policy=none) header.from=posteo.net; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 195CE396E6 X-Spam-Score: -4.34 X-Migadu-Scanner: scn0.migadu.com X-TUID: 90Kmb50b6WIz 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 > links may be used. Certainly plain text may be outside: > > #+begin_src elisp > (org-export-string-as "A word" 'html t) > #+end_src > > #+RESULTS: > :

> : A interword

> > - 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:@@" arg "@@html:@@")) ((org-export-derived-backend-p org-export-current-backend 'odt) (concat "@@odt:@@" arg "@@odt:@@")))) (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