From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id 4Cq9LUDzxGUtcgAAqHPOHw:P1 (envelope-from ) for ; Thu, 08 Feb 2024 16:29:04 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id 4Cq9LUDzxGUtcgAAqHPOHw (envelope-from ) for ; Thu, 08 Feb 2024 16:29:04 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=Bm93m87N; 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=pass (policy=none) header.from=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1707406144; 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=ToYPiaiTzlVnqnKlYW23tHa4sXczqCZCF0NKp/sbt9E=; b=EOUI7QVk608jWLhBU1BhsSgENC4KMss+PhcdDzKFW8S8GTfTZrt1CRPWzslJbOZbee3JGD PZUb7DCoPu2Vw++ZmHCaolIZxOJ5VQRteOWXTrodmZ1U/xQR/3eFekRJTuI+wMbuHYBqe8 n16omHhvvtxikJ65QQAMVubudmGq2FNIHhDaYyjIUJUPyix+/qYWpV1JDDuSu7i4lqMpIV 0dKfky3u8B1VGdci7ue0mE0uBsDYv+wDO3D5VN5CtuTombUMRVqhxKMy7IpMnlds2TiKIk SLOerFBEguJ9ip5WYvwoJ3d5+vSX2CCO99VMuNGKfUApj5M5Ie7dIML53JXIfw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=Bm93m87N; 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=pass (policy=none) header.from=posteo.net ARC-Seal: i=1; s=key1; d=yhetil.org; t=1707406144; a=rsa-sha256; cv=none; b=EtNj27SL1iFrh9MHML/t/jDmHwE9Mne8ztz5Nq+nI3qkLpw6W4tjJ5KpmMlOtnXxowjlA+ Pn3yO3QSwwvBG78F5+Rrjeu5hbNyHXjN/wApu0qIjMHpMTOgTCfgvzkm+N2im7/9aEEIto +88/M7FFGREIcUUXMZafasvqS7WhWnFYUj9oSPlRw4aFMT1U+FlbBtFzZeUpEYR06r/y4s IAU+5PsxiQXq6lNo2X3JosfrdPBFR7cuEAi/ZjZxffZcIvEnC9ONmZHwKpx3QQoaRlY19L vmcaLyaUL4UGri1HI2QMkD2EvIFZC2VMAR/I2pmZZy3Wozs8tqwM7Kq3K0Qtwg== 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 8B44E524B1 for ; Thu, 8 Feb 2024 16:29:04 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rY6K9-0000PI-AG; Thu, 08 Feb 2024 10:28:25 -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 1rY6K7-0000PA-Gz for emacs-orgmode@gnu.org; Thu, 08 Feb 2024 10:28:23 -0500 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rY6K4-0002BI-Df for emacs-orgmode@gnu.org; Thu, 08 Feb 2024 10:28:23 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id EBA84240101 for ; Thu, 8 Feb 2024 16:28:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1707406097; bh=2yBsVF6iQqliWbSk/MlotD33/n0kHqCkF3AHh4zd9FI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=Bm93m87NbMnuOTOLDN2kRqFwm5ohZ2aqkRMmpP299TBY35lZST1MJMxMvDLr8aLI2 D9wjqqHQoVWwsLhH3PeYtmGWARAoQhJCrNGVud8VCVSCKxAtlQrIn8/8vXEn38Laky TROHzYSbWiQdEJdrbfhLPTLFNXb5AlByKluMZT4Cy6w1lH3NFEJqI7ZON8wCqrYAx7 EvdkXPI5DJboM2KmzBkfeh3eVRF1aRXu8vXQOeVaoFMFJ15fCquibvk7K2wMUp0u4+ Mk723Il/j6jYBAfzfSNnPMoXqdRHHHwX9WH+EZtdwUkzZknlDq74bzMaNTYcaX/ow5 V1+fkcvsaTJxA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4TW18c0my0z6ty3; Thu, 8 Feb 2024 16:28:15 +0100 (CET) From: Ihor Radchenko To: Jason May Cc: emacs-orgmode@gnu.org Subject: Re: Org mode version 9.7-pre (9.7-pre-n/a-g093879 In-Reply-To: <27899b3fba30cc984e2d8fa4701d26066471f8b9@hey.com> References: <27899b3fba30cc984e2d8fa4701d26066471f8b9@hey.com> Date: Thu, 08 Feb 2024 15:31:47 +0000 Message-ID: <87sf23ynto.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -6.89 X-Migadu-Scanner: mx13.migadu.com X-Spam-Score: -6.89 X-Migadu-Queue-Id: 8B44E524B1 X-TUID: B/IcfmVxle7h Jason May writes: > This request was prompted by an issue encounted in org-journal, and it > probably exists in org-roam and other similar packages. > > Ignoring blank lines sounds like a reasonable approach. It is reasonable, but I am not convinced that it is important enough to make changes to Org mode syntax. Allowing blank lines may help with certain types of accidental edits - a small fraction of possible accidental edits. The benefit is very small. Too small, IMHO. > For more significant syntax violations such as your example, perhaps > org-entry-get and other functions should raise errors instead of > silently returning nil? That would require org-entry-get to try searching things that /look like/ malformed property drawer. This will be (1) slower; (2) defeat the purpose of changes introduced in Org 8.3 https://orgmode.org/worg/org-release-notes.html#orgaf78411 I am not in favor of such change. > I'm going to investigate how it might be possible to initiate an org- > lint if an exception situation was to arise in org-journal. Org syntax is not restrictive. We deliberately allow people to write arbitrary text that do not follow strict rules and Org still recognizes such text as generic text with no special meaning. So, Org mode syntax has no notion of exceptions. There are of course common mistakes when writing Org markup. That's why we have org-lint. However, org-lint is always suggestive - it is an equivalent of compiler warnings. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at