Re: An academic journal entirely made in Org-Mode

[Daniel Ortmann]

Yes, please!

--
Daniel Ortmann
https://www.linkedin.com/in/danieldeanortmann/
https://ieee-collabratec.ieee.org/app/p/DanielDeanOrtmann/
612-518-3147 m

On 1/29/24 14:03, Juan Manuel Macías wrote:

Hi,

In last December, issue 23 of the "Revista de Estudios Latinos" (Journal
of Latin Studies) was published, sponsored by the Spanish Society of
Latin Studies. It is designed and produced by me using Org-Mode,
Org-Publish and LuaTeX. If anyone is interested in the code I used for
specific aspects of the publication, I can share it here :-).

Link to the journal in PDF version:

https://recyt.fecyt.es/index.php/rel/issue/view/4327/948

And a screenshot of the making-off:

https://i.imgur.com/lkwIOGA.png

Best regards,

Juan Manuel

Re: [BUG] org agenda showing current time - not task time when closing repeatedly-scheduled task [9.7-pre (release_9.6.10-840-g9fcbd1 @ /home/d/src/git-org-mode/lisp/)]

[Daniel Ortmann]

A bit more clarity ...

 * If the task clock is activated on a TODO in the agenda,
 * and closed quickly enough that the elapsed time is 0:00,
 * then MOMENTARILY the agenda shows the CURRENT WALLCLOCK TIME.
 * The actual logbook entry shows the correct 0:00 elapsed task time.
 * And when the agenda is merely REFRESHED the wallclock time is
   replaced with the 0:00.


So there seems to be NO BUG.  It's just an odd transient behavior which 
I now noticed only because of tracking "time" on some small tasks.


Definitely not worth touching brittle code.  "It's just how it is."

And that's ok!  :-)

Thank you for your attention to this matter which now is clearly smaller 
than expected.


On 10/16/23 02:38, Ihor Radchenko wrote:

Daniel Ortmann  writes:


No, no, not clock check mode.

- I created a TODO with a scheduled time that repeats.  When completed
it remains alive to be scheduled the next day.

- I started the clock on that TODO task.

- Then completed the task with 't' in the Agenda view.

- The task's "clock time" shows in the log ... i.e. how much time I
spent completing that task.

Ok. Got it.


==>> Previously, a day or so ago, the current local time was recorded in
the Agenda log rather than the "clock time" (i.e. rather than the time
spent to complete the task).

==>> Now, the current "clock time" again is correctly recorded in the log.

I looked into the code, and I do have a feeling that it is brittle
(agenda is a very old and convoluted code), but without a concrete
reproducer I wouldn't dare to touch it.


I hope the screen captured images came across in the previous email?
They should help explain.

I indeed did not notice the attachments - they were not indicated in the
plain/text part of the email. They indeed did help to explain things.

Re: [BUG] org agenda showing current time - not task time when closing repeatedly-scheduled task [9.7-pre (release_9.6.10-840-g9fcbd1 @ /home/d/src/git-org-mode/lisp/)]

[Daniel Ortmann]

No, no, not clock check mode.

- I created a TODO with a scheduled time that repeats.  When completed 
it remains alive to be scheduled the next day.


- I started the clock on that TODO task.

- Then completed the task with 't' in the Agenda view.

- The task's "clock time" shows in the log ... i.e. how much time I 
spent completing that task.



==>> Previously, a day or so ago, the current local time was recorded in 
the Agenda log rather than the "clock time" (i.e. rather than the time 
spent to complete the task).


==>> Now, the current "clock time" again is correctly recorded in the log.


I hope the screen captured images came across in the previous email?  
They should help explain.


On 10/15/23 04:00, Ihor Radchenko wrote:

Daniel Ortmann  writes:


In the last entry below, the "Clocked:" part of the log would have
showed 3:47 (i.e. the current local CDT time) rather than the time to
complete the task which is now correctly shown as 0:01 minutes.

Do you mean that you used agenda clockcheck mode? I tried and I see no
problem there.


The problem no longer appears!  Excellent.  Not sure what fixed it.
...
Problem fixed ... but it would be nice to know it was not an accidental fix.

I am not sure what you mean by fixed. Did you do anything?


Thank you!  You can close it or investigate further at your discretion.

I am not able to reproduce the problem. Since you cannot either, I am
closing this bug.

Canceled.

Re: [BUG] org agenda showing current time - not task time when closing repeatedly-scheduled task [9.7-pre (release_9.6.10-840-g9fcbd1 @ /home/d/src/git-org-mode/lisp/)]

[Daniel Ortmann]

Hey,
The problem no longer appears!  Excellent.  Not sure what fixed it.

In the last entry below, the "Clocked:" part of the log would have 
showed 3:47 (i.e. the current local CDT time) rather than the time to 
complete the task which is now correctly shown as 0:01 minutes.


Problem fixed ... but it would be nice to know it was not an accidental fix.

Thank you!  You can close it or investigate further at your discretion.







On 10/15/23 03:39, Ihor Radchenko wrote:

Daniel Ortmann  writes:


I have a repeatedly-scheduled TODO with this entry for the schedule:
SCHEDULED: <2023-10-15 Sun .+1d -0d>

The TODO is marked with 'sometag'.

In the regular agenda view (C-a a) I narrow with /sometag.
Then S-I to start the clock.
Finally, t and C-c C-c to close today's action.

The result is that the agenda shows the current time (in this case
9:41) ...

May you please elaborate about "agenda shows the current time"?

[BUG] org agenda showing current time - not task time when closing repeatedly-scheduled task [9.7-pre (release_9.6.10-840-g9fcbd1 @ /home/d/src/git-org-mode/lisp/)]

[Daniel Ortmann]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See

https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


I have a repeatedly-scheduled TODO with this entry for the schedule:
SCHEDULED: <2023-10-15 Sun .+1d -0d>

The TODO is marked with 'sometag'.

In the regular agenda view (C-a a) I narrow with /sometag.
Then S-I to start the clock.
Finally, t and C-c C-c to close today's action.

The result is that the agenda shows the current time (in this case 9:41)
instead of the correct 6 minutes. Note that the task's LOGBOOK entry
correctly shows 0:06 minutes.

I expected to see the usual 6 minutes for the task in the agenda view.
Today is the first time I noticed this anomaly, but perhaps it has been
happening previously?
Not sure if this is new as of today: [2023-10-14 Sat 09:47] (CDT time)

A sample task:
* TODO sometask with sometag :sometag:
SCHEDULED: <2023-10-15 Sun .+1d -0d>

Emacs : GNU Emacs 30.0.50 (build 40, x86_64-pc-linux-gnu, GTK+ Version 
3.24.37, cairo version 1.16.0)

of 2023-10-14
Package: Org mode version 9.7-pre (release_9.6.10-840-g9fcbd1 @ 
/home/d/src/git-org-mode/lisp/)

--
Daniel Ortmann  612-518-3147 m
key: C9E170E2, fingerprint = 81BB 6CAF F1EC F6C7 690C F4E9 66D7 7AFD 
C9E1 70E2

Re: [BUG] org sub tree sort broken [9.7-pre (release_9.6.10-827-ge15699 @ /home/d/src/git-org-mode/lisp/)]

[Daniel Ortmann]

Fix confirmed.

Thank you!

On 10/12/23 03:21, Ihor Radchenko wrote:

Daniel Ortmann  writes:


org-element--generate-copy-script: Symbol\u2019s function definition is
void: org-export--list-bound-variables

Sorry. Silly mistake in a recent commit.
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f660afc50

[BUG] org sub tree sort broken [9.7-pre (release_9.6.10-827-ge15699 @ /home/d/src/git-org-mode/lisp/)]

[Daniel Ortmann]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See

https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


Create a test-of-org-sort.org file with the following content:
* top
** one
** two
** three

Click mouse-1 on the top heading.

Press C-c ^ a
... to attempt to sort the sub headings alphabetically.

The result is:
Sort children: [a]lpha [n]umeric [p]riority p[r]operty todo[o]rder [f]unc
[t]ime [s]cheduled [d]eadline [c]reated cloc[k]ing
A/N/P/R/O/F/T/S/D/C/K means reversed:
Sorting entries...
org-element--generate-copy-script: Symbol\u2019s function definition is 
void: org-export--list-bound-variables



Emacs : GNU Emacs 30.0.50 (build 37, x86_64-pc-linux-gnu, GTK+ Version 
3.24.37, cairo version 1.16.0)

of 2023-10-11
Package: Org mode version 9.7-pre (release_9.6.10-827-ge15699 @ 
/home/d/src/git-org-mode/lisp/)

--
Daniel Ortmann  612-518-3147 m
key: C9E170E2, fingerprint = 81BB 6CAF F1EC F6C7 690C F4E9 66D7 7AFD 
C9E1 70E2

Re: [External] : Re: [BUG] updating existing org date with time always sets time to 0:00 [9.6.1 (release_9.6.1-262-gd94f40 @ /home/dortmann/src/git-org-mode/lisp/)]

[Daniel Ortmann]

Ihor,

 * In an org buffer, input: [1960-10-16]
 * Set point between the brackets.
 * Press C-c ! and enter.
 * The result is [19_*7*_0-10-16 Fri]
 * I expected [1060-10-16-Sun]

Yes, C-c C-c works.

But C-c ! enter is supposed to use [1960-10-16] as the default date and 
not change that date to 1970.



(Yes, I am replying to the correct thread which corresponds to the bug 
report submitted.)


On 3/22/23 10:10, Ihor Radchenko wrote:

Daniel Ortmann  writes:


Since that existing timestamp at point is supposed to be used as the
default, we definitely have a bug
==>> ... Since that 'default' time is bumped up to 1970.

Clearly, the expected default behavior is not working as expected.
(Times after 1970 are fine.)

May you elaborate? Are you sure that you are replying to the right thread?

Re: [External] : Re: [BUG] updating existing org date with time always sets time to 0:00 [9.6.1 (release_9.6.1-262-gd94f40 @ /home/dortmann/src/git-org-mode/lisp/)]

[Daniel Ortmann]

Since that existing timestamp at point is supposed to be used as the 
default, we definitely have a bug

==>> ... Since that 'default' time is bumped up to 1970.

Clearly, the expected default behavior is not working as expected. 
(Times after 1970 are fine.)


On 2/22/23 04:57, Ihor Radchenko wrote:

Daniel Ortmann  writes:


file org-plain-date-to-date-time.org has:

