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 oBQCAwduPmMcQAAAbAwnHQ (envelope-from ) for ; Thu, 06 Oct 2022 07:56:23 +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 OHn7AgduPmNVYAEA9RJhRA (envelope-from ) for ; Thu, 06 Oct 2022 07:56:23 +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 BB66C1B9D5 for ; Thu, 6 Oct 2022 07:56:22 +0200 (CEST) Received: from localhost ([::1]:39572 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ogJrp-0004XS-M5 for larch@yhetil.org; Thu, 06 Oct 2022 01:56:21 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43272) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogJqS-0004Vy-KD for emacs-orgmode@gnu.org; Thu, 06 Oct 2022 01:54:59 -0400 Received: from mail-pj1-x1033.google.com ([2607:f8b0:4864:20::1033]:45587) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ogJqP-0007QW-Nf for emacs-orgmode@gnu.org; Thu, 06 Oct 2022 01:54:55 -0400 Received: by mail-pj1-x1033.google.com with SMTP id o9-20020a17090a0a0900b0020ad4e758b3so742116pjo.4 for ; Wed, 05 Oct 2022 22:54:49 -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=9AnF94hGdaAXMNXbOVMoSrLKeecrDBEIMogM1dzCv4M=; b=j3ex6TV6WPOQokEiQFcn5D/58//exQBevQQ0rZTG7WZo5jAh8I48PGHMvuLQmNbTWk L4Z18i8jEx7o1+lxo2rRA7FOgo4rZ0KEOZN/lf/eoI0gI7ibzWVYR51tBjIXIbYnY83V 3NoYSlzoPgceoVZTg/s/cUbn+KxdXBhEctzTEu1I7r774lH6ZOo+E7ioIZ5y0hGYl3VQ CJPvMWgSB5LqzlUiHm82ClnvBCKwLPNCTOJCAn0xom8eIjLM4i1ye3+zLalsKgd3iMBr ww0oHPkDY93itYsutxohZN3rHW8Say9fGNA41NEmXhO1EYEYqvzZq32o/l2tiaebbFK4 7viQ== 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=9AnF94hGdaAXMNXbOVMoSrLKeecrDBEIMogM1dzCv4M=; b=wOpP7O1jbffaS1m5XwEIRZx4CDh2rXGy/rkTtL8ZFpU6T2kIZHOlW6X46aWMrDBOEf VpXdg7XavjddnDldgD/2DV+wdDGytpuAE9ACxTccsgiJNSGXs5GoFB+Zq56t0ok2BMc4 kItxpGX7rWhEzkbjyKotsPxn2izF13lJBmKqPefEebW75e5qBty3kWxMqmVv6bEzTF+j ZFnAzC/CBa/HtUXkercSBCypG1zcQpjvtxIlnojQpo8APCfca1/yX40fC/3xhygTx4WA p5qvlDFh5bvncVVZN6Y0fYEFrBOBRK8ACjarWRx94ec3mEfemGE6VXF+5xr6y4RsBCsQ beJg== X-Gm-Message-State: ACrzQf077irGYp89/YD5f8R/hP4G0DqWtN9WtCd/VGGfuakFZQxtZyKG RfnKYH6cIzhbmIiam4cs/mE= X-Google-Smtp-Source: AMsMyM5vJzthq5AH4vEbzUCLkDyUONnxPJVlYNy0AFvpy0qWXxAyzJTuCaFwxtkyvpjfc2X2GzS4yw== X-Received: by 2002:a17:90b:1c0d:b0:202:61d0:33c with SMTP id oc13-20020a17090b1c0d00b0020261d0033cmr9023801pjb.90.1665035688167; Wed, 05 Oct 2022 22:54:48 -0700 (PDT) Received: from localhost ([1.83.154.214]) by smtp.gmail.com with ESMTPSA id s4-20020a170902ea0400b00176675adbe1sm11453987plg.208.2022.10.05.22.54.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Oct 2022 22:54:47 -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> <878rm02pc1.fsf@localhost> <87ill3st88.fsf@localhost> <87h70m252s.fsf@localhost> <87r0zpy14r.fsf@localhost> Date: Thu, 06 Oct 2022 13:55:38 +0800 Message-ID: <87edvl5wdh.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::1033; envelope-from=yantar92@gmail.com; helo=mail-pj1-x1033.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=1665035782; 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=9AnF94hGdaAXMNXbOVMoSrLKeecrDBEIMogM1dzCv4M=; b=GNwNw/s8rAaU4BPNrywYUafxS5tCxHvBjCNTtY7F3ABmxEBuNuJcE1C0GHnCjPU84RwSEy E5yyXzfj1A1H/t4QUZJD+Nzq37xEcZd7utkDEz3CYlFmdsXkyN2hFFD5fSJNitqu0Sz8kx phdCyf3L9W9yBZilXSALnkvRZ4PNa7vBpk9y0O22ndd50YlZC0n4vNu4PHbLHmcWJCVVzP myh8DKTm6vFGyj52TB8LQQMM7quzZt660bkLCG3KjN7VM7r7RLEjLJ++cHVPRKWVONfw4+ XKCwlAAfgkFXcdBi7IJTufQyPb7ZU0U+3YXLe2Qk69hAciY4nWfbillmJOcJIg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1665035782; a=rsa-sha256; cv=none; b=ksdphbOePgO64d+1T0jqzyOEfZOGRZChUWltFjeWE+avsJknLtgJ0tVkLEWjDp7quwXUFd B+urPT0xV8WftA100ZlNC9ODitGMEOrjQ26M7ZgPWxXGsjm0SSc9H2d0MHDhksILh7i5sE EuIZYNZnaVKUijRr7Vl1FS+0DUhM5Na0qlQdw4x+BB3bVo+EA75KYy+i++jiyIX/8oJIOs y5wesMCDblJUFsW8ZQgyVAXCaPzWfqm4KKEZPF3QvOlogaTm3ok2R95ngGgFSrmmUv5zKe tQ1HziT1mrc8RHZKQD3CwwynpS7RViy+M/lIzgY0MiztEE0EiAH0P6kTVYC3xw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=j3ex6TV6; 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: -5.67 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=j3ex6TV6; 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: BB66C1B9D5 X-Spam-Score: -5.67 X-Migadu-Scanner: scn0.migadu.com X-TUID: PNcPUoAXSdtb Max Nikulin writes: > It seems I completely failed trying to express my idea. > > Instead of extending Org grammar (syntax), I suggest to change behavior > of source blocks during export. In addition to current :results options, > "ast" may be added. Its effect is that instead of adding text to export > buffer that is parsed as Org markup, it causes insertion of a branch of > syntax tree into original parse results. I admit, during export it may > be necessary to iterate over source blocks one more time at a later stage. So, do I understand it correctly that you are _not_ suggesting the AST format _instead_ of the discussed inline blocks? > Such source blocks should return "Org Syntax Tree", a simplified variant > of org-element. It allows to change implementation details and e.g. to > use vectors instead of lists for attributes in org-element. A converter > from Org Syntax Tree to org-element should be implemented. Doesn't it effectively mean that we need to introduce yet another Org element syntax---"Simplified AST"? > Certainly such format may be used directly as src_ost{(code (:class var) > "language")} inline snippets or as > > #+begin_src ost > (code nil ("libtree-{sitter}-" > (code (:class var) "\"language\"") > "." > (code (:class var) "ext"))) > #+end_src > > block-level elements. However I expect that it is the last resort option > when there is no way to express desired construct in some other way. I can foresee issues when we insert, say, code object in place of paragraph element. The consequences might be drastic. Unless we just allow users to shoot their own leg. > I think, more convenient org-babel backends may be created to parse > TeX-like (texinfo-like) or SGML-like (XML-like) syntax into Org Syntax > Tree hierarchy. The essential idea is that outside of source blocks > usual lightweight markup is used. Source blocks however have just a few > special characters ([\{}], [@{}], or [&<>], etc.) to reduce issues with > escaping for regular text or verbatim-like commands. This is not a bad idea, but I feel like it is getting a bit too far from the syntax discussion herein. You might open a new thread about importing foreign syntax into Org. >>> (code nil ("libtree-{sitter}-" >>> (code (:class var) "\"language\"") >>> "." >>> (code (:class var) "ext"))) >> >> This is not much different from @name[nil]{} idea, but >> more verbose. >> > > Also, more importantly, I strongly dislike the need to wrap the text > > into "". You will have to escape \". And it will force third-party > > parsers to re-implement Elisp sexp reader. > > By this example I was trying to show how to express @var, @samp, @file > without introducing of new custom objects. I do not see any problem with > verbosity of such format, it may be used for really special cases only, > while some more convenient markup is used for more simple cases. I was comparing the inline block vs. your AST proposal. If the AST idea is complementary, I see no issue. >>> If there was some syntax for object attributes then simple cases would >>> be like >>> >>> [[attr:(:class var)]]~language~ >> >> I do not like this idea. It will require non-trivial changes in Org >> parser and fontification. >> >> Using dedicated object properties or at least inheriting properties from >> :parent is the style we employ more commonly across the code: >> >> @var{language} >> or >> @code[:class var]{language} >> or >> @attr[:class var]{~language~} > > I do not mind to have some "span" object to assign attributes to its > direct children. I used link-like prefix object just because a proof of > concept may be tried with no changes in Org. It does not require support > of nested objects. There is no existing syntax for such "span" objects, > but perhaps it is not necessary and source blocks should be used instead > for special needs. The problem is that instead of supporting nested objects we will have to support "previous object changing the meaning of subsequent", which is more fundamental change. I envision the new inline blocks to allow assigning attributes to children. These new inline blocks must not have issues with nesting by design. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at