Re: org-sort-entries sorting by top-level with first entry at bob
yes, you understood my points. if you already understood them and they are not useful to you, then please disregard them. On 10/30/20, Gustavo Barros wrote: > Hi Samuel, > > On Fri, 30 Oct 2020 at 17:43, Samuel Wales wrote: > >> i always have everyting under a top level, so taht files are trees not >> forests and org can work treeishly even at toplevel. > > This would be a workaround, not a solution. Is it a formal requirement > of Org that files must be kept in this form? > >> but to not use >> the mark, typically you supply point-min and point-max to some >> function. > > `org-sort-entries' does not take beg/end as arguments, it uses the > active region, as reported. > > Regards, > Gustavo. > > > > > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: org-sort-entries sorting by top-level with first entry at bob
Hi Samuel, On Fri, 30 Oct 2020 at 17:43, Samuel Wales wrote: i always have everyting under a top level, so taht files are trees not forests and org can work treeishly even at toplevel. This would be a workaround, not a solution. Is it a formal requirement of Org that files must be kept in this form? but to not use the mark, typically you supply point-min and point-max to some function. `org-sort-entries' does not take beg/end as arguments, it uses the active region, as reported. Regards, Gustavo.
Re: org-sort-entries sorting by top-level with first entry at bob
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
org-sort-entries sorting by top-level with first entry at bob
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.
