From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id WHTaMFC42GareQEAqHPOHw:P1 (envelope-from ) for ; Wed, 04 Sep 2024 19:43:12 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id WHTaMFC42GareQEAqHPOHw (envelope-from ) for ; Wed, 04 Sep 2024 21:43:12 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b="i/QFmxFK"; dmarc=pass (policy=none) header.from=posteo.net; 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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1725478992; 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=YBZKAqO9tEe25gzPfhBtDoW+mpp3bC2lYOZDvpzJMDU=; b=BYG12snn6X8FhTkHluqQNSd5y6bAFy/IvcGc6ie7blcgpLJ6ONvdXUODLeVSCJz861x98W Wo7bGNpqZW8DzAvEfcJMXOMBuCv8eQpZI6+YSGBveCCBwxUumivFPojPpdoJabPQarogm9 G6Zxk1dtUnKJLoy6fIk/igbRsos9Gl96epcpG+OAJsQftQdBBwN8A8F0tG4iX/ChkwBrLz mU4FtOpKTokyByo4NmItfbMuU0bLm5EbgkWXRqpQsei5y7pe8pWhfuHIEpP5Tq8+JoD38H NKmsjdk1XcmJiyt5hTpqg5J7CkZGislB0hfyKVp65fwFutlvVQo3zUiqUQpPCA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1725478992; a=rsa-sha256; cv=none; b=Fr89/5kgU5RHGFp9F5TKIicgZlIr4AK8164fu+tCzQ+ChBbYXq/pO1Ch5bOqto8JPGHHq3 KlXSIX6TbVb5Fu9UYjCGrPrriMbDsHfYqBFOYYYiEWSBUhflqCmHG0Ko6HwI2Of6mFN2nd 968aRisRREFK4KmTc5FY/bFWjeRCOfQbH4ofxMp41xXnJdUmOmZqXIFj+RYodJgGpLVaSd j3TaAp0ktnxaLO0ojz+Vh5oHLCNQlcjJ87st0MiENEh4TRPZXFfawUv+qqm8DdepSqy2m2 Alkyn+3Ua5tRxy60VvedZ9pFQXL4/pjBbzhAqECE7fEtksQxXTG1lz98DtfI/A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b="i/QFmxFK"; dmarc=pass (policy=none) header.from=posteo.net; 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" 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 834E8706CD for ; Wed, 4 Sep 2024 21:43:12 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1slvtD-0001nb-1C; Wed, 04 Sep 2024 15:42:03 -0400 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 1slvtA-0001nO-BX for emacs-orgmode@gnu.org; Wed, 04 Sep 2024 15:42:01 -0400 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 1slvt8-00058B-3r for emacs-orgmode@gnu.org; Wed, 04 Sep 2024 15:42:00 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 1D435240103 for ; Wed, 4 Sep 2024 21:41:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1725478911; bh=eKsoF/eZJ9pzOjE1kdEhXM2huvoldreLcSzrecB1tiE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=i/QFmxFK31AE9/4ej/jtkTH9b9ZBgCcMr/ueOJXqhLJNxpiuRwL0Wv428wveUk1PJ YGQGoaagp9lAFUPfUT0pNEguLD+k7+UOi8R8WiN/EHzVYUm/oJG/KrgtfL6xM0d+/R gI4l5GI1SH8LYEfkrl7AD2jyGwcjs5VoQtcXpI/0ZB8YMZHTz599oEPQWA/McmOxww 8JkPaLF9Huyz6AEx8VIgfMCOHYu6ABXnr+yJ/1/yOp1AhKbIuseg+g3pFJ4cn0f/7D sZ9midPPjzgC9rXQ6ErzopvqI2gybq+pxWAjHU+3F3AFvRetNbAhqcIZq4iF/cGj+B x5KAgcnGer+hw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4WzXtk5HRNz6twx; Wed, 4 Sep 2024 21:41:50 +0200 (CEST) From: Ihor Radchenko To: Antonio Romano Cc: emacs-orgmode@gnu.org Subject: Re: Should "org-element-parse-buffer" check whether the buffer's major mode is org mode? In-Reply-To: <1b2b8c2791e628f6a41ef533e49a5ac9e3dee8a4.camel@pm.me> References: <1b2b8c2791e628f6a41ef533e49a5ac9e3dee8a4.camel@pm.me> Date: Wed, 04 Sep 2024 19:43:17 +0000 Message-ID: <87r09zkxwq.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_H3=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-Queue-Id: 834E8706CD X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -8.70 X-Spam-Score: -8.70 X-TUID: cVqoaLRd2dM3 Antonio Romano writes: > What I did was simply parse out a buffer, change all headlines's TODO > keyword in its AST to "DONE", interpret the resulting AST and finally > print out the resulting document to a new buffer. The issue I had > encountered was that an headline like "* TODO Hello" would wrongly > become "* DONE TODO Hello" instead of "* DONE Hello". That might happen, yes. The behavior in non-Org buffers is currently undefined. Sometimes, you may also get errors. > A kind user pointed out that the issue was that I called "org-element- > parse-buffer" in a fundamental-mode buffer and, in fact, turning on > org-mode beforehand solved the issue. As the user suggested, I'm here > to ask you if this is the intended behavior or if it would be better > limiting the usage of the function to org-mode (and derived) buffers > only. Thank you in advance. If you look into the docstring, it says ... This function assumes that current major mode is `org-mode'. Should we complain when current buffer is not in Org mode? It is not easy to answer. In Org 9.7 (before the release), we modified `org-element-at-point' to do exactly this - complain when current major mode is not Org mode. Soon, a number of people reported that `org-element-at-point' is, in fact, misused by a number of packages and does get called in non-Org buffers. At the end, I had to change `org-element-at-point' to throw a warning rather than an error as some packages simply _rely_ upon such misuse. The current tentative plan for this is the following: 1. Slowly update the parser so that using it in non-Org buffers becomes less unreliable. (It mostly involves computing some variables that Org mode normally initializes dynamically) 2. Allow the parser to be used on arbitrary text. So, you should be able to use `org-element-parse-buffer' in non-Org buffers in the long run. For now, a note in the docstring is what we have. I may also add a warning, but I am not sure - a number of people are confused enough by the warning from `org-element-at-point' (caused by packages abusing it in non-Org buffers); to the point that I am thinking to remove it as well. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at