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 gHN2GOJrrWMKFAAAbAwnHQ (envelope-from ) for ; Thu, 29 Dec 2022 11:28:50 +0100 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 OPJOGOJrrWOvjAAAauVa8A (envelope-from ) for ; Thu, 29 Dec 2022 11:28:50 +0100 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 2D148DF43 for ; Thu, 29 Dec 2022 11:28:50 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pAq95-00017F-2K; Thu, 29 Dec 2022 05:28:19 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pAq92-00016r-9D for emacs-orgmode@gnu.org; Thu, 29 Dec 2022 05:28:16 -0500 Received: from mail.tuxteam.de ([5.199.139.25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pAq90-000160-ES for emacs-orgmode@gnu.org; Thu, 29 Dec 2022 05:28:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tuxteam.de; s=mail; h=From:In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:To:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=4MTvPqBvAqe0+Nqtj1gveKtw/qaOOlv4dMCkEeW5P0w=; b=RVD0oHUjSgIoKblsWZmg43MJKc W3tE70/QsrJFMwtx0aIEqBq085chckEJCy+n71Jcr0UUAe9+ll4O70l070MV+Y18vz72Z9LuThQ6w HQtPwA1idVdoXyWfnpi68bxSMjvPu6moHvj4zQe0ruEJqWhucsyoqPzt8Yh4+dkRK++0ALAqU01NV v2M/QNX22bQGk9voLSSBpmSE6Nu026i6QIogFQpNQi93+zv9Fw8p4RGd/XHG24IbnrPtuLXW7Hv7d jyWnsak9xx3WMe39iwUPiIwqcd0JWPghC99DOwPfzHmdDrCfzRHKQRwyFLDF+5fJh2ChkeDXFbDbI OWOrZEQA==; Received: from tomas by mail.tuxteam.de with local (Exim 4.94.2) (envelope-from ) id 1pAq8v-00018J-7Q for emacs-orgmode@gnu.org; Thu, 29 Dec 2022 11:28:09 +0100 Date: Thu, 29 Dec 2022 11:28:09 +0100 To: emacs-orgmode@gnu.org Subject: Re: section continuation Message-ID: References: <2a8c15a7047e6dd4979b311a5c373255@bitrot.link> <9ceaa25e9e84c9c2db5cb385c51eb1db@bitrot.link> <248c92c57142c9119ce0b6f51b41da46@bitrot.link> <87wn6cksy8.fsf@localhost> <86358yu47w.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zulNcpxnGdzU1m23" Content-Disposition: inline In-Reply-To: From: Received-SPF: pass client-ip=5.199.139.25; envelope-from=tomas@tuxteam.de; helo=mail.tuxteam.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, 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-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1672309730; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=4MTvPqBvAqe0+Nqtj1gveKtw/qaOOlv4dMCkEeW5P0w=; b=KS5vrDRlO7wJ+QIhn1kjZtv6yjHpGjDUqhHJ7YGSq3ShGSQfyzTmBhIo/WPVytefRxQ1d1 KZiebFdZ5j+ywTkwldOevvZXZNep+9lMRIGvVyafb4aH/X59LbEhgHV0O44Op1JWv+xQL1 Pu3677tsJTVEJSWBTXHa1UmQ1LuWD2+7x0Y3u/JXbSosRADlkyZOu+pI8WrUAULqSbAGq2 4s4W7xeRExoThtYJnqShdI1/DLMhOf9FxmQVXxqbgm/vyGz2W1MwpWsJAUG3KH9LSKGFO2 FVse65tOd+/oy3nsrkYXRhC+iaFnB2BZ9MUqRadTTACUY86YoGWcxV65u9cmAQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tuxteam.de header.s=mail header.b=RVD0oHUj; 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"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1672309730; a=rsa-sha256; cv=none; b=W64AiRAK+SMd2EBOmu4939SyvP3FuKqfOyv0aDMbUME2LV+C5XY9wPKcpiTu4cyIfPkNWV cIqIVSD+pfdFPtjaWD7JTEsW0rl5vRcdU/onUPjANthximjmPspft7VDfg6pU3nu2it+Jv moSgwrhCaJy43XGVj5mirjsHp4Xtr/V9FakTvq5eYoXRiXqCIK9HGw/feyv2o7Y8KVSeKZ CcmEYzGLW/07A4Ujkkwd8Hez8eVpkH8Y1iqGb6/KFeRyyYufeMjCJrWtofLzRM/4NdrzjI abWRtbNSKKB9U45COjwUI7qZ00fFJMS/BRPhAPrhSMz9CZmqdLDo2Gtknb41cg== X-Spam-Score: 0.57 X-Migadu-Queue-Id: 2D148DF43 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tuxteam.de header.s=mail header.b=RVD0oHUj; 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"; dmarc=none X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: 0.57 X-TUID: ei9O0FqYBKKM --zulNcpxnGdzU1m23 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 29, 2022 at 10:21:55AM +0100, Heinz Tuechler wrote: [...] > Agreed. I think that "allow certain nodes to only have one text element > at the very beginning" is an arbitrary choice. There are many arbitrary choices when designing a data structure to represent text. > Inconvenient, but logically cleaner would be to allow for text either > only in leaves, You'd regret that quickly: what do you do for inline markup (e.g. bold, italics)? You'd have to introduce a special markup for "normal" text. Good-bye "lightweight markup" :) > or in any place of the nodes. This is XML's "mixed content". Note that specific XMLs can and do limit that, via DTDs or other validation restrictions (aka schema). If you're doing text using some suitable XML schema, you most probably won't be able to put a whole paragraph whithin a section title. Or a table. If you want a whole italics stretch straddling a paragraph boundary, you'll have to close it before the paragraph's end and re-open it next paragraph or something (although they might, logically or philosophically, belong together). Human language is too exciting to fit into a tree structure. > The latter appears more natural to me, as it would allow for connecting > words between sub sections and closing remarks at the end of a section. > Usually, one would circumvent the problem by inserting a connecting text > at the end of subsections, although this would offend the hierarchy. > best regards, Heinz You'll always end up offending some hierarchy some of the time. In some places you can be sent to jail for that ;-) No, seriously: Document models sometimes get stretched to data description languages (I always cringe when people talk about a JSON or YAML "document") and vice-versa. This is a strength, but also a weakness. And don't forget, OASIS's OpenDocument format also doesn't seem to support "going back". Perhaps for a reason. Cheers --=20 t --zulNcpxnGdzU1m23 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCY61rswAKCRAFyCz1etHa Rn8DAJ0fQsPhn3rCA6QXYfvlKp9PKLFXXwCeO3csW9c6IZA9qwOUyJ1rvimQswM= =2KSp -----END PGP SIGNATURE----- --zulNcpxnGdzU1m23--