From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:1008:1e59::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id 6E1dJnQ/fmUFrwAAkFu2QA (envelope-from ) for ; Sun, 17 Dec 2023 01:23:16 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id CGUiIHQ/fmX9RQEA62LTzQ (envelope-from ) for ; Sun, 17 Dec 2023 01:23:16 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.de header.s=2017 header.b=RBZfSJN+; 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.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1702772596; 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:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=fFv9jw/N2khy0jFmuARXq3KH+vGv1Va2EbU76FePRXY=; b=LS/jBQj/bwf6VsL2LbPnh8NlelkJR9zFt4DoVLvAaU5d+TUXVrnZCWs1rGO2z4erQxzkXs KnMQms2piqIKVubgvISeBPbUvS+LIXFy2Wq6jYgksaLDATBXGJsoUS9a7VFkHKyhLPHfES 7YTeygMhc1c8soYMAReEXNc/aMstnWlrOm/IckKLEF9rv33iaNhK9PI+YhH+S33fSzTV/3 GosrSzs0b25vpJqfac3dXusxJPww7jJJ5CVuQb8l9+6tlrCb3LgSeg5OI8t/H+jgxNgPRI oqB3nNioaZj2O/sedDKmEStcoyvTtdVKdnfalUqfFbaXLBrxIzy2qX4pYFWhrA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1702772596; a=rsa-sha256; cv=none; b=Bz2d6NPU0IkODrbFejYbJG+R3EMJDbVnArNngVQ1QSVpAe8Eu2rzUCEGPe+wYrmKLuTd22 BWxPmaJJakswWMEENH5CruKWwwNu71wPDWnhCizu7ZUz49BomjgEE7fYBDlMtZJk2v3U+J G0iL0XIKRU7rFXeashPmXbRhJy/ZOz0yPw53YmywF2FnnRRZLVfyVq2mB9XobLj7XeDbhP kv9+7OCtOMcmpPA+lNnB+FKTVkWwhB+GQsLc+BaFivtBN/F8RD/99XVg7Xd0muZfTsR7Fb 7SkUL1Bdg8Ajr2uWzIXCdM+dELh00tl+T621FB/IUeJpd50FAZJO8vYDlckHew== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.de header.s=2017 header.b=RBZfSJN+; 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.de 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 D3FF7100C8 for ; Sun, 17 Dec 2023 01:23:15 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rEevQ-0007OA-L2; Sat, 16 Dec 2023 19:22:32 -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 1rEevP-0007O1-1Z for emacs-orgmode@gnu.org; Sat, 16 Dec 2023 19:22:31 -0500 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rEevL-0002R4-NI for emacs-orgmode@gnu.org; Sat, 16 Dec 2023 19:22:30 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id D5017240027 for ; Sun, 17 Dec 2023 01:22:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1702772542; bh=5x7bbiH+KFJbpTQzUl3LJL3dzjC5gUEPVI0YofCzYUY=; h=Message-ID:Date:MIME-Version:To:From:Subject:From; b=RBZfSJN+gInzmkPecVlqP7EjgDsNGxHeDmzNhY8arVdFhh8/OSy0udWK1n5Gw4PAm OjpSSUtWoWCR/IkJ/ZK7H1HvnHYplzqYRnuHGnKJe9Vderu7qmWYWhtPRZVand/VxE KwYBdiIX60vdUneUPslIpsXW3SzSJo+tmIsOOoi4eFOgLi6Ubom9tKi0ZL3OP8Jf4A dSJjwC9wugsvmfOhBaDM7C35jjn/fYmCxLiUqaX1xvB9ukzeMA5aYXPQNdNI2x0lPo QH+x0hzqpDcch+gHrlyIsyZU73OHzT0tOxWv2Zcha30tpq78N9VM/M1P8UoojaRp/5 TKBUqEygOLpHg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4St3Yp16wwz9rxF for ; Sun, 17 Dec 2023 01:22:21 +0100 (CET) Content-Type: multipart/alternative; boundary="------------k4wmMwcm0uWzWWHIreAbrdTK" Message-ID: <8d637a8a-6cbc-4158-bded-f9182716a1fc@posteo.de> Date: Sun, 17 Dec 2023 00:22:21 +0000 MIME-Version: 1.0 To: emacs-orgmode@gnu.org From: Zelphir Kaltstahl Content-Language: en-US Subject: Bug in sorting headings according to priority Received-SPF: pass client-ip=185.67.36.65; envelope-from=zelphirkaltstahl@posteo.de; helo=mout01.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=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: -10.95 X-Spam-Score: -10.95 X-Migadu-Queue-Id: D3FF7100C8 X-Migadu-Scanner: mx12.migadu.com X-TUID: eEqIsHmU1lex This is a multi-part message in MIME format. --------------k4wmMwcm0uWzWWHIreAbrdTK Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello Org-mode users! I have observed a mini bug over some time now: When I sort headings in org mode according to their priority (C-c ^ p), sometimes the last heading (lowest priority) will not get its own line, but will be put in one line with the second last heading, making it no longer a separate heading, but part of the second last actual heading. This behavior depends on how one marks/selects/highlights the headings to be sorted. If one highlights the headings from top to bottom, moving the point to the next line after the last heading that shall be sorted, then it works without merging the last heading and the second last. However, if one does not move the point to the next line, then the described behavior occurs. I have the suspicion, that this is about each heading being defined as consisting also of a final newline character and since one does not select that as well by moving the point past it, org mode does not consider the last heading to be a separate heading, but instead thinks it is part of the second last heading. Or perhaps, that it only considers selected text to be sorted, not headings that continue after selected text and therefore forgets to include a newline for the last heading and if that heading moves around without the newline, another heading will be joined on to it on the same line, if any heading comes afterwards in the sorted result. When one highlights from bottom to top (so the other way around!) the same thing happens. If one started highlighting on the line below the last heading, then the sorting works without merging the last two lines. However, if one starts highlighting on the last heading line, then again org mode puts the last heading on the line of the second last heading. Of course this is quite annoying, when one sorts a lot, and one has to always be careful how one selects the headings. Note also, that this only happens, when org mode sorting actually would change the order of headings. If the headings are already sorted, then this does not happen. Here is an example document: ~~~~ * 1 ** [#A] 2.1 ** [#C] 2.2 ** [#B] 2.3 ~~~~ In this document move the cursor: ~~~~ * 1 ** [#A] 2.1 ** [#C] 2.2 ** [#B] 2.3 ^ `--- cursor here ~~~~ Then select until the start of the first level 2 heading, so that all level 2 headings are selected. Then run `org-sort' or press `C-c ^' and then `p'. The result is: ~~~~ * 1 ** [#A] 2.1 ** [#B] 2.3** [#C] 2.2 ~~~~ Instead of: ~~~~ * 1 ** [#A] 2.1 ** [#B] 2.3 ** [#C] 2.2 ~~~~ This also happens, when I try it in an Emacs started with `emacs -Q'. In my opinions org-sort should sort without merging headings. It should probably consider all text until the end of even a partially selected/highlighted heading including the final newline character to avoid this. * Emacs version: GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.37, cairo version 1.16.0) * org-mode version: 9.6.7 Please let me know, in case more details are required and how to get them. Best regards, Zelphir -- repositories:https://notabug.org/ZelphirKaltstahl --------------k4wmMwcm0uWzWWHIreAbrdTK Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Hello Org-mode users!

I have observed a mini bug over some time now:

When I sort headings in org mode according to their priority (C-c ^ p), sometimes the last heading (lowest priority) will not get its own line, but will be put in one line with the second last heading, making it no longer a separate heading, but part of the second last actual heading.

This behavior depends on how one marks/selects/highlights the headings to be sorted. If one highlights the headings from top to bottom, moving the point to the next line after the last heading that shall be sorted, then it works without merging the last heading and the second last. However, if one does not move the point to the next line, then the described behavior occurs.

I have the suspicion, that this is about each heading being defined as consisting also of a final newline character and since one does not select that as well by moving the point past it, org mode does not consider the last heading to be a separate heading, but instead thinks it is part of the second last heading. Or perhaps, that it only considers selected text to be sorted, not headings that continue after selected text and therefore forgets to include a newline for the last heading and if that heading moves around without the newline, another heading will be joined on to it on the same line, if any heading comes afterwards in the sorted result.

When one highlights from bottom to top (so the other way around!) the same thing happens. If one started highlighting on the line below the last heading, then the sorting works without merging the last two lines. However, if one starts highlighting on the last heading line, then again org mode puts the last heading on the line of the second last heading.

Of course this is quite annoying, when one sorts a lot, and one has to always be careful how one selects the headings.

Note also, that this only happens, when org mode sorting actually would change the order of headings. If the headings are already sorted, then this does not happen.

Here is an example document:

~~~~
* 1
** [#A] 2.1
** [#C] 2.2
** [#B] 2.3
~~~~

In this document move the cursor:

~~~~
* 1
** [#A] 2.1
** [#C] 2.2
** [#B] 2.3
           ^
           `--- cursor here
~~~~

Then select until the start of the first level 2 heading, so that all level 2 headings are selected.

Then run `org-sort' or press `C-c ^' and then `p'.

The result is:

~~~~
* 1
** [#A] 2.1
** [#B] 2.3** [#C] 2.2
~~~~

Instead of:

~~~~
* 1
** [#A] 2.1
** [#B] 2.3
** [#C] 2.2
~~~~

This also happens, when I try it in an Emacs started with `emacs -Q'.

In my opinions org-sort should sort without merging headings. It should probably consider all text until the end of even a partially selected/highlighted heading including the final newline character to avoid this.

  • Emacs version: GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.37, cairo version 1.16.0)
  • org-mode version: 9.6.7

Please let me know, in case more details are required and how to get them.

Best regards,
Zelphir

-- 
repositories: https://notabug.org/ZelphirKaltstahl
--------------k4wmMwcm0uWzWWHIreAbrdTK--