From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id aHZ5Gyt7nF96JQAA0tVLHw (envelope-from ) for ; Fri, 30 Oct 2020 20:44:27 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id 0M1PFyt7nF/yDQAAbx9fmQ (envelope-from ) for ; Fri, 30 Oct 2020 20:44:27 +0000 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 C4117940237 for ; Fri, 30 Oct 2020 20:44:26 +0000 (UTC) Received: from localhost ([::1]:40546 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kYbG5-0007ND-On for larch@yhetil.org; Fri, 30 Oct 2020 16:44:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56846) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kYbFM-0007Le-PP for emacs-orgmode@gnu.org; Fri, 30 Oct 2020 16:43:40 -0400 Received: from mail-pf1-x429.google.com ([2607:f8b0:4864:20::429]:35873) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kYbFK-0001lI-S7 for emacs-orgmode@gnu.org; Fri, 30 Oct 2020 16:43:40 -0400 Received: by mail-pf1-x429.google.com with SMTP id w65so6338430pfd.3 for ; Fri, 30 Oct 2020 13:43:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hdIWpJhjp8BTcg6oSPhRaEqvZRq0LHYw9UTObvdKhaY=; b=DI1tQPWIjGMq8Wj9fnheXp9fw6OqOuTriEosy1I30KY9M3c3ohRBN6xbhWNVr6Jf21 HcvD+NURDVzWs0sFPUWcPmZyIhcRVER7PmVWvcLm8+UPCjK/qVyOJLQFmEEhoIB0aExi PiNW47GjGoOtvrIGO27Mv+UB8gqF7A3fB17dz92XitDXZtasdsV5nkWmDq28Tec3PCND 1jmlpEmU6rHli+6e3l5+vTUOT78zjAAjQCNdbJyVCgjo/+nyRQNUXbTYP4QkmObw76k2 A+brarTEFbRjT7A7TWKP1GkRbIXcuVGGjG01YJpaqFiBl4m5iHMcP2Nm6og/MMydPEMI IuQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hdIWpJhjp8BTcg6oSPhRaEqvZRq0LHYw9UTObvdKhaY=; b=o2YSR8MQwcWB6ldlTIt1r3DTDJ997dzOcFXOC09Hg4ZORQEM0L7Xyc/h/oSlQ3Paqq KaPH4jjbL+2UrA3bzhlyYN2DDPQSKoHvP1rv+vKPDRlueFWzDTWTtKZ3OZutNt/tszSl Vt7VWAhxUxJaxxBSKSrf9M48QP2o/nbThtNRcQFj8Dc6geap0mWp10Xl6jY+6oBX2AhK uVsptLR5nzUbNFSqhbXZKp/KTKrsDNbFSRvAQNcdCCAh/oUNFtgDu5WK2pFtYa+LVvOn +RxQygMtyNSq+pYyatVBdhHHVJx1eZskhg59JbS8hYLVKxMJCUbWTOvXcugGChALiZys zYDg== X-Gm-Message-State: AOAM531hC5E7AVbBX2hMI1/HKzeMETf5KqoKFaaenxupsuHgMzCoMniN ouenF2iALxezGMaMhcEYdeB4nRoGtog+EKsvUB0= X-Google-Smtp-Source: ABdhPJzfXIVpZkcyYYrdj9J6GiaXTUmnjDjpKwa4+TSRimDo/CWG6BwOQPpTHvhAlKQ40QiLLfIgn8g9/onSUplKtmI= X-Received: by 2002:a63:2051:: with SMTP id r17mr3616816pgm.191.1604090616918; Fri, 30 Oct 2020 13:43:36 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a05:6a10:c64b:0:0:0:0 with HTTP; Fri, 30 Oct 2020 13:43:36 -0700 (PDT) In-Reply-To: <87pn4zbvqy.fsf@gmail.com> References: <87pn4zbvqy.fsf@gmail.com> From: Samuel Wales Date: Fri, 30 Oct 2020 13:43:36 -0700 Message-ID: Subject: Re: org-sort-entries sorting by top-level with first entry at bob To: Gustavo Barros Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2607:f8b0:4864:20::429; envelope-from=samologist@gmail.com; helo=mail-pf1-x429.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=DI1tQPWI; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: -1.71 X-TUID: f6gmL8OuSJxk i always have everyting under a top level, so taht files are trees not forests and org can work treeishly even at toplevel. but to not use the mark, typically you supply point-min and point-max to some function. major changes to o-s-r migth not be needed, merely that. On 10/30/20, Gustavo Barros wrote: > Hi All, > > `org-sort-entries' provides no easy way to sort by top-level when the > first entry is at the beginning of buffer. This is true for both > interactive and non-interactive uses of the function, but a little more > inconvenient in the latter case. > > Indeed, `org-sort-entries', when deciding what to sort, first tests for > `org-region-active-p', then `org-at-heading-p' (or if after a heading), > failing those tests, it falls back to top-level sorting. However, if > the first heading is at the beginning of buffer and we want to sort by > top-level, we'll never get to the fall back case, because > `org-at-heading-p' will return non-nil, and the children of the first > entry will be sorted instead. > > Not an ECM, just an use case with the situation at hand. Consider a > buffer with contents: > > #+begin_src org > ,* B Foo > ,** B Baz > ,** A Foo > ,* A Bar > #+end_src > > How to sort by top-level? > > The currently existing alternative is to `mark-whole-buffer', and let > `org-sort-entries' sort by region. While this is reasonable in the > interactive case, it is less so if `org-sort-entries' is being called in > code. Using `mark-whole-buffer' in your code will grant you a nice > compiler warning and pretending you don't use it by doing the same thing > yourself is explicitly advised against in its docstring: "it is usually > a mistake for a Lisp function to use any subroutine that uses or sets > the mark". Behind the scenes, Org is using `use-region-p', which means > the region must not only exist but transient-mark-mode must be on and > the mark must be active. It can be made to work, of course, but it is > clearly less than ideal. Either way, currently the only way to ensure > that sorting is done by top-level when you don't know whether there is > something before the first heading (including possible narrowing) is to > rely on the region case. > > What to do with it is somewhat tricky, though. My first thought was to > test if we are actually looking at a heading regexp, and sort on the > heading's level in this case. But, on second thought, I believe this is > not a good idea, because it will conflict with current and expected > behavior for speed-keys, in particular. Perhaps test if point is at > beginning of buffer, and handle this case specially? > > > Best regards, > Gustavo. > > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html