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
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?
>>
e 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: Wed, 1 May 2024 12:36:40 -0400
S
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
* 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
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
| 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): Rewrite using element api
---
lisp/org-clock.el |
can encounter 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 Sep 17
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
t;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/test-org-element.el b/t
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
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")
>
>
m 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 file changed, 17 insertions(+), 3 de
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
org-element
* lisp/org-element.el (org-element-timestam
re 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 (Timestamp): Add ':repeater-dea
* 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,
* 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
---
* 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
---
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 dedicate
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
>
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
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
>> 'repeated-after-d
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
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-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.
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
* 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.
* 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
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
* 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
* 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(+),
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
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.
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/org-habit.el (org-ha
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
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
36 matches
Mail list logo