* plain date
C-c ! gives:
[2023-02-21 Tue]
* updating plain date
C-c ! followed by C-u C-! gives:
[2023-02-21 Tue 00:00]
* date-time
C-u C-c ! gives:
[2023-02-21 Tue 14:13]

I expected that updating an existing date with C-u C-c ! would produce
the same result as creating a new date-time.

When point is at existing timestamp, C-c ! tries to take the time of
that timestamp as default. To force today's date and time, you can use
C-u C-u C-c !

Re: [BUG] incorrect result with C-c ! to correct (complete) a date [9.7-pre (release_9.6.1-306-ga645a6 @ /home/d/src/git-org-mode/lisp/)]

[Daniel Ortmann]

Excellent.  C-c C-c does work.  I will use that in the future. Thank you.

The 'incorrect' behavior with C-c ! remains.

Adjusting [1960-10-16] fails with C-c !

But adjusting [1971-10-16] with C-c ! works fine.

Something to do with the epoch boundary?

On 3/21/23 09:00, Max Nikulin wrote:

On 20/03/2023 08:56, Daniel Ortmann wrote:

Starting with this manually-typed birthday date:
[1960-10-16]
Use the arrows to move to the text.
Now press C-c ! and then ENTER

I expected this result, i.e. I expected the day of the week to be added:
[1960-10-16 Sun]


If all what you need is to add day of week you may try C-c C-c instead 
of C-c !.

[BUG] incorrect result with C-c ! to correct (complete) a date [9.7-pre (release_9.6.1-306-ga645a6 @ /home/d/src/git-org-mode/lisp/)]

[Daniel Ortmann]

--=-=-=
Content-Type: text/plain



Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See

https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


* correct date information
Starting with this manually-typed birthday date:
[1960-10-16]
Use the arrows to move to the text.
Now press C-c ! and then ENTER

I expected this result, i.e. I expected the day of the week to be added:
[1960-10-16 Sun]

But the following incorrect result occurs:
[1970-10-16 Fri]



--=-=-=
Content-Type: text/plain
Content-Disposition: attachment; filename=date-edit-oops.org
Content-Description: date edit oops org file


* correct date information
Starting with this manually-typed birthday date:
[1960-10-16]
Use the arrows to move to the text.
Now press C-c ! and then ENTER

I expected this result, i.e. I expected the day of the week to be added:
[1960-10-16 Sun]

But the following incorrect result occurs:
[1970-10-16 Fri]

--=-=-=
Content-Type: text/plain



Emacs : GNU Emacs 30.0.50 (build 50, x86_64-pc-linux-gnu, GTK+ Version 
3.24.34, cairo version 1.16.0)

of 2023-03-19
Package: Org mode version 9.7-pre (release_9.6.1-306-ga645a6 @ 
/home/d/src/git-org-mode/lisp/)

--
Daniel Ortmann  612-518-3147 m
key: C9E170E2, fingerprint = 81BB 6CAF F1EC F6C7 690C F4E9 66D7 7AFD 
C9E1 70E2


--=-=-=--

* correct date information
Starting with this manually-typed birthday date:
[1960-10-16]
Use the arrows to move to the text.
Now press C-c ! and then ENTER

I expected this result, i.e. I expected the day of the week to be added:
[1960-10-16 Sun]

But the following incorrect result occurs:
[1970-10-16 Fri]

[BUG] updating existing org date with time always sets time to 0:00 [9.6.1 (release_9.6.1-262-gd94f40 @ /home/dortmann/src/git-org-mode/lisp/)]

[Daniel Ortmann]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See

https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


file org-plain-date-to-date-time.org has:

* plain date
C-c ! gives:
[2023-02-21 Tue]
* updating plain date
C-c ! followed by C-u C-! gives:
[2023-02-21 Tue 00:00]
* date-time
C-u C-c ! gives:
[2023-02-21 Tue 14:13]

I expected that updating an existing date with C-u C-c ! would produce
the same result as creating a new date-time.

Emacs : GNU Emacs 30.0.50 (build 10, x86_64-pc-linux-gnu, GTK+ Version 
3.22.30, cairo version 1.15.12)

of 2023-02-21
Package: Org mode version 9.6.1 (release_9.6.1-262-gd94f40 @ 
/home/dortmann/src/git-org-mode/lisp/)

Re: [External] : [RFC] If you use Org 9.6, please share the output of M-x org-element-cache-hash-show-statistics

[Daniel Ortmann]

11.99% of cache searches hashed, 12.16% non-hashable.

13 hours, 20 minutes, 43 seconds

On 2/9/23 05:51, Ihor Radchenko wrote:

Hi,

I would like to assess the efficiency of one of search optimizations used
in org-element.el [1]

The statistics about efficiency is collected by Org, but obviously not
shared without your consent.

If you are ok with sharing the statistics, and you are running Emacs
session for at least few hours (using Org mode, obviously), please reply
sharing the output of
  M-x org-element-cache-hash-show-statistics 
  M-x emacs-uptime 

[1] Pugh [Information Processing Letters] (1990) Slow optimally balanced
  search strategies vs. cached fast uniformly balanced search strategies.
  
https://urldefense.com/v3/__http://dx.doi.org/10.1016/0020-0190(90)90130-P__;!!ACWV5N9M2RV99hQ!JwEvxu0CggVEXgYmfXdxPXq0nYdBMMbQ3NzQ6pTShxTfCLwft_6uaHlG2rbztwtljiKyvCyPZJDkkaaGDGJo$

Re: [External] : Re: Clocking in is pretty slow in version 9.6 when the item has a large

[Daniel Ortmann]

Eli,
I also had performance issues after the logbook was switched to true 
parsing instead of regular expressions.  In my case, I had logbook 
entries going back to 2012!


After I cleared out the excess entries the performance jumped back up.

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3790bf8ea1d070055a989f0b9587948e07877977

On 12/4/22 11:41, Ihor Radchenko wrote:

Eli Qian  writes:


Any idea about speeding up clocking in?

Try reducing `org-element--cache-self-verify-frequency' to a smaller
number.

--- Begin Message ---
Works perfectly after cleaning out old time log entries going back to 
2013.  :-)


On 10/20/22 00:37, Ihor Radchenko wrote:

Daniel Ortmann  writes:


(The performance drop was sudden and steep, by the way.)

It is because clocking now calls Org parser API.
https://urldefense.com/v3/__https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3790bf8ea1d070055a989f0b9587948e07877977__;!!ACWV5N9M2RV99hQ!KgwLbNpmmeNRH40ZJBT24H5ehmytyzRmS_wXhRSXlz7b-jzilorwtWKuAF0iQwTkP4UT779uIe4jNXhYh7W-$



--- End Message ---

Re: [PATCH] Add new :results ignore header argument (was: [External] : Re: [BUG] executing sh source block with ':results none' encounters error region is longer than org-table-convert-region-max-line

[Daniel Ortmann]

Works great!

On 11/22/22 00:02, Daniel Ortmann wrote:

No objections.

On 11/21/22 20:12, Ihor Radchenko wrote:

Daniel Ortmann  writes:


I am happy with whatever you decide. :-)

Then, here is a tentative patch introducing new :results ignore header
argument.

Any objections?

Re: [PATCH] Add new :results ignore header argument (was: [External] : Re: [BUG] executing sh source block with ':results none' encounters error region is longer than org-table-convert-region-max-line

[Daniel Ortmann]

No objections.

On 11/21/22 20:12, Ihor Radchenko wrote:

Daniel Ortmann  writes:


I am happy with whatever you decide.  :-)

Then, here is a tentative patch introducing new :results ignore header
argument.

Any objections?

Re: [External] : Re: [BUG] executing sh source block with ':results none' encounters error region is longer than org-table-convert-region-max-lines [9.6-pre (release_9.5.5-1118-g70cee1 @ /home/dortman

[Daniel Ortmann]

I am happy with whatever you decide.  :-)

On 11/20/22 20:34, Ihor Radchenko wrote:

Daniel Ortmann  writes:


Please see attached which has the following code which reproduces the issue:

#+begin_src sh :shebang #!/bin/bash :results none
for (( i=1500 ; i>0 ; i-=1 ))
do
      head -c 6 /dev/urandom | uuencode -m -
done |
tee /dev/null
#+end_src

Thanks!

I was able to reproduce. However, this particular error appears to be
intentional.

`org-table-convert-region-max-lines' has been introduced explicitly for
such scenarios because table conversion may take significant time when
the output is large.

I think we can do 2 things to address the problem:

1. Tweak the error wording. Probably to something like
Babel result processing: Region is longer than 
`org-table-convert-region-max-lines' (%s) lines; not converting

2. Maybe introduce something like :results ignore to discard the results
completely.

Re: [External] : Re: [BUG] executing sh source block with ':results none' encounters error region is longer than org-table-convert-region-max-lines [9.6-pre (release_9.5.5-1118-g70cee1 @ /home/dortman

[Daniel Ortmann]

Please see attached which has the following code which reproduces the issue:

#+begin_src sh :shebang #!/bin/bash :results none
for (( i=1500 ; i>0 ; i-=1 ))
do
    head -c 6 /dev/urandom | uuencode -m -
done |
tee /dev/null
#+end_src


On 11/18/22 02:45, Ihor Radchenko wrote:

Daniel Ortmann  writes:


I have several small sh source blocks with ':results none'. The source
is executed for effect and the last line of the source is:
... | tee /target/path/to/file.csv

⛔ Error (org-babel): Error reading results: (user-error "Region is
longer than ‘org-table-convert-region-max-lines’ (999) lines; not
converting")

I expected that :results none would simply drop the output rather than
complaining about it.

Even though it says "error", the results seem to be correct.

This is because blocks with :results none may still be used as input for
other source blocks as reference or noweb reference. So, the results are
computed, but not inserted or otherwise indicated.

Could you please provide a reproducer so that we fix the issue with
table conversion?



reproduce.org
Description: Lotus Organizer

[BUG] executing sh source block with ':results none' encounters error region is longer than org-table-convert-region-max-lines [9.6-pre (release_9.5.5-1118-g70cee1 @ /home/dortmann/src/git-org-mode/li

[Daniel Ortmann]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See

https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


I have several small sh source blocks with ':results none'. The source
is executed for effect and the last line of the source is:
... | tee /target/path/to/file.csv

⛔ Error (org-babel): Error reading results: (user-error "Region is 
longer than ‘org-table-convert-region-max-lines’ (999) lines; not 
converting")


I expected that :results none would simply drop the output rather than
complaining about it.

Even though it says "error", the results seem to be correct.

Emacs : GNU Emacs 29.0.50 (build 8, x86_64-pc-linux-gnu, GTK+ Version 
3.22.30, cairo version 1.15.12)

of 2022-11-17
Package: Org mode version 9.6-pre (release_9.5.5-1118-g70cee1 @ 
/home/dortmann/src/git-org-mode/lisp/)

Re: [External] : RE: org-assert-version considered harmful

[Daniel Ortmann]

Malcolm,
I also ran into troubles which are similar, apparently due to mixed 
org-mode versions; we've got to load org-mode before emacs tries to do 
it for us or we get mixed stuff.


My resolution was to load the org-mode path first in my init.el file and 
then require org:


   (add-to-list 'load-path "/home/dortmann/src/git-org-mode/lisp")
   (require 'org)

And then I build with something like this:

   dortmann@ddo-linux:src$ cd ~/src/git-org-contrib/ && git pull && cd
   ~/src/git-org-mode/ && git pull && make all && make autoloads && cd
   ~/src/git-emacs-master/ && git pull && make all && sudo -H make
   install && cd ..


Then only an occasional 'make bootstrap' is required in the emacs build dir.




On 10/31/22 09:11, Cook, Malcolm wrote:


Hello,

I found this recent thread researching why my strategy for staying 
abreast with org head had started failing with invalid-function 
"org-assert-version"


My strategy had been to build org initially with

` cd ~/.emacs.d && git clone 
https://git.savannah.gnu.org/git/emacs/org-mode.git 
 
