Hello,
I'm using emacs from commit f258f67 (quite recent) and org from commit
39005dc (quite recent).
I'm using native compilation and PGTK.
I was able to reproduce this with 'emacs -Q'
When trying to update a clocktable I get the following backtrace (with a
little bit removed).
Debugger enter
Ihor Radchenko writes:
> org-encode-time is defined in org-macs.el in the latest Org, but _not_
> in built-in Org. What you are seeing is most likely caused by "mixed"
> installation of Org when part of Org is loaded from built-in Org
> distribution coming from Emacs.
I was actually seeing htt
bout the second patch
though shouldn't stop the first one from being applied.
>From cc16dd6a8c59312a75b8e25669a7e4eb3d9f9ef4 Mon Sep 17 00:00:00 2001
From: Morgan Smith
Date: Tue, 11 Oct 2022 11:44:26 -0400
Subject: [PATCH 1/2] lisp/org-habit.el: Use time as a history cutoff point
* lisp/
Hello,
Colin Baxter writes:
> Please do not alter the default behaviour. When writing a paper or a
> book I use and need both logging and state changes, and I would prefer
> not to have to spend time changing my setup.
Don't worry, this shouldn't change the default behavior in the
slightest.
Ihor Radchenko writes:
>
> I am not against such feature. However, using clocking will break an
> assumption that a single log record corresponds to a single habit
> completion. This assumption is implied across org-habit code.
>
Oh that's a good point. I'll have to go back through the code and
* testing/lisp/test-org-agenda.el (test-org-agenda/skip-if): New test.
(test-org-agenda/non-scheduled-re-matces): Fix typo by changing name
to 'test-org-agenda/non-scheduled-re-matches'.
---
testing/lisp/test-org-agenda.el | 62 -
1 file changed, 61 insertions(+), 1
* testing/lisp/test-org-agenda.el
(test-org-agenda/check-for-timestamp-as-reason-to-ignore-todo-item):
New test.
---
testing/lisp/test-org-agenda.el | 56 +
1 file changed, 56 insertions(+)
diff --git a/testing/lisp/test-org-agenda.el b/testing/lisp/test-org-agenda
Previously, when trying to run the tests in a container limited to the
org repository, it fails because it can't create the directory
"~/.emacs.d/.org-id-locations".
* testing/org-test.el (org-test-load): Move setting
'org-id-locations-file' from here ...
org-test-update-id-locations: ... to here
* lisp/org-clock.el(org-clock-sum): Rewrite function using
'org-element-map' to traverse the file instead of searching.
---
Hello!
I have a very big file with lots of clock entries and refreshing my clocktable
has become slow. Using '(benchmark-elapse (org-ctrl-c-ctrl-c))' I saw that it
took 5.6
* lisp/org/org-compat.el: Add definition of 'org-imenu-flatten'.
(org-imenu-get-tree): Use 'org-imenu-flatten'.
---
Hello!
I've been using this patch for a bit and I quite like it. One would think
there would be an option in imenu itself to flatten trees but that does not
seem to be the case. I
Ihor Radchenko writes:
>
> Have you considered adding a "flatten" option to imenu itself?
> That way, you could automatically get the functionality for free
> everywhere, not just in Org mode.
I have considered that but gave up with minimal investigation because it
seemed harder then this soluti
lisp/org-agenda.el (org-agenda-goto-date): Check agenda type earlier.
Also remove redundant error.
When this function is run on a todo agenda the user is given the
undescriptive error "(wrong-type-argument listp "todo")" because we
attempt to parse the 'org-last-args text-property prematurely. Wi
doc/org-manual.org: 'org-hierarchical-checkbox-statistics' ->
'org-checkbox-hierarchical-statistics'
---
doc/org-manual.org | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index a5cd9735e..8d74fa332 100644
--- a/doc/org-manual.org
+++
lisp/org-agenda.el (org-agenda-get-scheduled): Consolidate deadline
fetching code. Don't check if deadline is shown when
'org-agenda-skip-scheduled-if-deadline-is-shown' has a value of
'repeated-after-deadline'.
Currently when 'org-agenda-skip-scheduled-if-deadline-is-shown' has a
value of 'repea
Ihor Radchenko writes:
> Morgan Smith writes:
>
>> lisp/org-agenda.el (org-agenda-get-scheduled): Consolidate deadline
>> fetching code. Don't check if deadline is shown when
>> 'org-agenda-skip-scheduled-if-deadline-is-shown' has a value of
>> &#
Ihor Radchenko writes:
> Morgan Smith writes:
>
>>> May you please provide a detailed reproducer demonstrating the bug you
>>> are trying to fix? Such reproducer could be a basis of a new test.
>>
>> See a detailed reproducer attached to this mai
Ihor Radchenko writes:
> But then `org-agenda-skip-scheduled-if-deadline-is-shown' does not look
> like the right place for this customization. It would make more sense to
> have a dedicated custom variable for this. WDYT?
>
> I am adding Bastien to the loop - he authored the original feature
> i
Ihor Radchenko writes:
> Morgan Smith writes:
>
>> Ihor Radchenko writes:
>>
>>> But then `org-agenda-skip-scheduled-if-deadline-is-shown' does not look
>>> like the right place for this customization. It would make more sense to
>>> have a ded
* lisp/org-capture.el (org-capture-get-indirect-buffer): Simplify by
using 'generate-new-buffer-name'.
---
lisp/org-capture.el | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 8ce11cb75..5d9ae4947 100644
--- a/lisp/org-capture.
* doc/org-manual.org (Plot options): Document "timeind". Also fix the
formatting for a couple other entries.
---
doc/org-manual.org | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index ad5c85e2a..69c760c8b 100644
--- a/doc
* lisp/org-element.el (org-element-timestamp-parser,
org-element-timestamp-interpreter): Add support for repeater
deadlines. Adds two new properties: ':repeater-deadline-value' and
':repeater-deadline-unit'.
* testing/lisp/test-org-element.el (test-org-element/timestamp-parser,
test-org-element/t
ne-value/unit would be more readable as the variable name.
Done
>From b285023ca107f7c0fc8b89f7f636cf96bd217207 Mon Sep 17 00:00:00 2001
From: Morgan Smith
Date: Thu, 4 Apr 2024 16:49:31 -0400
Subject: [PATCH] Document repeater deadline syntax and element api
* dev/org-element-api.org (Times
I'll start switching org-habit over to the
element API soon. I've already played with that a bit
>From 582d4e7372c005f098f213b496de6f85c0c11d2f Mon Sep 17 00:00:00 2001
From: Morgan Smith
Date: Wed, 3 Apr 2024 16:30:42 -0400
Subject: [PATCH] lisp/org-element.el: Add repeater-deadline support to
actually
change the regex.
>From 3c3d7abed25cafb2be1096ca079a0e8be907c644 Mon Sep 17 00:00:00 2001
From: Morgan Smith
Date: Thu, 11 Apr 2024 12:23:21 -0400
Subject: [PATCH 1/2] lisp/org-clock.el (org-clock-sum): Rewrite regex using rx
---
lisp/org-clock.el | 20 +---
1 f
Ihor Radchenko writes:
>> * testing/lisp/test-org-clock.el (test-org-clock/clocktable/insert):
>> Add a clock time that does not include timestamps.
>> ...
>> -
>> - (goto-line 2)
>> + (insert (org-test-clock-create-clock ". 1:00" ". 2:00")
>> + "CLOCK: => 1:00\n")
>
> This
Ihor Radchenko writes:
> So, in the message I linked, Nicolas (the major Org mode contributor)
> was not right. I hence need to fix the parser and update Org syntax
> page. This includes fixing `org-element-clock-line-re' to account for
> CLOCK: => 1:00 syntax.
Cool. I guess ping this thread wh
not showing up.
>From 9deff2111b73bb2ceb9127db5d88486affa04f0b Mon Sep 17 00:00:00 2001
From: Morgan Smith
Date: Thu, 18 Apr 2024 09:18:51 -0400
Subject: [PATCH] failing test
---
testing/lisp/test-org-element.el | 13 +
1 file changed, 13 insertions(+)
diff --git a/testing/lisp/tes
So I found another bug in `org-element-cache-map'.
Executing the following code just freezes up. I am struggling to work
through the logic of `org-element-cache-map'. If no-one else magically
solves my issues, I'll figure it out eventually. But I would appreciate
some advice on how to debug thi
r when
> there are changes in buffer while `org-element-cache-map' is mapping
> over it).
See attached for a way to break :from-pos as well. I would like to help
refactor but studying this function is a little dizzying for me.
>From eb37560b9c94bed6e91d6834462173d0a6d7d44b Mon S
2 | 5000 | 33.944309156 |
| mine| 2 | 5000 | 19.84887913 |
>From bfc01710186be01aab2186762cf678d360c5476e Mon Sep 17 00:00:00 2001
From: Morgan Smith
Date: Thu, 11 Apr 2024 12:23:21 -0400
Subject: [PATCH] lisp/org-clock.el (org-clock-sum): Re
This should result in a nice performance boost when the function is
called repeatedly (as is often done).
* lisp/org.el (org-make-tags-matcher): Evaluate returned function to
compile it into a closure.
---
Hello!
All tests pass.
I don't have any rigorous benchmarks but this does make things sig
* lisp/org.el (org-cached-entry-get): Rewrite in terms
`org-entry-get'. Obsolete in favor of `org-entry-get'.
(org-make-tags-matcher): Replace uses of `org-cached-entry-get' with
`org-entry-get'.
---
Hello!
All tests pass.
I don't think we can justify the existence of this function but let me kn
Ihor Radchenko writes:
>
>
> This function should yield speedups when matching special properties
> like "CLOCKSUM", "CLOCKSUM_T", "TIMESTAMP", or "TIMESTAMP_IA".
>
> For example, when the requested match tests these properties multiple
> times.
>
> We need a real-life justification, not a theore
here again just so you can see my slowdown
is only between 1.5x and 3x.
org-cached-entry-get
1st run: 26.868990287
2nd run: 16.043983143
org-entry-get
1st run: 18.209056578
2nd run: 5.003186764
>From 5d9cef1250ef1eb656b84d3168ebfecb0e9c9c5c Mon Sep 17 00:00:00 2001
From: Morgan Smith
Date: We
Ihor Radchenko writes:
> Morgan Smith writes:
>>> Also, with the old approach, if you observe slowdowns, you likely have
>>> some property being calculated slowly (like BLOCKED in my case). Do you
>>> happen to know which property is it for your setup?
>>
Hello!
I'm currently running org from commit
'773bba92a8e2b927427cf1daf374fa774fe834e0' (+ my own modifications).
I was reading the manual `8.4.2 The clock table' when I got down to the
`:block' section I noticed it was way too wide. Like this wide:
‘:block’
The time block to cons
* etc/ORG-NEWS: Fix typos.
* testing/lisp/test-org-agenda.el: Fix typos.
---
Hello!
I was reading through the news and found this entry a little confusing. Also
the variable names wheren't quite right.
Thanks,
Morgan
etc/ORG-NEWS| 13 +
testing/lisp/test-org-a
With a file like this:
* headline 1
** headline 2
We currently produce an imenu tree that looks like this:
'(("headline 1" ("headline 2" . marker-2)))
imenu has no clue where "headline 1" is located and thus the user
can't navigate to it. With this patch installed imenu knows where
non-leaf he
Samuel Wales writes:
> how does imenu compare against completion systems like ido combined with org
> refile set to goto? when would you use imenu vs. other completion?
For my specific use case, all I want is a simple minibuffer completion
that offers me all the headings in the current buffer a
Ihor Radchenko writes:
> Morgan Smith writes:
>
>> Quirks:
>>
>> With the default `imenu-flatten' value of nil, it is still impossible
>> to visit non-leaf headlines and no change is perceived.
>
> But no regressions, right? Especially in older Emac
* lisp/org.el (org-tags-sort-hierarchy): New function.
(org-tags-sort-function): Add new function to type.
* testing/lisp/test-org.el (test-org/tags-sort-hierarchy): New test
---
This is one of those things that I thought would be easy but then ended up
hard.
I wrote this so that items in my agen
* testing/lisp/test-org-agenda.el (test-org-agenda/tags-sorting): New
test.
---
Hello!
I just recently sent in a patch to add a new possible value for
`org-tags-sort-function'. To ease discussion there, I thought I'd add a nice
little test here so I can later show off the feature I'm trying to a
nd
2012 :month-end 1 :day-end 1 :hour-end 0 :minute-end 2))
:duration "0:01"))
>From d407b357ba4285acc3c2548e38f034b5665b40bb Mon Sep 17 00:00:00 2001
From: Morgan Smith
Date: Thu, 11 Apr 2024 12:23:21 -0400
Subject: [PATCH 1/2] lisp/org-clock.el (org-clock-sum): Rewrite using e
* doc/org-manual.org: Add missing '~'.
* lisp/org-element-ast.el (org-element-deferred): Fix typo in docstring.
* lisp/org-element.el (org-element-archive-tag,
org-element-drawer-re-nogroup, org-element--cache-log-message): Fix
typos in docstring.
(org-element--current-element, org-element--cache-f
Ihor Radchenko writes:
>> Ideally the fix in that commit should be ported to the org-element API.
>> Notably, the malformed clock from the email thread from that commit is
>> parsed a little strangely by org-element. I'm not sure what effect this
>> has on my rewrite patch but regardless, we sho
Ihor Radchenko writes:
> Morgan Smith writes:
>
>>> That's expected.
>>> We have the following _syntax_ description for clock lines:
>>>
>>> https://orgmode.org/worg/org-syntax.html#Clocks...>> clock:
>>> INACTIVE-TIMESTAMP-RANGE D
Ihor Radchenko writes:
> Ihor Radchenko writes:
>
>> ... may you please elaborate what kind of sorting
>> order does your function imply? ...
>
> It has been over a month. Have you had a chance to look into my
> questions?
After you asked that question, I decided to demonstrate the changes I
wa
ategy' so I'm going to
refrain from trying to document things I don't understand.
>> + ((or 'nil 'org-string<)
>> +
>> "group_a\ngroupless\nlonely\ntag_a_1\ntag_a_2\ntag_b_1\ntag_b_2\n")
>> + ('org-stri
* lisp/org-goto.el: Don't conditionally define keys based on if
`isearch-other-control-char' is bound.
Org mode only supports Emacs 27 and later.
---
lisp/org-goto.el | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/lisp/org-goto.el b/lisp/org-goto.el
index f75cc9ed
Hello!
Morgan Smith writes:
> Ihor Radchenko writes:
>>> + ;; TODO: a value of `nil' sorts it! That's not what the
>>> + ;; defcustom :type of `org-tags-sort-function' says! It
>>> + ;; says "No sorting&q
Hello!
I have updated the patch with many improvements and tests.
Ihor Radchenko writes:
> Morgan Smith writes:
>
>> * lisp/org.el (org-tags-sort-hierarchy): New function.
>> (org-tags-sort-function): Add new function to type.
>> * testing/lisp/test-org.el (test-org/t
Ihor Radchenko writes:
> Ihor Radchenko writes:
>
>>> Fallback to `org-sort-function'.
>>
>> I am not sure if it is the best idea to hard-code using
>> `org-sort-function' here.
>>
>> What if a user wants specific `org-sort-function' for, say, table
>> sorting, but something else for tags?
>> Se
Ihor Radchenko writes:
> Morgan Smith writes:
>
>> However, I believe I have managed to come up with a flexible solution that
>> does
>> involve allowing `org-tags-sort-function' to be a list of functions. The
>> trick
>> is to lexically bind th
Hello,
In commit ffb1652c4ada9595dc74773d3ccd409ec10280a1 Ihor removed the
"jump" submodule located at "testing/jump". However, they did not
remove the ".gitmodules" file that specifies the git module. This is
causing strange errors for me when using guix to build org-mode in its
container like
t looks like (B D F).
The type of sorting I'm trying to do would have the list end up as (B F D)
since F falls under B.
>From 7951ff4639197cd846e292bf30c731846e05c3f2 Mon Sep 17 00:00:00 2001
From: Morgan Smith
Date: Tue, 27 May 2025 15:14:34 -0400
Subject: [PATCH 1/2] Allow `org-tags-sor
My apologies. The previous email reverted too much of my `org-set-tags'
changes. These changes should work now. Please see attached.
Commentary from previous email is still applicable.
>From 7ea6b1bbdf7e3df075f419269c3ebbd5b2578359 Mon Sep 17 00:00:00 2001
From: Morgan Smith
Date:
Ihor Radchenko writes:
> Morgan Smith writes:
>
>> --- a/lisp/org.el
>> +++ b/lisp/org.el
>> @@ -3015,7 +3015,8 @@ org-tags-sort-function
>>(const :tag "Default sorting" nil)
>>(const :tag "Alphabetical" org-string&l
57 matches
Mail list logo
