Re: 9.5: coping with loss of ditaa.jar
> Jarmo Hurri writes: > 3. Copy ditaa.jar from previous version of org. Works in the short > run, but I do not think we want to advocate this: "We took > ditaa.jar out of org, so you will want to download an earlier > version of org to make ditaa work." Not true. I use Org mode version 9.5 (release_9.5-91-gf5faff) with a previous org-mode ditaa.jar and have no issues.
org-persist
After today's pull of org-mode I get the warning that org-persist cannot read its index. This is an entirely new warning (as of today) and I assume is the result of the recent commits in org-persist. Please, can this be corrected. The warning is irritating, especially so since I do not use org-persist and have no wish to do so. Best wishes, Colin Baxter.
Re: org-persist
>>>>> Ihor Radchenko writes:
> Colin Baxter ๐บ writes:
>> After today's pull of org-mode I get the warning that org-persist
>> cannot read its index. This is an entirely new warning (as of
>> today) and I assume is the result of the recent commits in
>> org-persist.
>> Please, can this be corrected. The warning is irritating,
>> especially so since I do not use org-persist and have no wish to
>> do so.
> Fixed.
Thank you. I cloned org-mode afresh and got the same warning during
'make' - I presume that too is now fixed.
> Note that org-persist is enabled by default together with
> org-element-cache. You can indeed disable it,
How can I do this?
Best wishes,
Re: org-persist
>>>>> Ihor Radchenko writes: r> Colin Baxter ๐บ writes: >> Thank you. I cloned org-mode afresh and got the same warning >> during 'make' - I presume that too is now fixed. r> The warning should never appear now. I removed it completely. >> > Note that org-persist is enabled by default together with > >> org-element-cache. You can indeed disable it, >> >> How can I do this? r> If you want to disable cache persistence, just set r> `org-element-cache-persistent' to nil. It is documented in r> ORG-NEWS. If you find ORG-NEWS not clear, please let me know. I r> will try to improve the news record. Thank you. r> If you want to disable cache completely, you can set r> `org-element-use-cache' to nil. However, I am hoping to make r> cache enabled all the time in future. If you have specific r> reasons to avoid org-element-cache, may you share them? I may not have understood things fully, but it seems that the org-persist directory is set only by the org-persist-path. Unfortunately, the resulting org-persist directory in ~/.cache is no good for me since I daily clear out my ~/.cache using bleachbit. I can't find a way of changing org-persist-path and grep finds the variable only in ORG-NEWS. Best wishes, Colin.
Re: org-persist
>>>>> Ihor Radchenko writes:
> Colin Baxter ๐บ writes:
>> I may not have understood things fully, but it seems that the
>> org-persist directory is set only by the
>> org-persist-path. Unfortunately, the resulting org-persist
>> directory in ~/.cache is no good for me since I daily clear out
>> my ~/.cache using bleachbit. I can't find a way of changing
>> org-persist-path and grep finds the variable only in ORG-NEWS.
> Oops. It was my bad (fixed now). Should be
> `org-persist-directory'. You can set it to other location in your
> init.el.
Ok, thanks - that works - I used ~/.emacs.d/org-persist/. It might be
worth mentioning that the user should not create the
org-persist-directory himself. I did this originally (mkdir
~/.emacs.d/org-persist , touch ~/.emacs.d/org-persist/index )
and got various parsing error messages. Everything worked fine after I
deleted my own handiwork and left the directory creation to org-persist.
I had originally set org-element-use-cache to nil because I remember
reading somewhere that the nil setting would help prevent emacs from
hanging in org-mode.
I'll certainly begin using org-persist and see what happens.
Thanks for your help.
Best wishes,
Colin.
Re: org-persist - bug report
> Ihor Radchenko writes: > Alastair Burt writes: >> Hi there, >> >> I couldn't find an issue-tracking system for org-mode as they >> have for projects on github. So I'm emailing you directly. > Thanks! The bug reporting for Org mode is by email. You can send > email to Org mailing list at emacs-orgmode@gnu.org (also, see "1.4 > Feedback" section of Org manual or https://orgmode.org/ The issue > tracker is derived from the email and can be found online in > https://updates.orgmode.org/ > I am CCing this message the mailing list. >> I just upgraded my org-mode to the latest version in >> git. Whenever I visited a certain org file, my Emacs became >> unusable. Any attempt to use M-x (execute-extended-command) >> resulted in max-specpdl-size errors as did using C-x C-c to exit >> Emacs. Some but not all of the errors mentioned "Error during >> file deserialization". After an hour's debugging, I tracked this >> down to org-persist. Deleting "~/.cache/org-persist" made the >> problem go away. I just stumbled on this error myself. The culprit was a agenda file - I mean, an org-mode file called by org-agenda. I'll pursue further when I've got time (not today!) Best wishes, Colin.
Re: org-persist - bug report
>>>>> Ihor Radchenko writes:
> Colin Baxter ๐บ writes:
>> >> I just upgraded my org-mode to the latest version in >>
>> git. Whenever I visited a certain org file, my Emacs became >>
>> unusable. Any attempt to use M-x (execute-extended-command) >>
>> resulted in max-specpdl-size errors as did using C-x C-c to exit
>> >> Emacs. Some but not all of the errors mentioned "Error during
>> >> file deserialization". After an hour's debugging, I tracked
>> this >> down to org-persist. Deleting "~/.cache/org-persist" made
>> the >> problem go away.
>>
>> I just stumbled on this error myself. The culprit was a agenda
>> file - I mean, an org-mode file called by org-agenda. I'll pursue
>> further when I've got time (not today!)
> If you see the error again, can you also try with the following?
> (setq org-element--cache-self-verify 'backtrace)
> (setq org-element--cache-self-verify-frequency 1)
I set the above in my ~/.emacs
> If a warning appears, backtrace could be helpful. If not, it
> should be something to do with org-element-cache-map.
The max-specpdl-size error has happened again when I tried to add a note
to an agenda item. Emacs hung and had to be killed. The debugger buffer
was empty and the only other information given was the message:
mapc: Lisp nesting exceeds `max-lisp-eval-depth'
I hope this helps.
Best wishes,
Colin.
Re: org-persist - bug report
>>>>> Max Nikulin writes: > On 21/10/2021 02:04, Colin Baxter ๐บ wrote: >> >> The max-specpdl-size error has happened again when I tried to add >> a note to an agenda item. Emacs hung and had to be killed. The >> debugger buffer was empty and the only other information given >> was the message: >> >> mapc: Lisp nesting exceeds `max-lisp-eval-depth' > Ihor, I have seen your instructions for more debug info, but I > have not tried them yet. In the meanwhile I have tracked my > problem down to to the following minimal file > --- >8 --- > #+begin_example org ,* H #+end_example > --- 8< --- > M-x org-lint > Debugger entered--Lisp error: (error "Variable binding depth > exceeds max-specpdl-size") ... org-filename-concat I can reproduce that. Then emacs just hangs. I have the latest org-mode. Best wishes, Colin.
Re: org-persist - bug report
> Ihor Radchenko writes: > It was malformed add-hook call. Fixed in 5315773e8. Great! I've pulled org-mode and I can confirm I no longer see my org-persist errors. Excellent. I'm looking at the vc-diff buffer and it's amazing that such a small omission has such a major effect. Best wishes, Colin.
org-element-cache-reset
Hello, Assuming such a question make sense, how do I manually reset org-persist for all org buffers? It's not clear to me if doing M-x org-element-cache-reset is sufficient. Thanks. Best wishes,
Re: org-element-cache-reset
>>>>> Ihor Radchenko writes:
> Colin Baxter ๐บ writes:
>> Hello,
>>
>> Assuming such a question make sense, how do I manually reset
>> org-persist for all org buffers? It's not clear to me if doing
>> M-x org-element-cache-reset is sufficient.
> You can reset cache in all open Org buffers via M-:
> (org-element-cache-reset 'all)
> The new cache will overwrite the old cache for the open buffers
> after you close Emacs (or close all the Org buffers).
> If you want to remove the cache completely, just delete the cache
> folder before running Emacs.
> If you think that more options should be provided, let me know.
Thank you for the information.
Best Wishes,
Colin.
An org-persist convert :-)
org-persist warning when archiving
Hello, Whenever I archive a DONE item via 'C-c C-x C-a' I get the warning: Warning (emacs): org-element--cache: Unregistered buffer modifications detected. Resetting. The archiving is successful, but I keep getting the warning and therefore wonder if there is some org-persist or cache setting that needs to be adjusted. Best wishes, Colin Baxter.
Re: org-persist warning when archiving
>>>>> Colin Baxter ๐บ writes: > Hello, Whenever I archive a DONE item via 'C-c C-x C-a' I get the > warning: > Warning (emacs): org-element--cache: Unregistered buffer > modifications detected. Resetting. > The archiving is successful, but I keep getting the warning and > therefore wonder if there is some org-persist or cache setting > that needs to be adjusted. Thinking a little more about this, I have not yet had a chance of archiving an item in a new emacs session. It may be that the warning is temporary to the first session and will disappear if and when I archive a DONE item in a new session. Colin.
Re: org-persist warning when archiving
Hi Thor,
>>>>> Ihor Radchenko writes:
> Colin Baxter ๐บ writes:
>> > Hello, Whenever I archive a DONE item via 'C-c C-x C-a' I get
>> the > warning:
>>
>> > Warning (emacs): org-element--cache: Unregistered buffer >
>> modifications detected. Resetting.
>>
>> > The archiving is successful, but I keep getting the warning and
>> > therefore wonder if there is some org-persist or cache setting
>> > that needs to be adjusted.
>>
>> Thinking a little more about this, I have not yet had a chance of
>> archiving an item in a new emacs session. It may be that the
>> warning is temporary to the first session and will disappear if
>> and when I archive a DONE item in a new session.
> This message always indicates some problem. However, I cannot
> reproduce what you observe on my side. Did you try with emacs -Q?
> Also, you might not be running the latest Org. I have extended
> this warning in recent commits.
I'm running Org mode version 9.5 (release_9.5-178-gcf8906) on
emacs-28.0.60. Unfortunately, I could not apply your patch ('patch would
not apply') using either 'git apply /path/to/patch' or 'git a
/path/to/patch'. I then tried manually to apply it, but that produced
errors when I ran the command org-agenda. I may have messed up the
manual apply so I'll try again tonight.
Best wishes,
Colin.
Re: org-persist warning when archiving
Hi Ihor,
>>>>> Ihor Radchenko writes:
> Colin Baxter ๐บ writes:
>> I'm running Org mode version 9.5 (release_9.5-178-gcf8906) on
>> emacs-28.0.60. Unfortunately, I could not apply your patch
>> ('patch would not apply') using either 'git apply /path/to/patch'
>> or 'git a /path/to/patch'.
> Oops. Try the updated patch. The old one was based on my working
> branch.
Ok, I now applied your patch and remade org-mode. Unfortunately, I don't
see any change. I still get the warning on all the archive commands:
org-agenda-archive-default, org-agenda-archive and
org-agenda-archive-default-with-confirmation. I've appended the warning
for the latter command.
--8<---cut here---start->8---
Warning (emacs): org-element--cache: Unregistered buffer modifications
detected. Resetting.
If this warning appears regularly, please report it to Org mode mailing list
(M-x org-submit-bug-report).
The buffer is: todo.org_archive
Current command: org-agenda-archive-default-with-confirmation Disable showing
Disable logging
Warning (emacs): org-element--cache: Unregistered buffer modifications
detected. Resetting.
If this warning appears regularly, please report it to Org mode mailing list
(M-x org-submit-bug-report).
The buffer is: todo.org_archive
Current command: org-agenda-archive-default-with-confirmation Disable showing
Disable logging
--8<---cut here---end--->8---
I've not tried it on emacs -Q yet. For that, do I need to start afresh
and first delete the org-persist-directory?
Best wishes,
Colin.
Re: org-persist warning when archiving
>>>>> Ihor Radchenko writes:
> Colin Baxter ๐บ writes:
>> Ok, I now applied your patch and remade org-mode. Unfortunately,
>> I don't see any change. I still get the warning on all the
>> archive commands: org-agenda-archive-default, org-agenda-archive
>> and org-agenda-archive-default-with-confirmation. I've appended
>> the warning for the latter command.
> Thanks for testing! My guess was incorrect and I am still unable
> to reproduce using agenda (previously, I just tried archiving from
> inside Org buffer).
>> --8<---cut here---start->8---
>> Warning (emacs): org-element--cache: Unregistered buffer
>> modifications detected. Resetting. If this warning appears
>> regularly, please report it to Org mode mailing list (M-x
>> org-submit-bug-report). The buffer is: todo.org_archive Current
>> command: org-agenda-archive-default-with-confirmation Disable
>> showing Disable logging Warning (emacs): org-element--cache:
>> Unregistered buffer modifications detected. Resetting. If this
>> warning appears regularly, please report it to Org mode mailing
>> list (M-x org-submit-bug-report). The buffer is:
>> todo.org_archive Current command:
>> org-agenda-archive-default-with-confirmation Disable showing
>> Disable logging --8<---cut
>> here---end--->8---
>>
>> I've not tried it on emacs -Q yet. For that, do I need to start
>> afresh and first delete the org-persist-directory?
> You can simply start from emacs -Q + a new file (the new file will
> not have any cache). In my testing, I just created a new org file,
> opening it from emacs -Q -L /path/to/latest/org/lisp -l org
> /path/to/the/new/file.org Then, I added a new TODO heading, opened
> todo agenda for current buffer, and tried to archive the heading
> from agenda. No warning on my side.
> You can repeat my steps and see what happens. If nothing, you may
> try archiving from your todo.org (but still using emacs -Q). If
> still nothing, it may be something about your config.
The warnings may be due to my use of ATTACH directories in agenda
files. I don't attach by id but prefer to use a directory for each node
and to link attachments to other files rather than copy. The attachments
also include other org-mode files. I should have time this weekend
to check this and to confirm if my configuration is responsible.
Best wishes,
Colin.
Re: org-persist warning when archiving
I have now discovered what is causing the org-persist warnings. It is because my org-agenda files have local variables present. If I remove the local variables, the warnings disappear. Best wishes, Colin.
Re: org-persist warning when archiving
Hi Ihor, My ECM is as follows. I'm using GNU-Linux and emacs-28.0.60. 1. Delete any existing org-persist directory. 2. mkdir ~/a 3. emacs -Q 4. Evaluate path to latest org-mode. I enter (add-to-list 'load-path (expand-file-name "~/path/to/git/org-mode/lisp")) in the scratch buffer and do C-j. 5. C-x C-f ~/test.org 6. Enter the following in test.org: * Test :PROPERTIES: :CATEGORY: Test :DESCRIPTION: Test :ARCHIVE: ~/a/%s_archive::datetree/* Test :LOG_INTO_DRAWER: LOGDRAWER :END: ** TODO archive test SCHEDULED: <2021-10-29 Fri> # Local Variables: # eval: (setq org-adapt-indentation t) # End: 7. Same the file and close down emacs in order to populate the or-persist directory. 8. emacs -Q 9. Evaluate path to latest org-mode, as before. 10. Open ~/test.org and make the TODO as DONE. 11. Save ~/test.org 12. I think I then closed down emacs and re-launched emacs to ensure org-persist noted the changes. I don't think this step is necessary. 13. With cursor on DONE do C-c C-x C-a to archive the item. 14. Item is archived to ~/a but with the warning: --8<---cut here---start->8--- Warning (emacs): org-element--cache: Unregistered buffer modifications detected. Resetting. If this warning appears regularly, please report it to Org mode mailing list (M-x org-submit-bug-report). The buffer is: test.org_archive Current command: org-archive-subtree-default Disable showing Disable logging Warning (emacs): org-element--cache: Unregistered buffer modifications detected. Resetting. If this warning appears regularly, please report it to Org mode mailing list (M-x org-submit-bug-report). The buffer is: test.org_archive Current command: org-archive-subtree-default Disable showing Disable logging Warning (emacs): org-element--cache: Unregistered buffer modifications detected. Resetting. If this warning appears regularly, please report it to Org mode mailing list (M-x org-submit-bug-report). The buffer is: test.org_archive Current command: org-archive-subtree-default Disable showing Disable logging --8<---cut here---end--->8--- 15. If the test is repeated but with :ARCHIVE: ~/a/%s_archive::datetree/* Test removed. Then we get the warning --8<---cut here---start->8--- Warning (emacs): org-element--cache: Unregistered buffer modifications detected. Resetting. If this warning appears regularly, please report it to Org mode mailing list (M-x org-submit-bug-report). The buffer is: test.org_archive Current command: org-archive-subtree-default Disable showing Disable logging --8<---cut here---end--->8--- It would appear that the local variables and the archive path are both conspiring to produce the warning. Best wishes, Colin.
Re: org-persist warning when archiving
>>>>> Ihor Radchenko writes:
> Colin Baxter ๐บ writes:
>> Hi Ihor,
>>
>> My ECM is as follows. I'm using GNU-Linux and emacs-28.0.60.
> Thanks! I was able to reproduce on my system. Should be fixed on
> main via 9f87b1cc3.
Yes, I can confirm the problem is fixed for me. Great!
Thank you.
Best wishes,
Colin.
Re: C-c . no longer inserts org-time-stamp (after upgrade to 9.5)
> Michael Maurer writes: > Subject line says it all, I upgraded to 9.5 two days ago and > everything seemed to work, but today I fire up the PC and C-c . no > longer is bound to anything. I guess I could custom-bind it in my > config, but I'm more interested in why it's happening. The last > package I installed after the upgrade was undo-fu and > undo-fu-sessions, but I dont' think they are involved. They could be. I don't have those packages and C-c . works for me and I am running the latest git pull from org-mode. You might also have multiple org files present. Best wishes.
org-diary
Hello,
I have this
#+begin_src elisp
&%%(org-diary :deadline* :timestamp :scheduled*)
#+end_src
at line 9 in my main diary file ~/.emacs.d/diary/main. It worked well up
until recently (a week or so, I think). Now I get the following warning:
--8<---cut here---start->8---
Error (diary): Bad diary sexp at line 9 in ~/.emacs.d/diary/main:
(org-diary :deadline* :timestamp :scheduled*)
Error: (search-failed
"\\]+[0-9]\\{1,2\\}:[0-9]\\{2\\}[0-9+:hdwmy/ .-]*\\)>")
--8<---cut here---end--->8---
There seems no obvious error in either the agenda or calendar displays
so I'd be grateful for suggestions as to where to look for the cause of
the warning.
Best wishes,
Colin Baxter.
Re: org-diary
>>>>> Eric S Fraga writes: > On Wednesday, 3 Nov 2021 at 06:43, Colin Baxter ๐บ wrote: >> I have this >> >> #+begin_src elisp &%%(org-diary :deadline* :timestamp >> :scheduled*) #+end_src > I cannot help you directly but I do note that my equivalent entry > in my Emacs diary file is subtly different: > %%(org-diary :scheduled :timestamp) ~/s/notes/diary.org > No &, no *s, and a file name at the end. Having said this, I must > admit that I cannot find any documentation on the format of this > line in the info manual. Maybe it's hiding... Thanks Eric. You have reminded me about the file name. I don't have a file name at the end because I want all my 5 agenda files searched. However, by entering each file in turn I can now identify the particular agenda file that's causing the warning. I don't see anything immediately wrong with it, but it contains multiple schedules with + and - days. I suspect the problems lies somewhere there. Thanks again - a great post that jogged my memory. Best wishes, Colin.
Re: org-diary
> Eric S Fraga writes: > On Thursday, 4 Nov 2021 at 18:21, Michael Maurer wrote: >> Oh. I assumed >> >> #+begin_src elisp &%%(org-diary :deadline* :timestamp >> :scheduled*) #+end_src >> >> is an org-babel code block. > Yes but I think that was just for the purposes of highlighting the > sexp in the email/post. Indeed, that was the purpose. I am the op and I apologise if my attempt to highlight my post caused confusion. Perhaps I stick to --8<---cut here---start->8--- M-x message-mark-inserted-region --8<---cut here---end--->8--- for highlighting. Best wishes.
Re: Bibliographies on export with ox-context and ox-epub
> Denis Maier writes: > Are you already on org 9.5? Looks like your still using the "old" > org-ref links. > The following mwe might get you started: > %% > #+title: Citation tests #+cite_export: csl > #+bibliography: test.bib > [cite: @doe 45] > [cite/text: @doe 45] > #+print_bibliography: > %% > This will use the new citation export framework. citeproc-el needs > to be installed for this to be working. Where is citeproc.el? I'm using Org mode version 9.5.1 (release_9.5.1-194-gd82936) and I don't see it. Best wishes,
Re: Bibliographies on export with ox-context and ox-epub
>>>>> Eric S Fraga writes: > On Wednesday, 24 Nov 2021 at 09:59, Colin Baxter ๐บ wrote: >> Where is citeproc.el? I'm using Org mode version 9.5.1 >> (release_9.5.1-194-gd82936) and I don't see it. > It's a separate Emacs package which you will need to install. > It's available on MELPA. The csl citation engine depends on it. > It is not part of org itself. Ah, I see. Tthanks again Eric Best wishes,
Re: Is M-j broken for you in Org on Emacs 27 and 28?
> Richard Lawrence writes: > Hi Org community, Some questions for those of you on Emacs 27 and > 28: > Does M-j in an org-mode buffer do what you expect? Does it throw > an error? What function is M-j bound to in Org? > Backstory: > I have long been on Emacs 26.3 (in Debian stable) but recently > decided to try a newer Emacs from GNU Guix. I immediately ran into > an issue, and now I'm trying to figure out if it's a bug, and if > so where to file it: in both Emacs 27.2 and 28.0.50, typing M-j in > an Org buffer throws (wrong-type-argument char-or-string-p nil) > The source of this problem appears to be that the keybinding for > M-j changed between Emacs 26 and 27. In Emacs 26 it calls > indent-new-comment-line. In Emacs 27 and 28 it calls > default-indent-new-line, and the call stack look like: > insert-before-markers-and-inherit(nil) > org-comment-line-break-function(nil) default-indent-new-line() > funcall-interactively(default-indent-new-line) > call-interactively(default-indent-new-line nil nil) > command-execute(default-indent-new-line) > The error arises because insert-before-markers-and-inherit cannot > accept nil (the value of fill-prefix in this context). > I see this error in emacs -q with both Emacs 27 and 28 from Guix. > After some investigation, the functions involved here don't appear > to have changed at all recently (though see [1]); just the > binding. This leads me to ask: why hasn't this been discovered > already? Which leads me to wonder if I am using M-j in some > non-standard way. > Some time in the distant past, I internalized the idea that M-j is > a better way to type a newline because (a) it doesn't involve a > pinky reach and (b) in most contexts in Emacs, it is more likely > to "do what I mean" than RET is. In particular, it continues > comments and indents properly. (I am also an evil-mode user and > there is probably some part of my brain that thinks "M-j is like j > for insert mode".) But maybe that was always wrong, and the > recently changed binding is just an indication that I was not > using M-j as intended. > So which is it? Is this a bug in Emacs, in Org, or in my ingrained > typing habits? Many thanks for your advice. > -- Best, Richard > [1] There is a commit which changed default-indent-new-line in > August of this year, but the changes don't seem relevant to the > error I'm seeing, since I also see it in Emacs 27.2: > https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=b41f31d2b60269bd0e7addd1081f3738f91e76bc I confirm that it also appears broken to me in emacs-27.2, with the same error as you found. I have never noticed it before, possibly because I use C-j rather than M-j. Best wishes,
Re: Is M-j broken for you in Org on Emacs 27 and 28?
> Richard Lawrence writes: > Tim Cross writes: >> I'm running Emacs 28 and cannot reproduce the issue you observe. > Hmm, the plot thickens! >> Running emacs -Q I find M-j is bound to >> >> M-j runs the command default-indent-new-line (found in >> global-map), which is an interactive compiled Lisp function in >> โsimple.elโ. > I definitely see the error in emacs -Q with Indeed, so do I with emacs -Q. I get the error message with emacs-27.2, emacs-28.0.50 and 29.0.50. I'm afraid the nuances of line indenting in org-mode have always been a black art to me. I stick to C-j because I've found it works for me in most cases. Best wishes, Colin Baxter.
Re: [BUG] clocktable :inherit-props does not respect global property setting [9.4.6 (9.4.6-12-gdcc3a8-elpa @ /home/jet/.config/emacs/elpa/org-20210823/)]
Hello Jeff You clock table works for me, including your missing rate of 150. I attach a screen shot. By the way, you have a ":inherit-props t" which is not on the #+BEGIN: clocktable line. I assume that has been corrupted in the email formatting. Best wishes
Clocktable parameters
Hello, I find the differences between the variables (1) org-clocktable-defaults (2) org-agenda-clockreport-parameter-plist hard to understand. Ok, (1) seems reasonably clear. It's described in `info' (there's no doc-string). The variable (2) confuses me. According to its doc string (there's no `info' mention) it gives parameters for a clock table in the daily and weekly agendas. How is that different from (1)? Am I correct in thinking (1) is primarily for a clock table not associated with the agenda? Quite how such a clocktable would arise is unclear to me. I would appreciate some pointers or a reference - thank you. Best wishes, Colin Baxter.
Re: [BUG] clocktable :inherit-props does not respect global property setting [9.4.6 (9.4.6-12-gdcc3a8-elpa @ /home/jet/.config/emacs/elpa/org-20210823/)]
>>>>> Jeff Trull writes: > Confirmed, after updating org it now works! Thanks for your help. > On Tue, Nov 30, 2021 at 1:07 AM Colin Baxter ๐บ wrote: >> Hello Jeff >> >> You clock table works for me, including your missing rate of >> 150. I attach a screen shot. >> >> By the way, you have a ":inherit-props t" which is not on the >> #+BEGIN: clocktable line. I assume that has been corrupted in the >> email formatting. >> >> Best wishes >> >> Excellent! You might be interested in this post in https://www.adventuresinwhy.com/post/org-mode-timekeeping/ It includes a formula for inserting the total billing amount in the clock table, calculated from the hourly rate. It works very nicely. Best wishes,
org-element-cache warning even when off
Hello, I have #+begin_src emacs-lisp (setq org-element-use-cache nil) (setq org-element-cache-persistent nil) #+end_src Yet when editing by hand a time string in a today habit I get the warning: --8<---cut here---start->8--- Warning (org-element-cache): org-element--cache: Cache corruption detected in todo.habits.org::539. Resetting. The error was: (error "Not an Org time string: <2021-12-0 Fri .+1d") Backtrace: nil --8<---cut here---end--->8--- I do not have an org-persist cache present. So I wonder where is the cache that I am supposedly corrupting. Best wishes Colin Baxter.
Re: org-element-cache warning even when off
>>>>> Ihor Radchenko writes:
> Colin Baxter ๐บ writes:
>> I do not have an org-persist cache present. So I wonder where is
>> the cache that I am supposedly corrupting.
> That warning is shown when org-element--parse-to throws an error
> (the parser fails). Apparently, there is some problem with Org
> parser.
>> Warning (org-element-cache): org-element--cache: Cache corruption
>> detected in todo.habits.org::539. Resetting.
> Can you try to copy the file text around 539 buffer point into
> separate Org file and check if you are seeing this kind of error
> there?
I have done this but now do not see any warning. Further, I now don't
seem to be able to re-produce the issue at all. It could that the
original warning was spurious and reflected some stale state. I did have
multiple emacsen open at the time.
I normally have org-persist on, but occasionally I need to do multiple
edits on an agenda file. On those occasions, I switch org-persist off
and move its cache out of the way in order to avoid cache corruption
warnings and to keep the syntax highlighting. I will look out for any
cache warnings if I edit any agenda files by hand again.
Best wishes,
Colin Baxter.
Re: [BUG] Plain capture template clocks into following headline instead of given olp [9.5.1 (release_9.5.1-15-gdb4805 @ /usr/share/emacs/29.0.50/lisp/org/)]
Hello Michael,
> Michael Eliachevitch writes:
> Hello, I found a potential bug in org which I can reproduce with a
> minimal configuration.
> I added some org-capture templates purely for clocking into tasks
> via the capture-menu. These capture templates are for things I
> want to time-track but don't want to create a special entry for
> (like eating and breaks), so I used the `plain' type with an empty
> `""' template hoping it would clock into the given olp:
> (setq org-capture-templates '(( "c" "clock into") ("cu"
> "Unintended" plain (file+olp "~/org/clock_test.org" "Time sinks"
> "Unintended") "" :clock-in t :clock-keep t :immediate-finish t)
> ("ce" "Eating" plain (file+olp "~/org/clock_test.org" "Time sinks"
> "Eating") "" :clock-in t :clock-keep t :immediate-finish t)))
> My `clock_test.org' has the following headings:
> * Time sinks ** Unintended ** Eating
This is amazing. I have run into exactly the same problem. I was
wondering whether to report it!
Oh, and I can reproduce the bug with your ECM.
Thanks for reporting it.
Best wishes,
Colin Baxter.
signature.asc
Description: PGP signature
Re: [BUG] Plain capture template clocks into following headline instead of given olp [9.5.1 (release_9.5.1-15-gdb4805 @ /usr/share/emacs/29.0.50/lisp/org/)]
Hello Michael, > Michael Eliachevitch writes: > Hello Colin, >> This is amazing. I have run into exactly the same problem. I was >> wondering whether to report it! >> >> Oh, and I can reproduce the bug with your ECM. > Glad that I'm not alone. When you say you ran into this, is this > something that appeared to you in a recent org-version for > existing capture templates which worked in older versions? Or is > this a behavior that has been always there for capture-templates > with :clock-in? A couple of night ago, I thought I'd try experimenting with my org-capture setup. I normally have a menu with single letter choices and no hierarchy. I wrote a couple of lines, very similar to yours, but couldn't get it to work. I thought it simply indicative of my ignorance of lisp (which is profound!) and abandoned the experiment. I use org-mode version 9.5.1 and I got the same results with emacs-28.0.90, 29.0.50 and (I think) 27.2. > When I have time I might try if I can hack something to fix this, > but not sure if I have time as I'm quite busy with my PhD > currently. Btw, I'm not sure what the procedure following the bug > report will be, as I'm quite new here on the mailing list and am > still more used to working with github-issues etc, but I guess > patience is key in an open source project. If you get no response on this org-mode list, perhaps re-submit it as a normal emacs bug (M-x report-emacs-bug ). Best wishes, Colin. signature.asc Description: PGP signature
Re: [BUG] Plain capture template clocks into following headline instead of given olp [9.5.1 (release_9.5.1-15-gdb4805 @ /usr/share/emacs/29.0.50/lisp/org/)]
>>>>> Ihor Radchenko writes:
> Colin Baxter ๐บ writes:
>> If you get no response on this org-mode list, perhaps re-submit
>> it as a normal emacs bug (M-x report-emacs-bug ).
> That's not a good idea. org-mode related staff is just forwarded
> back to this list (but not even always).
Ah, I didn't know that - thanks.
> Just wait a bit until someone get free time to look into your
> report.
Future TODOs with notes appear prematurely
Hello, A TODO item scheduled for a future date ordinarily does not appear in today's agenda. However, this is not the case if the TODO has a note dated today in its log drawer. The TODO item is now visible in today's agenda, even though it's scheduled for the future. If this isn't a bug then how can I keep the TODO item hidden until its scheduled date? Best wishes, Colin Baxter.
Re: Future TODOs with notes appear prematurely
>>>>> Samuel Wales writes: > a guess from everything yoyu described. i assume you are talking > about the agenda agenda daily/weekly view. please confirm. > what are the values of org-agenda-include-inactive-timestamps, > org-agenda-log-mode, and org-agenda-log-mode-items? Well, this is embarrassing. On a newly launched emacs, I cannot now reproduce what I originally saw. I am sorry for forgetting to try the obvious things before posting! > On 12/17/21, Colin Baxter ๐บ wrote: >> Hello, >> >> A TODO item scheduled for a future date ordinarily does not >> appear in today's agenda. However, this is not the case if the >> TODO has a note dated today in its log drawer. The TODO item is >> now visible in today's agenda, even though it's scheduled for the >> future. If this isn't a bug then how can I keep the TODO item >> hidden until its scheduled date? >> >> Best wishes, >> >> Colin Baxter. >> >> >>
org-journal key-bind confusion
There appears to be confusion between "org-journal-new-entry" and "org-goto". My ME is: 1. emacs -Q (I used emacs-29.0.50) 2. M-x load-library 3. /path/to/org-journal.el 4. C-h c 5. C-c C-j 6. "C-c C-j runs the command org-journal-new-entry" 7. Create an org file (say "test.org") from C-x C-f 8. C-h c 9. C-c C-j 10. "C-c C-j runs the command org-goto" Best wishes, Colin Baxter.
Re: org-journal key-bind confusion
Thank you for the reply.
>>>>> Ihor Radchenko writes:
> Colin Baxter ๐บ writes:
>> There appears to be confusion between "org-journal-new-entry" and
>> "org-goto". My ME is:
>>
>> 1. emacs -Q (I used emacs-29.0.50) 2. M-x load-library
>> 3. /path/to/org-journal.el 4. C-h c 5. C-c C-j
>> 6. "C-c C-j runs the command org-journal-new-entry" 7. Create an
>> org file (say "test.org") from C-x C-f 8. C-h c 9. C-c C-j
>> 10. "C-c C-j runs the command org-goto"
> Note that org-journal is not a part of Org. From a quick glance
> at the source code, C-c C-j for org-journal only works in
> org-journal-mode.
Yes, that is correct.
> I do not see anything wrong on Org side. Moreover, this issue is
> explicitly mentioned in
>
https://github.com/bastibe/org-journal#some-key-bindings-in-org-journal-conflict-with-org-mode-key-bindings
I didn't know of the URL mentioning the issue, thanks.
Best wishes,
Colin -
Re: org-journal key-bind confusion
I've changed the kbd for org-journal-new-entry to "C-c j". Simpler too. Thanks. Best wishes, Colin -
Re: Feedback on Emacs-Jupyter
> Nathaniel Nicandro writes: > Hello all, > I'm the maintainer of the emacs-jupyter project > (https://github.com/nnicandro/emacs-jupyter) which essentially > integrates Jupyter kernels (https://jupyter.org) with Org mode > source blocks. jupyter.org in using cloudflare uses non-free js. For me, this is a significant barrier.
Re: [BUG] Prefer lowercase #+results [9.5.2 (release_9.5.2-3-geb9f34 @ /Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/)]
> Rudolf Adamkoviฤ writes: > If I remember well, Org decided to suggest with lowercase keywords > (and use uppercase keywords in the manual, for some reason). > Then, we should change "org-babel-results-keyword" from "RESULTS" > to "results". Change it for yourself. Please don't change the default.
Re: [BUG] Prefer lowercase #+results [9.5.2 (release_9.5.2-3-geb9f34 @ /Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/)]
> Timothy writes: > Hi Gyro, >> Consider Emersonโs quote: >> >> โA foolish consistency is the hobgoblin of little minds, adored >> by little statesmen and philosophers and divines. With >> consistency a great soul has simply nothing to do.โ > I think applying a quote about how societal expectations and norms > can limit the capacity for greatness of individuals, to โฆ > capitalisation is a bit of a stretch. > FWIW, I think it would be good to be internally > consistent. #+RESULTS is currently one of the few keywords > inserted in upper case. Unless thereโs a good reason to > distinguish it from other keywords (perhaps an argument could be > made that it should be treated differently because it is usually > generated, not inserted by the user?), Iโd be in favour of > changing the default to be consistent. What is the point of changing a default? Users can change to whatever they like, but a default is a default - i.e. remains fixed. Why a particular default arose belongs to peculiarities of history. Do people really want to revisit this year after year? The value of a default is irrelevant: what is important is that it does not change, once it is chosen, without some very good reason. I have not seen that reason in this particular case. The arguments of consistency are ephemeral.
Re: [BUG] Prefer lowercase #+results [9.5.2 (release_9.5.2-3-geb9f34 @ /Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/)]
>>>>> Ihor Radchenko writes:
> Colin Baxter ๐บ writes:
>> What is the point of changing a default? Users can change to
>> whatever they like, but a default is a default - i.e. remains
>> fixed. Why a particular default arose belongs to peculiarities of
>> history. Do people really want to revisit this year after year?
>> The value of a default is irrelevant: what is important is that
>> it does not change, once it is chosen, without some very good
>> reason. I have not seen that reason in this particular case. The
>> arguments of consistency are ephemeral.
> For some more context, other functions are not really consistent
> about uppercase/lowercase: - =org-insert-structure-template=
> lowercase - =org-insert-drawer= uppercase -
> =org-insert-property-drawer= uppercase -
> =org-babel-exp-code-template= defaults to uppercase -
> =org-clock-find-position= defaults to uppercase :END: -
> =org-feed-write-status= defaults to uppercase -
> =org-inlinetask-insert-task= defaults to uppercase -
> =org-mobile-write-agenda-for-mobile= defaults to uppercase -
> =org-babel-examplify-region= lowercase
> I just looked for END vs end.
> So, unless there is overwhelming support for changing uppercase
> defaults into lowercase and a thorough patch, I am inclined
> towards preserving the existing behaviour.
Agreed.
> Changing just RESULTS keyword provides no benefit to making things
> consistent.
Agreed.
Best - Colin
Re: [BUG] Prefer lowercase #+results [9.5.2 (release_9.5.2-3-geb9f34 @ /Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/)]
> Rudolf Adamkoviฤ writes: > Ihor Radchenko writes: >> So, unless there is overwhelming support for changing uppercase >> defaults into lowercase and a thorough patch, I am inclined >> towards preserving the existing behaviour. > The results so far: > - For inconsistent defaults: Colin I did not write that. I wrote that I am for a default remaining a default. Whether it is "consistent" or "inconsistent" is not important. Once chosen it should stay fixed.
Re: Depreciating TeX-style LaTeX fragments
> Sรฉbastien Miquel writes:
> Hi, With respect to readability, I only mean to point out that the
> $โฆ$ syntax is one less character, and that the \(\) characters are
> quite overloaded.
Indeed. Compare something like
$g=\lim_{\delta m\to 0}(\delta F/\delta m)$
with
\(g=\lim_{\delta m\to 0}(\delta F/\delta m)\)
Backslash city! I know which one I'd prefer to read.
>> this is a good opportunity to point out that $/$$ are very much
>> second class citizens in LaTeX now, no matter what you may see in
>> old documents.
> The posts that you quote are 10 years old. As per [0] (2020),
> there will be no LaTeX3. Nor is it only old documents that use the
> $โฆ$ syntax : looking for learning ressources (see [1]), everything
> that I find uses it. That includes The Not So Short Introduction
> to LaTeX [2] (2021) and
> https://en.wikibooks.org/wiki/LaTeX/Mathematics.
Ah, LaTeX3 - whatever happened to that?
> Although I have no evidence of this, my expectation is that the
> majority of tex users use the $โฆ$ syntax (it is in fact widely
> used outside of tex: in most markdown flavors and texmacs for
> example). I also expect that a significant proportion of tex users
> are not aware of the \(โฆ\) syntax. I think here of users that are
> less tech literate than most of this mailing list.
Agreed.
Best wishes,
Re: Depreciating TeX-style LaTeX fragments
> Juan Manuel Macรญas writes: > Colin Baxter writes: >> Ah, LaTeX3 - whatever happened to that? > If you're a LaTeX user, you're already using LaTeX3 to a very high > extent, even if you don't see it. The current idea is not to > replace LaTeX2e with LaTeX3 as a new version, but to gradually > incorporate elements of LaTeX3 into the LaTeX kernel, like the new > syntax, xparse, etc. LaTeX3 is already present in many aspects of > LaTeX, and that is an undeniable advance. If anyone is interested > in the state of the art, this short talk by Frank Mittelbach at > TUG 2020 is very illustrative: Yes, I know. My remark was tongue in cheek.