& org-mode && make autoloads && make`


and ensure this clone of org was picked up in my 
"~/.emacs.d/org-mode/lisp by including the following in my .init.el 
very early (right after bootstrapping the package system and use-package):


(use-package

:pin manual

:load-path "~/.emacs.d/org-mode/lisp"

)

Then, when I occasionally wished to update org, I would

`cd ~/.emacs.d/org-mode && git pull && make autoloads && make`

Recently I started getting errors invalid-function "org-assert-version".

Upon cursory reading of this thread I guessed that I could fix them by 
adding a `make clean` to my update mantra.


It worked.

Am I advised to do otherwise?Is there a best/better practice?

Thanks,

~Malcolm

Re: [External] : Re: [BUG] recent slow down in agenda's clock table report (and with first clock-in) [9.6-pre (release_9.5.5-995-g4b9aef @ /home/dortmann/src/git-org-mode/lisp/)]

[Daniel Ortmann]

Thank you!  I will take one or more of those steps.

(The performance drop was sudden and steep, by the way.)

On 10/19/22 23:56, Ihor Radchenko wrote:

Daniel Ortmann  writes:


Here you go.

Thanks!
It looks like you have some task with giant years-worth logbook drawer.

You can try to reduce org-element--cache-self-verify-frequency or even
set org-element--cache-self-verify to nil. The latter should be safe if
you haven't seen any Org mode warnings recently.

[BUG] recent slow down in agenda's clock table report (and with first clock-in) [9.6-pre (release_9.5.5-995-g4b9aef @ /home/dortmann/src/git-org-mode/lisp/)]

[Daniel Ortmann]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See

https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


Sometime during the past week I have been surprised by a sudden jump in
load time when clocking into the first task in the agenda. Today, while
tracking down that performance change, the problem "disappeared"! The
first clockin behaved normally.

But! Pressing 'R' in the daily agenda took a long time.

I ran profile-start and then pressed R.
Here are the cpu and memory reports.
The memory report seems odd to me.
Thoughts?

19250 58% + ...
13660 41% + command-execute
35 0% + timer-event-handler

3,754,109,912 99% + command-execute
168,717 0% + timer-event-handler
19,138 0% + redisplay_internal (C function)
0 0% ...


Emacs : GNU Emacs 29.0.50 (build 66, x86_64-pc-linux-gnu, GTK+ Version 
3.22.30, cairo version 1.15.12)

of 2022-10-18
Package: Org mode version 9.6-pre (release_9.5.5-995-g4b9aef @ 
/home/dortmann/src/git-org-mode/lisp/)

Re: [External] : Re: strange errors with org-element-cache-reset and jit-lock-function void-variable org-element-citation-prefix-re

[Daniel Ortmann]

Was Eli Z's observation the key?  Of code not autoloading when 
eval-buffer is running?


On 9/21/22 03:37, Ihor Radchenko wrote:

Daniel Ortmann  writes:


These two lines are in my *Messages* buffer:
File mode specification error: (void-function org-element-cache-reset)
Error during redisplay: (jit-lock-function 1) signaled (void-variable
org-element-citation-prefix-re)

Confirmed.
I know how to "fix" this (can just add require 'org-element into
`org-mode'), but I do not fully understand what is going on on Emacs
side.

Let's see what Emacs devs say.
See 
https://urldefense.com/v3/__https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57972__;!!ACWV5N9M2RV99hQ!I8yBQdVtvdB9WZzgR3JRtDsvGImyGOhqd8fkT_pXuN02wF5lk8ftp-3v1HiF-T3Rn-eyiQIr2BhjbxqK_bo$

strange errors with org-element-cache-reset and jit-lock-function void-variable org-element-citation-prefix-re

[Daniel Ortmann]

Hmmm ...
While trying to investigate one bug I have run into another odd one:

 * emacs version: GNU Emacs 29.0.50 (build 23, x86_64-pc-linux-gnu,
   GTK+ Version 3.22.30, cairo version 1.15.12) of 2022-09-20
 * org version: Org mode version 9.5.5 (release_9.5.5-804-gf1a197 @
   /home/dortmann/src/git-org-mode/lisp/)


These two lines are in my *Messages* buffer:
File mode specification error: (void-function org-element-cache-reset)
Error during redisplay: (jit-lock-function 1) signaled (void-variable 
org-element-citation-prefix-re)



I ran this:
dortmann@ddo-linux:.emacs.d$ emacs -Q --debug-init asdf.el
... and then ran eval-buffer.

