From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id wO8DM+ZiOmNQjwAAbAwnHQ (envelope-from ) for ; Mon, 03 Oct 2022 06:19:50 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id ONAFM+ZiOmNgbwEAauVa8A (envelope-from ) for ; Mon, 03 Oct 2022 06:19:50 +0200 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 6C8F011888 for ; Mon, 3 Oct 2022 06:19:50 +0200 (CEST) Received: from localhost ([::1]:43476 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ofCvl-0005rv-15 for larch@yhetil.org; Mon, 03 Oct 2022 00:19:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37104) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ofCuX-0005o9-9E for emacs-orgmode@gnu.org; Mon, 03 Oct 2022 00:18:33 -0400 Received: from mail-pf1-x429.google.com ([2607:f8b0:4864:20::429]:33456) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ofCuT-0006z5-8e for emacs-orgmode@gnu.org; Mon, 03 Oct 2022 00:18:31 -0400 Received: by mail-pf1-x429.google.com with SMTP id w2so9210280pfb.0 for ; Sun, 02 Oct 2022 21:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date; bh=LayZKa0xDV0PC6mH6zG7l779KRZOT4Om8sPIePyVboM=; b=Oqgk7PtLqDwhBsFJ9AoUjY3qMd6TdVC7EslyTCgA6BozsPk9+mVrvjsHF8cZW1n28c 1znQKN818UVvtA6LFPbPH67Sc1B8Iupp65EO8tqeWm1RKY0hLk4lAmTaTiouHU1cLF79 MINIuDlEdoUwXGCnjJ2Sgrjb0UJZFd0AwR5p3itNxgAxUI3uTQuNTWtzvV4R0mJ1klVc N+FzLGZconlTJPPBJYXfdVzhtL5IUern8lxEJk8FwNi4J4bm8zhUO6uRb+m9GbLcMqI+ RrYwVlU/WRIZUPhKhoGxZDjy9x2dSAjRPT8i5bch45bpXCtD2/a/4ffswCPW7pDstg8I 1a2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date; bh=LayZKa0xDV0PC6mH6zG7l779KRZOT4Om8sPIePyVboM=; b=ws/1Mn2gA15tdpbu5ZH2yaJ2xkLfyBSdVsSo4BkDQXq7nWqjFRukMC9vvGrYafZ/Z1 kUMS2uO7EGjoIywr9U99FQBDlrIpE5FrEI17ffNfxPzSBBDJB5Cn999j7AKf9JI+UII9 clv//sEBiFNrzCly6QruN2E2Xlz2+E3UtgX4jizQzAEH1XV/ZDQhnMrg1zi8wl8Bkh09 1RrCNN/i0lKVyZXiynKwR7WFA4wXnB5ChkYbKuitYVf4ptnB9c/EtUkIsouLVDbXd6Iu /RtUy3uEIGIV3kDGfrdaX224XgUwBn3clSx+b2oRi/Pe6yOx8y8SEtluggL50P6xAP16 tP5w== X-Gm-Message-State: ACrzQf2Ch7u38MjH4lM0fio5ASREB6PIRcWcmC8Tr26vLHAPdRwCtHRH mVhcE5FB0SnxAQ32wbPyJQ1vQvzJamK+7HhF X-Google-Smtp-Source: AMsMyM4BcvwoCOCa6/3ACVoQsj8EVPIxvP3C+nzk5omrP9m7KFLHdRPXS3SPAxhrXXcy7zXex1Gvlg== X-Received: by 2002:a63:721a:0:b0:447:d900:ba3a with SMTP id n26-20020a63721a000000b00447d900ba3amr7838638pgc.177.1664770705592; Sun, 02 Oct 2022 21:18:25 -0700 (PDT) Received: from localhost ([1.83.154.214]) by smtp.gmail.com with ESMTPSA id e2-20020a17090301c200b00172ea8ff334sm6137380plh.7.2022.10.02.21.18.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 Oct 2022 21:18:24 -0700 (PDT) From: Ihor Radchenko To: Max Nikulin Cc: emacs-orgmode@gnu.org Subject: Re: [HELP] Fwd: Org format as a new standard source format for GNU manuals In-Reply-To: References: <87bkqx4jyg.fsf@localhost> <86pmfcv7jq.fsf@gmail.com> <875yh42nj9.fsf@localhost> Date: Mon, 03 Oct 2022 12:19:18 +0800 Message-ID: <87wn9hy1x5.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::429; envelope-from=yantar92@gmail.com; helo=mail-pf1-x429.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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: , 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=1664770790; 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=LayZKa0xDV0PC6mH6zG7l779KRZOT4Om8sPIePyVboM=; b=ncVC2K3dPU5QDZ7yydFkFnC7VEoAy988mpwGJVfYYzkzDzndQJZ9h5cHZ/vu+TuUP7VLA4 YHKXuVQPjOGliocgDvavM5MMzk2/IS7jIckDdua2sng0f81UOLLm85XU8JrtK/j3VFsQO1 Ni2rKzo/kBZ+83grhlkYbzfWi/q5+fC0e+m3Jxytsch/xE/03PTekd7TXgxnPNj2sIKd1G 6BL4FLo2GF0KL0yDWyp+M65jwDxKOEfUgvTfB9E4T/tddBwkRZpLDbgXUbwuSMbi8HiWY8 lWIRhjs3OnAYf9p1jomOYnZ5lsUn7ZiSNT3VrQXaXMX0Q2kt+UqY4lipDhWISQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1664770790; a=rsa-sha256; cv=none; b=MQPdPNCuOV2ViiQjdARF2RZS92QDARqWgTd47xmi5kH0KH7SVsC4aDDwZgXC+PDJ/KYATd lG3thUyXRZF6S9GV/qvSoegsIeLETezokpnMJHGjjbU2Ld+M6STvjrYFFUrrrH3sXxYk/C yqeyYNlA4yBt2juv3E7U7UBbdeObNvn2ikJG8II88DnKs9YlBmIa2nRM3gwbOCiMoUHRuq bwZqNMGFADIshhV2Oz8H6PQ15bFCQm79eCKAHvgVUkwRsuYoJ+RdYSNQ3SYCAZQXj7HKUn 45a2qm70KkD5qSV51JOj+H+qd8aofEG+vtKdmUmQUGgUPqutPH9EFG0tpm6oXg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Oqgk7PtL; dmarc=pass (policy=none) header.from=gmail.com; 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: -6.85 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Oqgk7PtL; dmarc=pass (policy=none) header.from=gmail.com; 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: 6C8F011888 X-Spam-Score: -6.85 X-Migadu-Scanner: scn0.migadu.com X-TUID: b7qrf4wFpvrW Max Nikulin 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 . Support Org development at , or support my work at