From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id uDnIDiJYOGOgMQAAbAwnHQ (envelope-from ) for ; Sat, 01 Oct 2022 17:09:22 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id yNfJDiJYOGP8OwAA9RJhRA (envelope-from ) for ; Sat, 01 Oct 2022 17:09:22 +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 CE32D25515 for ; Sat, 1 Oct 2022 17:09:21 +0200 (CEST) Received: from localhost ([::1]:49162 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oee7D-00079g-Ot for larch@yhetil.org; Sat, 01 Oct 2022 11:09:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45064) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oee6n-00079V-Lp for emacs-orgmode@gnu.org; Sat, 01 Oct 2022 11:08:53 -0400 Received: from ciao.gmane.io ([116.202.254.214]:59302) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oee6m-00043K-6s for emacs-orgmode@gnu.org; Sat, 01 Oct 2022 11:08:53 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1oee6i-0004G9-Ps for emacs-orgmode@gnu.org; Sat, 01 Oct 2022 17:08:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: [HELP] Fwd: Org format as a new standard source format for GNU manuals Date: Sat, 1 Oct 2022 22:08:42 +0700 Message-ID: References: <87bkqx4jyg.fsf@localhost> <86pmfcv7jq.fsf@gmail.com> <875yh42nj9.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Content-Language: en-US In-Reply-To: <875yh42nj9.fsf@localhost> Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 1 X-Spam_score: 0.1 X-Spam_bar: / X-Spam_report: (0.1 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-2.743, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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=1664636961; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=nFuE6y6GAJW8AqHURuljJVB3ORWuMkD1LTDhnVDwS4I=; b=NEIeRTvW4r5qxJgmq7Pox5S8nia+hjy9K6ZB1NM4eMw2FXK7QDEB9itMxYWB5Ij95P/uxP pL6X9VLjVwdybwEHXYeTEN8JHrCKl9L+KeuePFhI3ATrsptoEWt/PCuRqanWe24C/bW4Yb yM+4xikSq47k1jNK7DKKpL6K0Jxz0a+VEGXwZikV4TcJ7/nsD+zfwF0Kb/XwRx3Z8QrcNJ B1T0A47b2Uz9XEfTtj/Oh1gUgk9Se8nN3TYZIpwqomFgwQ7XsSD7Evwhaw+xqiN1seS0Nl v8UKUlBxEVwkyhsbY/Elw3H2IjUjQyS16HgPvh0apQgSmEJKfA+8Tw7zVUQjyA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1664636961; a=rsa-sha256; cv=none; b=tDoDnCGfX/HLgtu8Xr3bCU4RFAYaSOV6CndEb/ZD3CfkiC0GfJ+mRItYbmsxcONJXkB2lD 6LxVl7Lq2AuMRE1D9pZhYSbW85eO6HuFhUx4MneBeSscd7K9wReFPwKykamLMKKpr8+B0w WJuarv1dHjKyIxhF645I3o/UkFakyITpJUsWs6KLoaxypMGwNs2eDI5DsWKRI0MPLbtns6 EgDP/PV9t/c5aN5bSeCm5Bv4edyw5HGrxzFbACig1Rm+fY9tgqFya3xP0LyfC+Hpopjex4 EDUQmpD9zWM/KC1F5ci3Bo36Z4vAe2Le3/7OKIjC+IHTX/YBqIrisHeJdcB4yw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); 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: 2.86 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); 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: CE32D25515 X-Spam-Score: 2.86 X-Migadu-Scanner: scn1.migadu.com X-TUID: x0ZWDziIkp8H On 01/10/2022 11:08, Ihor Radchenko wrote: > Tim Cross writes: > > I do not think that we need to add all the variety of Texinfo-specific > constructs to the Org specification. Instead, we should add generic > configurable syntax elements to Org. (The Texinfo-specific part will > come as a separate library, similar to ol-*.el) > > 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. 1. Interface is rather different from the derived backend property. Instead of org-element object only selected properties (and backend communication channel is available). 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. 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. 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. 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.