emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@gmail.com>
To: Max Nikulin <manikulin@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [HELP] Fwd: Org format as a new standard source format for GNU manuals
Date: Mon, 03 Oct 2022 12:19:18 +0800	[thread overview]
Message-ID: <87wn9hy1x5.fsf@localhost> (raw)
In-Reply-To: <th9l5s$fle$1@ciao.gmane.io>

Max Nikulin <manikulin@gmail.com> writes:

> On 01/10/2022 11:08, Ihor Radchenko wrote:
>> In particular, I suggest to (1) extend the existing special block elements
>> with Elisp-configurable :export settings; (2) add special block
>> equivalent object.
>
> While I do not mind to have flexible generic inline objects, I feel some 
> doubts.
>
> Export is already customizable through creation of derived backend. For 
> links :export property is merely an alternative way supposed to be more 
> convenient. In some sense it is a way to dispatch proper handler, a kind 
> of virtual function table, etc. I see a couple of limitations with link 
> export implementation.

Creating derived backend will force users to use that non-standard
backend for export - inconvenient. Especially for third-party backends.

:export property, among other things, can also provide a reasonable
fallback for arbitrary backend not considered in advance.

> 1. Interface is rather different from the derived backend property. 
> Instead of org-element object only selected properties (and backend 
> communication channel is available).

Is it? :export function for links is taking similar parameters with the
other export transcoders.

> 2. Unsure if there is a robust way to extend implementation of the 
> backend handler without replacing it completely. I mean a function that 
> modifies or sets some attributes and delegate real export to the default 
> handler.

We may provide something like :export-filter-object that will act
similar to `:filter-parse-tree' and replace the original link object
with arbitrary Org AST.

> Mentioned in this thread texinfo commands are not convincing reason for 
> special blocks from my point of view. They are different flavors of 
> verbatim (or code) object. If they are verbatim objects with some 
> additional property then they may be just exported by a backend that is 
> unaware of their kinds. It can be considered as graceful degradation. 
> For special blocks export handlers must be implemented for each backend 
> unless type hierarchy is someway declared.

No. There is no need to consider every possible backend. There could be
an export handler that will provide a fallback for unknown backend, if
needed.

> Earlier we discussed assigning attributes for inline objects. While 
> nesting is not involved, it may be a way to implement necessary texinfo 
> commands as verbatim with class or type attribute. I am unsure if 
> different types of special blocks is the best way to resolve nesting 
> problem. Verbatim custom objects require different rules of parsing.

Please do remember that texinfo commands, are _not_ verbatim. They can
contain other markup inside. I'd rather look at them as extended
emphasis. Their contents must be parsed as well.

> Actually I simplified things when wrote that a backend may be unaware of 
> verbatim type. When nesting is involved it should be ready at least to 
> nested verbatim object. E.g. markdown backend can not blindly wrap text 
> into backticks, it has to check if parent element is not a verbatim 
> snippet or a verbatim block.

Agree. See export filter idea.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


  reply	other threads:[~2022-10-03  4:19 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1ocmvz-0002iB-2M@fencepost.gnu.org>
2022-09-30  3:31 ` [HELP] Fwd: Org format as a new standard source format for GNU manuals Ihor Radchenko
2022-09-30  3:49   ` Samuel Wales
2022-09-30  5:47   ` Thomas S. Dye
2022-09-30  8:25   ` Christopher M. Miles
2022-09-30 12:49   ` Max Nikulin
2022-10-01  3:30     ` Ihor Radchenko
2022-10-01 10:42       ` Max Nikulin
2022-10-01 11:01         ` Ihor Radchenko
2022-10-01 11:27           ` Max Nikulin
2022-10-02  4:59             ` Ihor Radchenko
2022-10-02 10:38               ` Fraga, Eric
2022-10-02 13:02                 ` Ihor Radchenko
2022-10-02 13:21                   ` Fraga, Eric
2022-10-02 13:47                   ` Juan Manuel Macías
2022-10-03  4:23                     ` Ihor Radchenko
2022-10-04 20:28                       ` Juan Manuel Macías
2022-10-05  6:56                         ` Rick Lupton
2022-10-06  3:39                           ` Ihor Radchenko
2022-10-02 16:28               ` Max Nikulin
2022-10-03  4:36                 ` Ihor Radchenko
2022-10-04 16:32                   ` Max Nikulin
2022-10-06  5:55                     ` Ihor Radchenko
2022-09-30 20:36   ` Tim Cross
2022-10-01  4:08     ` Ihor Radchenko
2022-10-01  8:01       ` Tim Cross
2022-10-01 15:08       ` Max Nikulin
2022-10-03  4:19         ` Ihor Radchenko [this message]
2022-10-07 22:48   ` Richard Stallman
2022-10-08  6:52     ` Ihor Radchenko
2022-10-08 22:34       ` Richard Stallman
2022-10-11  3:03         ` Robert Weiner
2022-10-11 12:16           ` Ihor Radchenko
2022-10-12 22:00           ` Richard Stallman

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=87wn9hy1x5.fsf@localhost \
    --to=yantar92@gmail.com \
    --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).