From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:1008:1e59::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id 4LzaMt2jY2bovwAAA41jLg (envelope-from ) for ; Sat, 08 Jun 2024 02:20:45 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id wJ9kLN2jY2bVXwAA62LTzQ (envelope-from ) for ; Sat, 08 Jun 2024 02:20:45 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=ihm.name header.s=uddkim-202310 header.b=P+6vASSy; 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=ihm.name ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1717806045; 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:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=PpP5Lr28rG51h1v9g0LBI1icMm0QpbkoCmaWTrTnPDI=; b=ftv/0okoWaVv0JyzEs110zSbwtqMQXFpE6IH+j/nQy9YdiZpEOdNAkfHPmkU6szWs1T2LN zY3rjAsYXGHAa/2ZBIhqWxXLoN0NcqIk4wT5w6XRiuFnUOsVvUuxElRNcpanKDfjrYrzhb SfC8N6RAQfMuJvk6zQtDgMSASqOc2RPLU493v0ars+39riZUsxD8yYSQok+8cfjFfPLM94 WEYU7XWSGWdoUqOKZ1XT8ZLBVXQR7Zd7PxJMmw5U8WN3w+L4O/w6+ppaRkv6StN9vRAwi8 chCwpgXCSl3YihfkHAmzXKii/i2Q2zcK8ja7IYHMYr6+Fbr2ZUfuOFrqFWzWZQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=ihm.name header.s=uddkim-202310 header.b=P+6vASSy; 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=ihm.name ARC-Seal: i=1; s=key1; d=yhetil.org; t=1717806045; a=rsa-sha256; cv=none; b=IQMH+KzIxDd6rJqGuNzWHOATumg3tvskbwG6gcH1WMbVbsCo4ktGn1sPqoY7dqmUx1eMe8 ELxnlSXmXrBILG38KnEvP8u2ZzzFhJN8tiKwhVz1irC2zAoPAZ1ZuttbLg+gn1QM7ma20C seF43CC7jJ63NHsHgxWPf66FSB2tQKrfuvj+gaTc8IJFCnvLzDdE+IdTYrcG1ktjv91Woj kBg1aNFCPFcbSkgTcuR7Uo1iJKAt2EweoXFu7WuEWkq7gqYrIn/4R8jXFsz/f8BP4OgvLC rVsJHZicKeK8FvhJ13EaCiROPoFQrE80AU+e1ORS2gkWpGblJyQb1bebXBdDlA== 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 4200E71753 for ; Sat, 8 Jun 2024 02:20:45 +0200 (CEST) Received: from [::1] (helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sFbC2-0002Se-No; Fri, 07 Jun 2024 11:07:50 -0400 Received: from [2001:470:142:3::10] (helo=eggs.gnu.org) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sFbC0-0002SQ-03 for emacs-orgmode@gnu.org; Fri, 07 Jun 2024 11:07:48 -0400 Received: from smtp03-ext2.udag.de ([62.146.106.30]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sFbBx-00014N-VL for emacs-orgmode@gnu.org; Fri, 07 Jun 2024 11:07:47 -0400 Received: from ox-api-1.vpn.udag.de (unknown [89.31.141.171]) by smtp03-ext2.udag.de (Postfix) with ESMTPA id 2FFE3E0138 for ; Fri, 7 Jun 2024 17:07:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihm.name; s=uddkim-202310; t=1717772862; h=from:from: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; bh=PpP5Lr28rG51h1v9g0LBI1icMm0QpbkoCmaWTrTnPDI=; b=P+6vASSyLffLayhnv1HlS4ieSh99An8x7B7z41lyBzwcodRldGE3DIRM4TO++6MPyJLzDr 7s6qL05CxtVpnA5yqoI9t1QEjOVuO0mZBmWsBzZUB2KsIpISTtZOBTUUzozWZU95zBOUpY XH/+NFgWYofoEuJoeCQvfPrVuqPjiroMLcVEZ/Bay6aQCoW1QslrPI9tg5w6nkVgQkulvu hMYiuAsPK3EeQnSkonkOJJ+xnM92e+QRmpCphetuYE4oye8ITLXhae5ZxZyO6N0zxCABWg qv+fbxDDzmdwUTgUVHtvfimvQYEFh/eiM+e9z/2A2T2qBllv4LgJghtz7TyHAA== Date: Fri, 7 Jun 2024 17:07:41 +0200 (CEST) From: Marc-Oliver Ihm To: "emacs-orgmode@gnu.org" Message-ID: <677194399.53008.1717772861672@ud-mail.de> Subject: [PATCH] Fixing endless loop of org-reveal with inline-task MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.6-Rev53 X-Originating-Client: open-xchange-appsuite Received-SPF: pass client-ip=62.146.106.30; envelope-from=marc@ihm.name; helo=smtp03-ext2.udag.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-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-Country: US X-Migadu-Flow: FLOW_IN X-Spam-Score: -7.64 X-Migadu-Queue-Id: 4200E71753 X-Migadu-Scanner: mx10.migadu.com X-Migadu-Spam-Score: -7.64 X-TUID: 4mqRE8vllhpa Hi all, If I have this simple buffer: * foo *************** bar *************** END i.e. one node with a single inline node. If now I place the cursor at the end of the buffer and invoke (org-reveal),= I get stuck in an endless loop. (of course one needs to (require 'org-inlinetask) before) I think this can be fixed by patching org-goto-sibling as shown below (agai= nst HEAD). Could you please consider accepting this patch, as the problem h= its me every few days. Background: In my opinion the current behavior of org-goto-sibling is wrong= if the cursor is at the end of the given example-buffer. In that case curs= or gets placed at the start of the END-line and the return value is t. This= contradicts the documentation, which states "Returns t when a sibling was found. When none is found, return nil and don=E2=80=99t move point." My patch corrects this, so that when invoking org-goto-sibling in this case= , cursor is not moved and return value is nil. I did not notice any negative effects with this patch in the past few weeks= . Thanx a lot Marc Ihm diff --git a/lisp/org.el b/lisp/org.el index cf4c9a99e..c786f7719 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -21530,6 +21530,10 @@ move point." (when (org-element-type-p (org-element-at-point) 'inlinetask) (org-up-heading-safe)) (setq level (funcall outline-level)) + (when (org-inlinetask-at-task-p) + (if previous + (org-inlinetask-goto-beginning) + (org-inlinetask-goto-end))) (catch 'exit (or previous (forward-char 1)) (while (funcall fun re nil t)