Where asdf.el has this content:
(add-to-list 'load-path "/home/dortmann/src/git-org-mode/lisp")
(require 'org)

(setq org-capture-templates
  `(("c" "Item to current clocked task" checkitem
   (clock)
   "%i%?" :prepend t :empty-lines 1)))



Then I loaded asdf.org which has this:
* TODO start clock on this test item


The result is the failure message above.  :-/

'make autoloads' works but 'make ; make autoloads' fails with a version mismatch?

[Daniel Ortmann]

What's up with this behavior?  It began a couple of weeks ago.  I have 
the load-path set immediately in my init.el followed by require org.


Versions are:

 * GNU Emacs 29.0.50 (build 9, x86_64-pc-linux-gnu, GTK+ Version
   3.22.30, cairo version 1.15.12) of 2022-09-14
 * Org mode version 9.5.5 (release_9.5.5-785-g86c463 @
   /home/dortmann/src/git-org-mode/lisp/)

'make clean' followed by 'make autoloads' works fine:

dortmann@ddo-linux:git-org-mode$ make autoloads
make -C lisp autoloads
make[1]: Entering directory '/home/dortmann/src/git-org-mode/lisp'
rm -f org-version.el org-loaddefs.el org-version.elc org-loaddefs.elc 
org-install.elc

org-version: 9.5.5 (release_9.5.5-785-g86c463)
Loading /home/dortmann/src/git-org-mode/lisp/org-compat.el (source)...
Loading /home/dortmann/src/git-org-mode/mk/org-fixup.el (source)...
Package autoload is deprecated
org-loaddefs: 9.5.5 (release_9.5.5-785-g86c463)
Loading /home/dortmann/src/git-org-mode/lisp/org-compat.el (source)...
Loading /home/dortmann/src/git-org-mode/mk/org-fixup.el (source)...
Package autoload is deprecated
make[1]: Leaving directory '/home/dortmann/src/git-org-mode/lisp'
dortmann@ddo-linux:git-org-mode$

*==>> *But 'make clean' and then 'make' followed by 'make autoloads' 
fails.  I could not get around it by manipulating load-path further:


dortmann@ddo-linux:git-org-mode$ make autoloads
make -C lisp autoloads
make[1]: Entering directory '/home/dortmann/src/git-org-mode/lisp'
rm -f org-version.el org-loaddefs.el org-version.elc org-loaddefs.elc 
org-install.elc

org-version: 9.5.5 (release_9.5.5-785-g86c463)
Loading /home/dortmann/src/git-org-mode/lisp/org-compat.el (source)...
Warning (emacs): Org version mismatch.  Make sure that correct 
‘load-path’ is set early in init.el

This warning usually appears when a built-in Org version is loaded
prior to the more recent Org version.

Version mismatch is commonly encountered in the following situations:
1. Emacs is loaded using literate Org config and more recent Org
   version is loaded inside the file loaded by ‘org-babel-load-file’.
   ‘org-babel-load-file’ triggers the built-in Org version clashing
   the newer Org version attempted to be loaded later.

   It is recommended to move the Org loading code before the
   ‘org-babel-load-file’ call.

2. New Org version is loaded manually by setting ‘load-path’, but some
   other package depending on Org is loaded before the ‘load-path’ is
   configured.
   This "other package" is triggering built-in Org version, again
   causing the version mismatch.

   It is recommended to set ‘load-path’ as early in the config as
   possible.

3. New Org version is loaded using straight.el package manager and
   other package depending on Org is loaded before straight triggers
   loading of the newer Org version.

   It is recommended to put
    (straight-use-package ’org)
   early in the config.  Ideally, right after the straight.el
   bootstrap.  Moving ‘use-package’ :straight declaration may not be
   sufficient if the corresponding ‘use-package’ statement is
   deferring the loading.

Error: error ("Org version mismatch.  Make sure that correct ‘load-path’ 
is set early in init.el")
  mapbacktrace(#f(compiled-function (evald func args flags) #0xa578661cbaef144>))

  debug-early-backtrace()
  debug-early(error (error "Org version mismatch.  Make sure that 
correct ‘load-path’ is set early in init.el"))
  signal(error ("Org version mismatch.  Make sure that correct 
‘load-path’ is set early in init.el"))
  error("Org version mismatch.  Make sure that correct `load-path' is 
set early in init.el")
  byte-code("\300 \301\232\204\17\0\302\303!\210\304\305!\210\300\207" 
[org-git-version "release_9.5.5-785-g86c463" warn "Org version 
mismatch.  Make sure that correct `load-path' is set early in 
init.el\nThis warning usually appears when a built-in Org version is 
loaded\nprior to the more recent Org version.\n\nVersion mismatch is 
commonly encountered in the following situations:\n1. Emacs is loaded 
using literate Org config and more recent Org\n   version is loaded 
inside the file loaded by `org-babel-load-file'.\n   
`org-babel-load-file' triggers the built-in Org version clashing\n   the 
newer Org version attempted to be loaded later.\n\n   It is recommended 
to move the Org loading code before the\n   `org-babel-load-file' 
call.\n\n2. New Org version is loaded manually by setting `load-path', 
but some\n   other package depending on Org is loaded before the 
`load-path' is\n   configured.\n   This \"other package\" is triggering 
built-in Org version, again\n causing the version mismatch.\n\n   It is 
recommended to set `load-path' as early in the config as\n   
possible.\n\n3. New Org version is loaded using straight.el package 
manager and\n other package depending on Org is loaded before straight 
triggers\n   loading of the newer Org version.\n\n   It is recommended 
to put\n    (straight-use-package 'org)\n   early in the config.  
Ideally, right 

Re: [External] : Re: org-mode compile issue this morning - how to report this?

[Daniel Ortmann]

Fix confirmed!  Everything works fine now with emacs 29.0.50.  (Many 
many new messages about obsolete functions.)

Thank you

GNU Emacs 29.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.22.30, 
cairo version 1.15.12) of 2022-08-25
Org mode version 9.5.4 (release_9.5.4-758-g3c11e9 @ 
/home/dortmann/src/git-org-mode/lisp/)


On 8/25/22 09:36, Daniel Ortmann wrote:

FYI,
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57394

Lars at gnu says it is fixed in emacs 29
The bug's web page says, more specifically, "bug marked as fixed in 
version 29.1"


... I can't find emacs 29.1; my 'git pull' still says 29.0 and I don't 
see any 29.1 branches available.

I have not been able to test and verify the fix.

Thoughts?

    Daniel Ortmann  writes:


Error: error ("Eager macro-expansion failure: (void-function
byte-compile-warn-obsolete)")
debug-early-backtrace()
debug-early(error (error "Eager macro-expansion failure:
(void-function byte-compile-warn-obsolete)"))


This should now be fixed in Emacs 29.

Re: [External] : Re: org-mode compile issue this morning - how to report this?

[Daniel Ortmann]

FYI,
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57394

Lars at gnu says it is fixed in emacs 29
The bug's web page says, more specifically, "bug marked as fixed in 
version 29.1"


... I can't find emacs 29.1; my 'git pull' still says 29.0 and I don't 
see any 29.1 branches available.

I have not been able to test and verify the fix.

Thoughts?

   Daniel Ortmann  writes:


Error: error ("Eager macro-expansion failure: (void-function
byte-compile-warn-obsolete)")
debug-early-backtrace()
debug-early(error (error "Eager macro-expansion failure:
(void-function byte-compile-warn-obsolete)"))


   This should now be fixed in Emacs 29.

Re: [External] : Re: org-mode compile issue this morning - how to report this?

[Daniel Ortmann]

git bisect shows that this emacs commit is the problem (if I understand 
correctly ... this is the first time I have used git bisect):
[6ddcf67052545a0f77233f1a952dc90e296cda35] Make it possible to mark 
generalized variables as obsolete


Here is the bug report:
Subject: 29.0.50; emacs commit 6ddcf67052545a0f77233f1a952dc90e296cda35 
causes org-mode build to fail


dortmann@ddo-linux:git-org-mode$ ( set -eu ;  make clean ; make ; make 
autoloads )

make -C lisp clean
make[1]: Entering directory '/home/dortmann/src/git-org-mode/lisp'
rm -f org-version.el org-loaddefs.el org-version.elc org-loaddefs.elc 
org-install.elc

rm -f *.elc
make[1]: Leaving directory '/home/dortmann/src/git-org-mode/lisp'
make -C doc clean
make[1]: Entering directory '/home/dortmann/src/git-org-mode/doc'
rm -f *.pdf *.html *.info *_letter.tex org-version.inc org-version.tex \
  *.aux *.cp *.cps *.dvi *.fn *.fns *.ky *.kys *.pg *.pgs *.toc \
  *.tp *.tps *.vr *.vrs *.log *.ps
make[1]: Leaving directory '/home/dortmann/src/git-org-mode/doc'
make -C doc clean;  make -C lisp clean;
make[1]: Entering directory '/home/dortmann/src/git-org-mode/doc'
rm -f *.pdf *.html *.info *_letter.tex org-version.inc org-version.tex \
  *.aux *.cp *.cps *.dvi *.fn *.fns *.ky *.kys *.pg *.pgs *.toc \
  *.tp *.tps *.vr *.vrs *.log *.ps
make[1]: Leaving directory '/home/dortmann/src/git-org-mode/doc'
make[1]: Entering directory '/home/dortmann/src/git-org-mode/lisp'
rm -f org-version.el org-loaddefs.el org-version.elc org-loaddefs.elc 
org-install.elc

rm -f *.elc
make[1]: Leaving directory '/home/dortmann/src/git-org-mode/lisp'
make -C lisp compile
make[1]: Entering directory '/home/dortmann/src/git-org-mode/lisp'
rm -f org-version.el org-loaddefs.el org-version.elc org-loaddefs.elc 
org-install.elc

org-version: 9.5.4 (release_9.5.4-758-g3c11e9)
Loading /home/dortmann/src/git-org-mode/lisp/org-compat.el (source)...

Error: error ("Eager macro-expansion failure: (void-function 
byte-compile-warn-obsolete)")

  debug-early-backtrace()
  debug-early(error (error "Eager macro-expansion failure: 
(void-function byte-compile-warn-obsolete)"))
  error("Eager macro-expansion failure: %S" (void-function 
byte-compile-warn-obsolete))
  internal-macroexpand-for-load((defalias 'org-string-width #'(lambda 
(string  pixels) "Return width of STRING when displayed in the 
current buffer.\nReturn width in pixels when PIXELS is non-nil." (if 
(and (version< emacs-version "28") (not pixels)) (org--string-width-1 
string) (remove-text-properties 0 (length string) '(wrap-prefix t 
line-prefix t) string) (unless pixels (remove-text-properties 0 (length 
string) '(face t) string)) (let ((current-invisibility-spec (or (and 
(not (listp buffer-invisibility-spec)) buffer-invisibility-spec) (let 
(result) (dolist (el buffer-invisibility-spec) (unless (or (memq el 
'(org-fold-drawer org-fold-block org-fold-outline)) (and (listp el) 
(memq (car el) '(org-fold-drawer org-fold-block org-fold-outline 
(push el result))) result))) (current-char-property-alias-alist 
char-property-alias-alist)) (with-temp-buffer (setq-local 
display-line-numbers nil) (setq-local buffer-invisibility-spec (if 
(listp current-invisibility-spec) (mapcar (lambda (el) (if (and (consp 
el) (cdr el)) (list (car el)) el)) current-invisibility-spec) 
current-invisibility-spec)) (setq-local char-property-alias-alist 
current-char-property-alias-alist) (let (pixel-width symbol-width) 
(with-silent-modifications (setf (buffer-string) string) (setq 
pixel-width (if (get-buffer-window (current-buffer)) (car 
(window-text-pixel-size nil (line-beginning-position) (point-max))) 
(set-window-buffer nil (current-buffer)) (car (window-text-pixel-size 
nil (line-beginning-position) (point-max) (unless pixels (setf 
(buffer-string) "a") (setq symbol-width (if (get-buffer-window 
(current-buffer)) (car (window-text-pixel-size nil 
(line-beginning-position) (point-max))) (set-window-buffer nil 
(current-buffer)) (car (window-text-pixel-size nil 
(line-beginning-position) (point-max))) (if pixels pixel-width (/ 
pixel-width symbol-width t)
load-with-code-conversion("/home/dortmann/src/git-org-mode/lisp/org-macs.el" 
"/home/dortmann/src/git-org-mode/lisp/org-macs.el" nil t)

  require(org-macs)
load-with-code-conversion("/home/dortmann/src/git-org-mode/lisp/org-compat.el" 
"/home/dortmann/src/git-org-mode/lisp/org-compat.el" nil nil)

  load("org-compat.el")
  command-line-1(("--eval" "(setq vc-handled-backends nil 
org-startup-folded nil org-element-cache-persistent nil)" "--eval" 
"(add-to-list 'load-path \".\")" "--eval" "(load \"org-compat.el\")" 
"--eval" "(load \"../mk/org-fixup.el\")" "--eval" "(org-make-org-version 
\"9.5.4\" \"release_9.5.4-758-g3c11e9\")"))

  command-line()
  normal-top-level()
Eager macro-expansion failure: (void-function byte-compile-warn-obsolete)
make[1]: *** [Makefile:72: org-version.el] Error 255
make[1]: Leaving directory 

org-mode compile issue this morning - how to report this?

[Daniel Ortmann]

Hello,

This morning I can't get org-mode to compile and load at all.  And the 
bug reporting is not working.


What to do?

Thank you!

Here are this morning's messages:

make -C lisp compile
make[1]: Entering directory '/home/dortmann/src/git-org-mode/lisp'
rm -f org-version.el org-loaddefs.el org-version.elc org-loaddefs.elc 
org-install.elc

org-version: 9.5.4 (release_9.5.4-756-g090dac)
Loading /home/dortmann/src/git-org-mode/lisp/org-compat.el (source)...

Error: error ("Eager macro-expansion failure: (void-function 
byte-compile-warn-obsolete)")
  mapbacktrace(#f(compiled-function (evald func args flags) #-0x9324d572c510f29>))

  debug-early-backtrace()
  debug-early(error (error "Eager macro-expansion failure: 
(void-function byte-compile-warn-obsolete)"))
  signal(error ("Eager macro-expansion failure: (void-function 
byte-compile-warn-obsolete)"))
  error("Eager macro-expansion failure: %S" (void-function 
byte-compile-warn-obsolete))
  internal-macroexpand-for-load((defalias 'org-string-width #'(lambda 
(string  pixels) "Return width of STRING when displayed in the 
current buffer.\nReturn width in pixels when PIXELS is non-nil." (if 
(and (version< emacs-version "28") (not pixels)) (org--string-width-1 
string) (remove-text-properties 0 (length string) '(wrap-prefix t 
line-prefix t) string) (unless pixels (remove-text-properties 0 (length 
string) '(face t) string)) (let ((current-invisibility-spec (or (and 
(not (listp buffer-invisibility-spec)) buffer-invisibility-spec) (let 
(result) (dolist (el buffer-invisibility-spec) (unless (or (memq el 
'(org-fold-drawer org-fold-block org-fold-outline)) (and (listp el) 
(memq (car el) '(org-fold-drawer org-fold-block org-fold-outline 
(push el result))) result))) (current-char-property-alias-alist 
char-property-alias-alist)) (with-temp-buffer (setq-local 
display-line-numbers nil) (setq-local buffer-invisibility-spec (if 
(listp current-invisibility-spec) (mapcar (lambda (el) (if (and (consp 
el) (cdr el)) (list (car el)) el)) current-invisibility-spec) 
current-invisibility-spec)) (setq-local char-property-alias-alist 
current-char-property-alias-alist) (let (pixel-width symbol-width) 
(with-silent-modifications (setf (buffer-string) string) (setq 
pixel-width (if (get-buffer-window (current-buffer)) (car 
(window-text-pixel-size nil (line-beginning-position) (point-max))) 
(set-window-buffer nil (current-buffer)) (car (window-text-pixel-size 
nil (line-beginning-position) (point-max) (unless pixels (setf 
(buffer-string) "a") (setq symbol-width (if (get-buffer-window 
(current-buffer)) (car (window-text-pixel-size nil 
(line-beginning-position) (point-max))) (set-window-buffer nil 
(current-buffer)) (car (window-text-pixel-size nil 
(line-beginning-position) (point-max))) (if pixels pixel-width (/ 
pixel-width symbol-width t)
  eval-buffer(# nil 
"/home/dortmann/src/git-org-mode/lisp/org-macs.el" nil t)
load-with-code-conversion("/home/dortmann/src/git-org-mode/lisp/org-macs.el" 
"/home/dortmann/src/git-org-mode/lisp/org-macs.el" nil t)

  require(org-macs)
  eval-buffer(# nil 
"/home/dortmann/src/git-org-mode/lisp/org-compat.el" nil t)
load-with-code-conversion("/home/dortmann/src/git-org-mode/lisp/org-compat.el" 
"/home/dortmann/src/git-org-mode/lisp/org-compat.el" nil nil)

  load("org-compat.el")
  eval((load "org-compat.el") t)
  command-line-1(("--eval" "(setq vc-handled-backends nil 
org-startup-folded nil org-element-cache-persistent nil)" "--eval" 
"(add-to-list 'load-path \".\")" "--eval" "(load \"org-compat.el\")" 
"--eval" "(load \"../mk/org-fixup.el\")" "--eval" "(org-make-org-version 
\"9.5.4\" \"release_9.5.4-756-g090dac\")"))

  command-line()
  normal-top-level()
Eager macro-expansion failure: (void-function byte-compile-warn-obsolete)
make[1]: *** [Makefile:72: org-version.el] Error 255
make[1]: Leaving directory '/home/dortmann/src/git-org-mode/lisp'
make: *** [mk/targets.mk:96: compile] Error 2

Re: [External] : Re: missing a character / font in agenda?

[Daniel Ortmann]

I am not seeing the problem anymore after installing the Symbola fonts.

On 7/16/22 04:15, Ihor Radchenko wrote:

Daniel Ortmann  writes:


More information on that character:

   position: 195 of 690 (28%), column: 26
      character: ⭠ (displayed as ⭠) (codepoint 11104, #o25540,
#x2b60)
    charset: unicode-bmp (Unicode Basic Multilingual Plane
(U+..U+))
code point in charset: 0x2B60
     script: symbol
     syntax: _     which means: symbol
   category: .:Base
   to input: type "C-x 8 RET 2b60" or "C-x 8 RET LEFTWARDS
TRIANGLE-HEADED ARROW"
    buffer code: #xE2 #xAD #xA0
      file code: #xE2 #xAD #xA0 (encoded by coding system utf-8-unix)
    display: no font available

Character code properties: customize what to show
    name: LEFTWARDS TRIANGLE-HEADED ARROW
    general-category: So (Symbol, Other)
    decomposition: (11104) ('⭠')

Would you mind sending a bug report to Emacs devs?
If you run (char-displayable-p ?⭠) on your side but yet not being able
to see the symbol properly, we can hopefully get some good suggestions
(or even a fix) from Emacs guys.

Best,
Ihor

Re: [External] : Re: missing a character / font in agenda?

[Daniel Ortmann]

Ihor,
What are your thoughts?

On 7/12/22 15:03, Juan Manuel Macías wrote:

Juan Manuel Macías writes:


The most reasonable thing would be to use a more
common symbol. But I'm still intrigued by the origin of that symbol...

It seems that the culprit is in line 1592 of org-agenda.el

I think this should be considered a bug, since the glyph used (LEFTWARDS
TRIANGLE-HEADED ARROW / #2b60) is not present in most fonts.

Best regards,

Juan Manuel

Re: [External] : Re: missing a character / font in agenda?

[Daniel Ortmann]

That odd new character just showed up after a normal daily org-mode 'git 
pull'.


The Symbola.ttf font worked fine.
I used this page for for instructions.
https://linuxconfig.org/how-to-install-and-manage-fonts-on-linux

After copying the font to ~/.local/share/font/ and running the 'fc-cache 
-vf' command

... The font appears after emacs + org-mode are restarted.
(I did not need to run set-fontset-font.)

Somewhere in there I also pulled fresh org-mode and emacs code and 
rebuilt; am not sure if that was needed.


Here is how that screen now appears:



 * Would using the ASCII '<' character be a better solution?
 * Is anyone else seeing this issue and missing font?
 * What would allow that Symbola font to be available?
 * Is that Symbola font, or equivalent, now a true dependency? Or is
   there something more common which I should be using? (Perhaps I have
   missed a normal configuration step?)

Thank you!


On 7/12/22 12:58, Juan Manuel Macías wrote:

Hi,

Daniel Ortmann writes:


Any clues where this particular symbol resides?  A hint about the
package name would wonderful.  :-)

To be able to display "unusual" symbols in Emacs, I usually use the
symbola font:

You can download it here:

https://urldefense.com/v3/__https://fontlibrary.org/en/font/symbola__;!!ACWV5N9M2RV99hQ!LCWutd87ZOlNkSgFTjjR0zYsqhv6xP6ZBep63lyK7tIveH2MWiQ331YB8rJexEVU6gjcjT99EdYoJvFPvxABlZvT$  


And then:

(set-fontset-font t 'symbol (font-spec :family "Symbola"))

But I think that what is interesting here is to know how that character
has arrived. Could it be related to some new package you have installed
lately?

Best regards,

Juan Manuel

missing a character / font in agenda?

[Daniel Ortmann]

Hello,

During the past couple of weeks I have been seeing a new character in 
the agenda when the log is on and I am displaying the time grid. I have 
tried to find and install this character representation on Fedora-based 
Linux but have not found the magic.


Any clues where this particular symbol resides?  A hint about the 
package name would wonderful.  :-)


Thank you!




More information on that character:

 position: 195 of 690 (28%), column: 26
    character: ⭠ (displayed as ⭠) (codepoint 11104, #o25540, 
#x2b60)
  charset: unicode-bmp (Unicode Basic Multilingual Plane 
(U+..U+))

code point in charset: 0x2B60
   script: symbol
   syntax: _     which means: symbol
 category: .:Base
 to input: type "C-x 8 RET 2b60" or "C-x 8 RET LEFTWARDS 
TRIANGLE-HEADED ARROW"

  buffer code: #xE2 #xAD #xA0
    file code: #xE2 #xAD #xA0 (encoded by coding system utf-8-unix)
  display: no font available

Character code properties: customize what to show
  name: LEFTWARDS TRIANGLE-HEADED ARROW
  general-category: So (Symbol, Other)
  decomposition: (11104) ('⭠')

There are text properties here:
  breadcrumbs  nil
  day  738348
  dotime   "12:11 "
  duration nil
  extra    ""
  face org-agenda-current-time
  format   [Show]
  level    ""
  org-agenda-type  agenda
  org-category ""
  org-day-cnt  1
  org-heading  t
  org-last-args    (nil 738348 day)
  org-priority-highest 65
  org-priority-lowest  67
  org-redo-cmd (org-agenda-list 'nil 738348 'day nil)
  org-series-cmd   nil
  tags nil
  time "12:11 ┄ "
  time-of-day  1211
  txt  [Show]

Re: [External] : Re: how to investigate? org-element-cache Unregistered buffer modifications detected

[Daniel Ortmann]

Hello,

... I rebuild at least once per day.
My current org-mode version is:
Org mode version 9.5.4 (release_9.5.4-596-gaa5bc2 @ 
/home/dortmann/src/git-org-mode/lisp/)


A bit more information may help?

 * 1.2MB org-mode file
 * received a stubborn parse error after today's build; could not load
   my org file; the file location looked fine
 * partitioned the large file into smaller files
 * ... was able to load each of those smaller files
 * afterwards, without any changes, I was able to load the full file
   without the 'parse error'
 * ... but once again received that org-element-cache warning
 * Now, after a fresh pull of code and a rebuild, NONE of the errors or
   warnings occur.


Everything is clean now.

Could loading those smaller files have cleaned or updated the cache?  Or 
was it your code updates?


Thank you!

On 6/28/22 21:03, Ihor Radchenko wrote:

Daniel Ortmann  writes:


Hey there,
I have a 1.2+ MB org-mode file and have been getting the following
message for a week or two.  I have cleaned up content by archiving older
content and have run org-lint to cleanup some syntax issues ...

How to debug this type of issue?

Thanks for reporting!
Could you please update you Org to the latest version and check if the
warning keep appearing? I just pushed a commit that changes the logic
when to show this type of warning (the previous logic had
false-positives too often).

Best,
Ihor

how to investigate? org-element-cache Unregistered buffer modifications detected

[Daniel Ortmann]

Hey there,
I have a 1.2+ MB org-mode file and have been getting the following 
message for a week or two.  I have cleaned up content by archiving older 
content and have run org-lint to cleanup some syntax issues ...


How to debug this type of issue?

Warning (org-element-cache): org-element--cache: Unregistered buffer 
modifications detected. Resetting.
If this warning appears regularly, please report the warning text to Org 
mode mailing list (M-x org-submit-bug-report).

The buffer is: plan.org
 Current command: (org-agenda 4070 5168)
 Chars modified: 4070
 Buffer modified: 5168
 Backtrace:
nil Disable showing Disable logging

Thank you for your guidance.

Re: [External] : Re: C-S left no longer shifts date entry?

[Daniel Ortmann]

Works fine with 'emacs -Q'.  I will debug further.

Thank you!

On 6/10/22 09:32, Ihor Radchenko wrote:

Daniel Ortmann  writes:


This morning C-S left no longer shifts the date in the LOGBOOK drawer.
I set the cursor on the second date which was 2022-06-10 initially and
pressed C-S left
... expecting it to be shifted to the 2022-06-09 as shown below.

    CLOCK: [2022-06-09 Thu 11:53]--[2022-06-09 Thu 19:20] =>  7:27

I am unable to reproduce.
S- does shift the date on my side. Can you try with emacs -Q?
See 
https://urldefense.com/v3/__https://orgmode.org/manual/Feedback.html__;!!ACWV5N9M2RV99hQ!OtZni8QMUmyNNh3KYcW3zKnoBJLHUBkaoZiQjC0YF2DVR0egNb8Qa_U3islDF0sJR4Mm_QDGSo7ilvQyE3c$

Best,
Ihor

Re: C-S left no longer shifts date entry?

[Daniel Ortmann]

I think it was actually S left which I was using.  (My fingers knew the 
command but did not tell my brain.)

... Anyway, that date-shifting no longer is working.

On 6/10/22 09:07, Daniel Ortmann wrote:
This morning C-S left no longer shifts the date in the LOGBOOK drawer. 
I set the cursor on the second date which was 2022-06-10 initially and 
pressed C-S left

... expecting it to be shifted to the 2022-06-09 as shown below.

  CLOCK: [2022-06-09 Thu 11:53]--[2022-06-09 Thu 19:20] => 7:27

I've checked this email list as well as news and C-h b and do not see 
directions for an alternate method.

Can anyone direct me?
I don't know if this is an intentional change or perhaps a bug?



Versions:

Org mode version 9.5.4 (release_9.5.4-531-g57d64c @ 
/home/dortmann/src/git-org-mode/lisp/)


GNU Emacs 29.0.50 (build 5, x86_64-pc-linux-gnu, GTK+ Version 3.22.30, 
cairo version 1.15.12) of 2022-06-10

C-S left no longer shifts date entry?

[Daniel Ortmann]

This morning C-S left no longer shifts the date in the LOGBOOK drawer.  
I set the cursor on the second date which was 2022-06-10 initially and 
pressed C-S left

... expecting it to be shifted to the 2022-06-09 as shown below.

  CLOCK: [2022-06-09 Thu 11:53]--[2022-06-09 Thu 19:20] =>  7:27

I've checked this email list as well as news and C-h b and do not see 
directions for an alternate method.

Can anyone direct me?
I don't know if this is an intentional change or perhaps a bug?



Versions:

Org mode version 9.5.4 (release_9.5.4-531-g57d64c @ 
/home/dortmann/src/git-org-mode/lisp/)


GNU Emacs 29.0.50 (build 5, x86_64-pc-linux-gnu, GTK+ Version 3.22.30, 
cairo version 1.15.12) of 2022-06-10

Re: [External] : Re: export org table to other formats (gnumeric or scalc or xlsx)

[Daniel Ortmann]

I highly recommend a recent LibreOffice.  Nearly everything I do is 
through LibreOffice and CSV files.  MS Excel has problems when using 
inter-field-separators such as semicolons.


When I receive Excel (or other) spreadsheets from people, I must first 
convert them into CSV files to clear out the crazy manual formatting in 
order to process them content.


Often a flow such as this helps:
*.xlsx => *.csv => Emacs (to cleanup text, newlines, whitespace) =>
LibreOffice (to sort, reorder, analyze with better use of graphical 
realestate) =>

*.org tables with Emacs macros to process further =>
*.csv => LibreOffice to generate fresh *.xlsx

Sometimes cleanup with *nix 'cut' and 'paste' tools helps greatly:
- *.csv => cut -d\; -f1-3 >file1
- *.csv => cut -d\; -f4- >file2
- Edit content or add a new set of data
- paste -d';' file1 file2
etc.

Very powerful.

On 7/4/21 5:00 PM, Tim Cross wrote:

Uwe Brauer  writes:


Hi

A couple of days ago I asked about importing excel formula into org
tables, and they only ways seems to do it manually.

I just realised that I need it also the other way around, exporting  to
some spreadsheet format, like gnumerica or scalc or xlsx.

But that look equally difficult, isn't.

Some hints would be welcome.


The big problem here is that there is no single format understood by all
these different programs which you can use. While CSV works OK for data,
it does not support formulas and other meta data. In particular,
translating formulas is a real challenge.

I went down this rabbit hole some years back i.e. having a workflow
which allowed me to interact with others who used Excel and allowing me
to use org mode.

It took hours and hours of additional work and never worked reliably
because

- I never found a way of 'exporting' to a format which could be imported
   by Excel and included formulas

- None of the Excel export formats support full export of Excel -
   especially at the meta data level i.e. Visual Basic macros and other
   'objects'. Workbooks were a real pain.

- Constantly having to do 'hand tweaking' to fix formulas and other
   'meta' information (both directions). When exporting to Excel, I would
   have to open the spreadsheet in another program to 'clean it up'
   before sending it to colleagues.

  - Too many different Excel versions. This issue may not be as bad now,
but back then, there were multiple xlsx versions and you would get
different results depending on the version.

In the end, I gave up and either just used LibreOffice (Linux) or an OSX
program (I think it was called numerics, but too long ago to recall
accurately - it was not an Apple program). In the end, my decision was
to only use org if either I only needed the data (possibly adding
formulas manually), would not need to export back to Excel (no
collaboration) and only need export to org once. Otherwise, use
LibreOffice or another program able to understand xlsx natively.

One thing which we did use for a time was to connect the excel
spreadsheets with a database. The excel spreadsheet would pull the data
from the database and apply formulas/macros to that data. I was then
able to pull data from the database into org and then export it back
into the database. It took a bit to setup - used Visual Basic to manage
data import/export into database and needed an Excel based UI to do some
CRUD operations and then some scripts on the Linux side to
extract/update the data from org. This sort of worked, but had issues
with synchronisation of data. It really needed a much more sophisticated
database API to make it work well which could handle versioning or
resolve data conflicts and dependencies etc.

To some extent, I guess Excel is a good example of what RMS was
concerned about and the problem with closed proprietary standards. While
someone can reverse engineer the formats and spend the time to develop
converters, they remain at the mercy of MS who can simply change the
formatting at their whim.  Most efforts I've seen seem to run out of
puff because of the efforts needed to maintain things.

Of course, life would probably be better if so many project managers
stopped using Excel for EVERYTHING! I've noticed over the last 10+ years
a growing use of Excel in the 'enterprise' as the default 'tool' to
collect and manage information. To many, it seems like a simple
solution, but in reality, you end up with all sorts of valuable
information floating around in multiple spreadsheets and spend far too
much time entering/updating data using a crappy interface and tweaking
format commands. I've seen more than one project almost hit the rocks
because someone was working off an old excel spreadsheet with the wrong
data. If you raise this concern, the likely outcome is a decision to use
MS Project, then your really stuffed!

Re: [External] : Re: The fate of ditaa.jar (9.4.5.)

[Daniel Ortmann]

And perhaps maintain the table in elpa?

On 5/11/21 7:52 AM, TEC wrote:

Tim Cross  writes:


I also had to install textlive, plantuml, graphviz, taskjuggler,
ledger, sqlite and many other things.

Perhaps it would be good to make a table of

| software | needed for | package name | download page |

and/or prompt users when an action requiring another executable is
undertaken if it isn't found.

--
Timothy

Re: [External] : Re: Invalid duration format (9.4.5)

[Daniel Ortmann]

This fix works for me.

   commit 6107c2b15bf19ab5300c2861db365a3dc310adc6 (origin/maint)
   Author: Nicolas Goaziou 
   Date:   Mon May 10 18:00:58 2021 +0200

    Revert "agenda: Fix "org-duration-to-minutes: Invalid duration
   format" error"

    This reverts commit bc857bfc62ba94e04fb338bfb35f4b612c114d0c.

    The "fix" breaks elsewhere, as reported below.

    Reported-by: Daniel Ortmann 
   <http://lists.gnu.org/r/emacs-orgmode/2021-05/msg00592.html>


On 5/10/21 9:25 AM, Nicholas Savage wrote:

Thanks for the report. This was also reported last night too: 
https://urldefense.com/v3/__https://lists.gnu.org/archive/html/emacs-orgmode/2021-05/msg00592.html__;!!GqivPVa7Brio!Non_TqJOEgfushDGmmgrZySe4dyz4pr69tdmeFRzKzRUwzoLORtfh7pMyW2pU_1ZotQ$

I'll probably have a chance to look into this sometime today, but it probably 
won't be until this evening if anyone else has a chance earlier than that.

On Mon, May 10, 2021, at 09:54, Detlef Steuer wrote:

Am Mon, 10 May 2021 16:45:30 +0300
schrieb Jarmo Hurri :


Greetings.

To get my work done, I had to switch from master branch to stable, but
now I started getting "invalid duration format" error when trying to
create my daily agenda:

org-duration-to-minutes: Invalid duration format: #("12:45-14:15 +1w"
0 15 (fontified nil org-category "schedule"))

Here is the corresponding row, and the preceding row, from file
schedule.org:

<2021-04-15 Thu 09:15-10:45 +1w>
<2021-04-19 Mon 12:45-14:15 +1w>

Any hints?

Jarmo




Can confirm!

Detlef


--
"Wozu leben wir, wenn nicht dazu, uns gegenseitig das Leben
  einfacher zu machen. (George Eliot)"

Dr. Detlef Steuer
Helmut-Schmidt-Universität
Fakultät WiSo
Holstenhofweg 85
22043 Hamburg

Tel:  040/6541-2819
mail: ste...@hsu-hh.de

Re: [External] : Bug: org-duration-to-minutes: Invalid duration format [9.4.5 (release_9.4.5-530-g981f25 @ /home/dortmann/src/git-org-mode/lisp/)]

[Daniel Ortmann]

Fix confirmed as working.

   commit 6107c2b15bf19ab5300c2861db365a3dc310adc6 (origin/maint)
   Author: Nicolas Goaziou 
   Date:   Mon May 10 18:00:58 2021 +0200

    Revert "agenda: Fix "org-duration-to-minutes: Invalid duration
   format" error"

    This reverts commit bc857bfc62ba94e04fb338bfb35f4b612c114d0c.

    The "fix" breaks elsewhere, as reported below.

    Reported-by: Daniel Ortmann 
   <http://lists.gnu.org/r/emacs-orgmode/2021-05/msg00592.html>



On 5/9/21 5:01 PM, Daniel Ortmann wrote:

Hello,
I opened my 'plan.org' file today and the C-c a a failed while 
creating the agenda.  The information is below.


Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See

https://urldefense.com/v3/__https://orgmode.org/manual/Feedback.html*Feedback__;Iw!!GqivPVa7Brio!LOkzTB59CDBzIuoTfXvXRwtkVqvxvGdCHi8m2Sx1wNReIvg87vPYcPOk5gcjflocjFo$ 


Your bug report will be posted to the Org mailing list.


The following long-time LOGBOOK entry, which has worked for a long 
time, now shows an error saying:


- Rescheduled from "[2020-01-16 Thu 12:30-13:30 ++1w]" on [2020-01-16 
Thu 11:03]


Here is the message from *Messages*:

org-duration-to-minutes: Invalid duration format: #("12:30-13:00 ++1w" 
0 16 (fontified nil org-category "plan"))



Emacs : GNU Emacs 28.0.50 (build 8, x86_64-pc-linux-gnu, GTK+ Version 
3.22.30, cairo version 1.15.12)

of 2021-05-09
Package: Org mode version 9.4.5 (release_9.4.5-530-g981f25 @ 
/home/dortmann/src/git-org-mode/lisp/)

Bug: org-duration-to-minutes: Invalid duration format [9.4.5 (release_9.4.5-530-g981f25 @ /home/dortmann/src/git-org-mode/lisp/)]

[Daniel Ortmann]

Hello,
I opened my 'plan.org' file today and the C-c a a failed while creating 
the agenda.  The information is below.


Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See

https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


The following long-time LOGBOOK entry, which has worked for a long time, 
now shows an error saying:


- Rescheduled from "[2020-01-16 Thu 12:30-13:30 ++1w]" on [2020-01-16 
Thu 11:03]


Here is the message from *Messages*:

org-duration-to-minutes: Invalid duration format: #("12:30-13:00 ++1w" 0 
16 (fontified nil org-category "plan"))



Emacs : GNU Emacs 28.0.50 (build 8, x86_64-pc-linux-gnu, GTK+ Version 
3.22.30, cairo version 1.15.12)

of 2021-05-09
Package: Org mode version 9.4.5 (release_9.4.5-530-g981f25 @ 
/home/dortmann/src/git-org-mode/lisp/)

are multi-hop file urls broken?

[Daniel Ortmann]

Today all of my multi-hop urls seem to be broken.  Is anyone else 
experiencing this issue?

Re: [O] Bug: clocktable error in org-agenda [9.2.2 (release_9.2.2-245-g9d7b1e @ /home/dortmann/src/git-org-mode/lisp/)]

[Daniel Ortmann]

Does anyone have an idea of why this problem occurs?
And perhaps how to fix it?

On 3/4/19 7:02 PM, Bernt Hansen wrote:
> Actually I think it is a bug.  This weird behaviour has been around for
> a very long time (years probably).
>
> I have noticed similar behaviour with log mode, and clock check mode as
> well.
>
> I can reproduce the issue at with the following recipe:
>
> C-c a a (start org agenda)
> j -3 RET (go back 3 days although any number of days probably works)
> l (turn on log mode) or R for clock report
> . (go to today)
> l (wont' turn off log mode anymore)
>
> Workaround:
>
> j -3 RET (go back 3 days again)
> l (turn log mode off) or R for clock report
> .  (works normally again)
>
> I run into this regularly when I'm checking clock reports in the agenda
> for the past week (jump to the past, turn clock reports or logging on)
> then move forwards again and you can't turn it off.
>
> HTH.
>
> Regards,
> Bernt
>
> Daniel Ortmann  writes:
>
>> This is crazy!  After months of problems, I myself no longer can
>> reproduce this issue!  :-/
>>
>> Comments welcome (Please!) ... but this issue no longer is actually a bug. 
>>
>> On 3/4/19 3:22 PM, Daniel Ortmann wrote:
>>> Remember to cover the basics, that is, what you expected to happen and
>>> what in fact did happen.  You don't know how to make a good report?  See
>>>
>>>  
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__orgmode.org_manual_Feedback.html-23Feedback=DwIGaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=Dkq-B4wf3U4UeyggH34kSw8HWPy7CqI3u3RwPXz2f5o=4fSQsyYOysB0leNb80s58m3u_JCrMhGMzVXrgGispfw=_u3sTu0de7IKTb2RsyImTOaTAqX4pl-EiuT_gDXAtXA=
>>>
>>> Your bug report will be posted to the Org mailing list.
>>> 
>>>
>>> Since this problem has been occurring for a few months now, it's got to
>>> be something wrong in my configuration.
>>>
>>> In the org agenda, pressing R activates the clock report but pressing it
>>> again does not turn it off.  The same behavior occurs through the menu;
>>> clicking the view clock report checkbox turns the checkbox on and the
>>> clock report appears in the agenda ... but clicking it again does not
>>> turn the clock report off; it stays visible.
>>>
>>> To log the bug report I started with
>>> emacs -Q -l ~/minimal-org.el
>>> then ran M-x org-agenda followed by a and then R.
>>> The following debug trace immediately occurred.
>>>
>>> Please clue in the clueless.
>>> Thank you!
>>>
>>> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>>>   file-exists-p(nil)
>>>   org-check-agenda-file(nil)
>>>   org-agenda-prepare-buffers((nil))
>>>   org-dblock-write:clocktable((:name "clocktable" :link t :maxlevel 2
>>> :tstart 737122 :tend 737123 :scope agenda :indentation-column 0 :content
>>> "\n"))
>>>   org-update-dblock()
>>>   org-clock-get-clocktable(:link t :maxlevel 2 :tstart 737122 :tend
>>> 737123 :scope agenda)
>>>   apply(org-clock-get-clocktable (:link t :maxlevel 2 :tstart 737122
>>> :tend 737123 :scope agenda))
>>>   org-agenda-list(nil 737122 day nil)
>>>   (let nil (org-agenda-list 'nil 737122 'day nil))
>>>   eval((let nil (org-agenda-list 'nil 737122 'day nil)))
>>>   org-let(nil (org-agenda-list 'nil 737122 'day nil))
>>>   org-agenda-redo()
>>>   org-agenda-clockreport-mode()
>>>   funcall-interactively(org-agenda-clockreport-mode)
>>>   call-interactively(org-agenda-clockreport-mode nil nil)
>>>   command-execute(org-agenda-clockreport-mode)
>>>
>>>
>>> Emacs  : GNU Emacs 27.0.50 (build 3, x86_64-pc-linux-gnu, X toolkit,
>>> Xaw3d scroll bars)
>>>  of 2019-03-04
>>> Package: Org mode version 9.2.2 (release_9.2.2-245-g9d7b1e @
>>> /home/dortmann/src/git-org-mode/lisp/)
>>>
>>> current state:
>>> ==
>>> (setq
>>>  org-src-mode-hook '(org-src-babel-configure-edit-buffer
>>>          org-src-mode-configure-edit-buffer)
>>>  org-metadown-hook '(org-babel-pop-to-session-maybe)
>>>  org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
>>>  org-mode-hook '(#[0 "\300\301\302\303\304$\207"
>>>            [add-hook change-major-mode-hook org-show-all append local]
>>>            5]
>>>          #[0 "\300\301\302\303\304$\207"
>>>   

Re: [O] Bug: clocktable error in org-agenda [9.2.2 (release_9.2.2-245-g9d7b1e @ /home/dortmann/src/git-org-mode/lisp/)]

[Daniel Ortmann]

This is crazy!  After months of problems, I myself no longer can
reproduce this issue!  :-/

Comments welcome (Please!) ... but this issue no longer is actually a bug. 

On 3/4/19 3:22 PM, Daniel Ortmann wrote:
> Remember to cover the basics, that is, what you expected to happen and
> what in fact did happen.  You don't know how to make a good report?  See
>
>  
> https://urldefense.proofpoint.com/v2/url?u=https-3A__orgmode.org_manual_Feedback.html-23Feedback=DwIGaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=Dkq-B4wf3U4UeyggH34kSw8HWPy7CqI3u3RwPXz2f5o=4fSQsyYOysB0leNb80s58m3u_JCrMhGMzVXrgGispfw=_u3sTu0de7IKTb2RsyImTOaTAqX4pl-EiuT_gDXAtXA=
>
> Your bug report will be posted to the Org mailing list.
> 
>
> Since this problem has been occurring for a few months now, it's got to
> be something wrong in my configuration.
>
> In the org agenda, pressing R activates the clock report but pressing it
> again does not turn it off.  The same behavior occurs through the menu;
> clicking the view clock report checkbox turns the checkbox on and the
> clock report appears in the agenda ... but clicking it again does not
> turn the clock report off; it stays visible.
>
> To log the bug report I started with
> emacs -Q -l ~/minimal-org.el
> then ran M-x org-agenda followed by a and then R.
> The following debug trace immediately occurred.
>
> Please clue in the clueless.
> Thank you!
>
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>   file-exists-p(nil)
>   org-check-agenda-file(nil)
>   org-agenda-prepare-buffers((nil))
>   org-dblock-write:clocktable((:name "clocktable" :link t :maxlevel 2
> :tstart 737122 :tend 737123 :scope agenda :indentation-column 0 :content
> "\n"))
>   org-update-dblock()
>   org-clock-get-clocktable(:link t :maxlevel 2 :tstart 737122 :tend
> 737123 :scope agenda)
>   apply(org-clock-get-clocktable (:link t :maxlevel 2 :tstart 737122
> :tend 737123 :scope agenda))
>   org-agenda-list(nil 737122 day nil)
>   (let nil (org-agenda-list 'nil 737122 'day nil))
>   eval((let nil (org-agenda-list 'nil 737122 'day nil)))
>   org-let(nil (org-agenda-list 'nil 737122 'day nil))
>   org-agenda-redo()
>   org-agenda-clockreport-mode()
>   funcall-interactively(org-agenda-clockreport-mode)
>   call-interactively(org-agenda-clockreport-mode nil nil)
>   command-execute(org-agenda-clockreport-mode)
>
>
> Emacs  : GNU Emacs 27.0.50 (build 3, x86_64-pc-linux-gnu, X toolkit,
> Xaw3d scroll bars)
>  of 2019-03-04
> Package: Org mode version 9.2.2 (release_9.2.2-245-g9d7b1e @
> /home/dortmann/src/git-org-mode/lisp/)
>
> current state:
> ==
> (setq
>  org-src-mode-hook '(org-src-babel-configure-edit-buffer
>          org-src-mode-configure-edit-buffer)
>  org-metadown-hook '(org-babel-pop-to-session-maybe)
>  org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
>  org-mode-hook '(#[0 "\300\301\302\303\304$\207"
>            [add-hook change-major-mode-hook org-show-all append local]
>            5]
>          #[0 "\300\301\302\303\304$\207"
>            [add-hook change-major-mode-hook org-babel-show-result-all
>         append local]
>            5]
>          org-babel-result-hide-spec org-babel-hide-all-hashes)
>  org-archive-hook '(org-attach-archive-delete-maybe)
>  org-confirm-elisp-link-function 'yes-or-no-p
>  org-agenda-before-write-hook '(org-agenda-add-entry-text)
>  org-metaup-hook '(org-babel-load-in-session-maybe)
>  org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3
> "\n\n(fn ENTRY)"]
>  org-babel-pre-tangle-hook '(save-buffer)
>  org-tab-first-hook '(org-babel-hide-result-toggle-maybe
>           org-babel-header-arg-expand)
>  org-occur-hook '(org-first-headline-recenter)
>  org-cycle-hook '(org-cycle-hide-archived-subtrees
> org-cycle-show-empty-lines
>           org-optimize-window-after-visibility-change)
>  org-speed-command-hook '(org-speed-command-activate
>               org-babel-speed-command-activate)
>  org-dynamic-block-alist '(("columnview" . org-columns-insert-dblock)
>                ("clocktable" . org-clock-report))
>  org-confirm-shell-link-function 'yes-or-no-p
>  org-link-parameters '(("id" :follow org-id-open)
>            ("eww" :follow eww :store org-eww-store-link)
>            ("rmail" :follow org-rmail-open :store
>             org-rmail-store-link)
>            ("mhe" :follow org-mhe-open :store org-mhe-store-link)
>            ("irc" :follow org-irc-visit :store org-irc-store-link
>             :export or

[O] Bug: clocktable error in org-agenda [9.2.2 (release_9.2.2-245-g9d7b1e @ /home/dortmann/src/git-org-mode/lisp/)]

[Daniel Ortmann]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


Since this problem has been occurring for a few months now, it's got to
be something wrong in my configuration.

In the org agenda, pressing R activates the clock report but pressing it
again does not turn it off.  The same behavior occurs through the menu;
clicking the view clock report checkbox turns the checkbox on and the
clock report appears in the agenda ... but clicking it again does not
turn the clock report off; it stays visible.

To log the bug report I started with
emacs -Q -l ~/minimal-org.el
then ran M-x org-agenda followed by a and then R.
The following debug trace immediately occurred.

Please clue in the clueless.
Thank you!

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  file-exists-p(nil)
  org-check-agenda-file(nil)
  org-agenda-prepare-buffers((nil))
  org-dblock-write:clocktable((:name "clocktable" :link t :maxlevel 2
:tstart 737122 :tend 737123 :scope agenda :indentation-column 0 :content
"\n"))
  org-update-dblock()
  org-clock-get-clocktable(:link t :maxlevel 2 :tstart 737122 :tend
737123 :scope agenda)
  apply(org-clock-get-clocktable (:link t :maxlevel 2 :tstart 737122
:tend 737123 :scope agenda))
  org-agenda-list(nil 737122 day nil)
  (let nil (org-agenda-list 'nil 737122 'day nil))
  eval((let nil (org-agenda-list 'nil 737122 'day nil)))
  org-let(nil (org-agenda-list 'nil 737122 'day nil))
  org-agenda-redo()
  org-agenda-clockreport-mode()
  funcall-interactively(org-agenda-clockreport-mode)
  call-interactively(org-agenda-clockreport-mode nil nil)
  command-execute(org-agenda-clockreport-mode)


Emacs  : GNU Emacs 27.0.50 (build 3, x86_64-pc-linux-gnu, X toolkit,
Xaw3d scroll bars)
 of 2019-03-04
Package: Org mode version 9.2.2 (release_9.2.2-245-g9d7b1e @
/home/dortmann/src/git-org-mode/lisp/)

current state:
==
(setq
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
         org-src-mode-configure-edit-buffer)
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-mode-hook '(#[0 "\300\301\302\303\304$\207"
           [add-hook change-major-mode-hook org-show-all append local]
           5]
         #[0 "\300\301\302\303\304$\207"
           [add-hook change-major-mode-hook org-babel-show-result-all
        append local]
           5]
         org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3
"\n\n(fn ENTRY)"]
 org-babel-pre-tangle-hook '(save-buffer)
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
          org-babel-header-arg-expand)
 org-occur-hook '(org-first-headline-recenter)
 org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-show-empty-lines
          org-optimize-window-after-visibility-change)
 org-speed-command-hook '(org-speed-command-activate
              org-babel-speed-command-activate)
 org-dynamic-block-alist '(("columnview" . org-columns-insert-dblock)
               ("clocktable" . org-clock-report))
 org-confirm-shell-link-function 'yes-or-no-p
 org-link-parameters '(("id" :follow org-id-open)
           ("eww" :follow eww :store org-eww-store-link)
           ("rmail" :follow org-rmail-open :store
            org-rmail-store-link)
           ("mhe" :follow org-mhe-open :store org-mhe-store-link)
           ("irc" :follow org-irc-visit :store org-irc-store-link
            :export org-irc-export)
           ("info" :follow org-info-open :export org-info-export
            :store org-info-store-link)
           ("gnus" :follow org-gnus-open :store org-gnus-store-link)
           ("docview" :follow org-docview-open :export
            org-docview-export :store org-docview-store-link)
           ("bibtex" :follow org-bibtex-open :store
            org-bibtex-store-link)
           ("bbdb" :follow org-bbdb-open :export org-bbdb-export
            :complete org-bbdb-complete-link :store
            org-bbdb-store-link)
           ("w3m" :store org-w3m-store-link) ("file+sys")
           ("file+emacs") ("doi" :follow org--open-doi-link)
           ("elisp" :follow org--open-elisp-link)
           ("file" :complete org-file-complete-link)
           ("ftp" :follow
            (lambda (path) (browse-url (concat "ftp:" path
           ("help" :follow org--open-help-link)
           ("http" :follow
            (lambda (path) (browse-url (concat "http:" path
 

Re: [O] recent org-mode changes: completion of repeated tasks reports "10 repeater intervals were not enough to shift date past today"

[Daniel Ortmann]

Another task which gives the same message with SCHEDULED instead of
DEADLINE; this one also uses "++" to repeat dates but with no "-0d". 
The result looks correct; only the message is bothersome.

I replied to the message 'y' twice and then 'n' to test the resulting
change.  Changes look fine:





>From *Messages*:
10 repeater intervals were not enough to shift date past today. 
Continue? (y or n) y [2 times]
10 repeater intervals were not enough to shift date past today. 
Continue? (y or n) n
And later
Entry repeats: SCHEDULED: <2019-01-17 Thu 07:50 .+1d> Plain: [2019-01-17
Thu 07:50 .+1d] Plain: [2019-01-17 Thu 07:50 .+1d]


Here is the task:

** TODO one-on-one   :meeting:
   SCHEDULED: <2019-01-23 Wed 13:30-14:00 ++1w>
   :PROPERTIES:
   :LAST_REPEAT: [2019-01-17 Thu 10:39]
   :END:
   :LOGBOOK:
   - State "CANCELED"   from "TODO"   [2019-01-17 Thu 10:39]
   - State "DONE"   from "TODO"   [2019-01-09 Wed 14:14]
...
   :END:


On 1/15/19 8:43 AM, Bernt Hansen wrote:
> Daniel Ortmann  writes:
>
>> No other tasks.  Here is the complete text with only one url removed:
>>
>> * TODO [#C] p6 time entry
>>   DEADLINE: <2019-01-18 Fri ++1w -0d>
>>   :PROPERTIES:
>>   :LAST_REPEAT: [2019-01-11 Fri 17:03]
>>   :END:
>>   :LOGBOOK:
>>
> 
>
>> On 1/13/19 10:12 AM, Bernt Hansen wrote:
>>
>> Daniel Ortmann  writes:
>>
>> I have a weekly scheduled task with ...
>>   DEADLINE: <2019-01-18 Fri ++1w -0d>
>> 
>> Recently, when I complete the task it reports the following:
>> 
>> Clock stopped at [2019-01-11 Fri 17:03] after 0:05
>> 10 repeater intervals were not enough to shift date past today. 
>> Continue? (y or n) n
>> 
>> Thoughts?
>> 
>> Hi Daniel,
>> 
>> Do you have some other repeating timestamp buried somewhere in that
>> task?  It is probably moving that one forward and it is the one that
>> needs more than 10 repeats to become current.
>> 
>> There was a recent change that updates all repeating timestamps in the
>> task.
>> 
>> Regards,
>> Bernt
> Sorry I can't reproduce what you are seeing.
>
> Regards,
> Bernt
>
>

[O] recent org-mode changes: completion of repeated tasks reports "10 repeater intervals were not enough to shift date past today"

[Daniel Ortmann]

I have a weekly scheduled task with ...
  DEADLINE: <2019-01-18 Fri ++1w -0d>

Recently, when I complete the task it reports the following:

Clock stopped at [2019-01-11 Fri 17:03] after 0:05
10 repeater intervals were not enough to shift date past today. 
Continue? (y or n) n

Thoughts?

[O] recent org-mode changes: completion of repeated tasks cause rewriting of LOGBOOK 'Rescheduled from' entries

[Daniel Ortmann]

I have a daily scheduled task with ...
  SCHEDULED: <2019-01-11 Fri 07:50 .+1d>

Recently, when I complete the task it not only moves the schedule to the
next day
... but it also /_rewrites_/ all of the "Rescheduled from ..." entries
in the LOGBOOK.

For example,
  - Rescheduled from "[2019-01-11 Fri 07:50 .+1d]" on [2019-01-02 Wed 10:54]
  - Rescheduled from "[2019-01-11 Fri 07:50 .+1d]" on [2018-12-31 Mon 11:50]
  - Rescheduled from "[2019-01-11 Fri 07:50 .+1d]" on [2018-12-16 Sun 19:29]
  - Rescheduled from "[2019-01-11 Fri 07:50 .+1d]" on [2018-12-03 Mon 10:49]
 etc.

Those previous LOGBOOK entries no longer are available; they are wiped
out by new task completions.