Re: [BUG] org-agenda generation missing some entries
Ihor Radchenko writes: > "Christopher M. Miles" writes: >> Now I tried your latest push. The errors gone. But org-agenda entries still >> missing. I checked >> *Messages* buffer, no error messages, including other error special buffers. >> no information. > > Agenda now uses a new algorithm to search entries. There may be a bug > there. Can you provide a minimal org file with a heading that should be > listed in agenda, but did not show up? > > Best, > Ihor I'm git bisect on the latest git-pulled org-mode. Still located bad commit on this bad commit. Seems commit also introduced other problem. #+begin_example 0ef88e2d9 * | bad @ org-agenda.el/org-agenda-get-scheduled: Use cache #+end_example I compared good *Org Agenda* buffer and bad *Org Agenda* buffer, bellowing are some of missing org-agenda entries: #+begin_src org ,* PROJECT 🅰 task A SCHEDULED: <2019-04-16 Tue> :LOGBOOK: - State "PROJECT"from [2019-04-16 Tue 13:37] :END: #+end_src I checked most of them, almost all missing org-agenda entries are "SCHEDULED" tasks with logbook or clocking log. <#secure method=pgpmime mode=sign> -- [ stardiviner ] I try to make every word tell the meaning that I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
Re: [BUG] org-agenda generation missing some entries
"Christopher M. Miles" writes: > I'm git bisect on the latest git-pulled org-mode. Still located bad commit on > this bad commit. Seems > commit also introduced other problem. > #+begin_example > 0ef88e2d9 * | bad @ org-agenda.el/org-agenda-get-scheduled: Use cache > #+end_example That's understandable, but not sufficient to pinpoint the bug. > I compared good *Org Agenda* buffer and bad *Org Agenda* buffer, bellowing > are some of missing > org-agenda entries: > > #+begin_src org > ,* PROJECT 🅰 task A > SCHEDULED: <2019-04-16 Tue> > :LOGBOOK: > - State "PROJECT"from [2019-04-16 Tue 13:37] > :END: > #+end_src > > I checked most of them, almost all missing org-agenda entries are "SCHEDULED" > tasks with logbook or > clocking log. Is it still missing if you put this heading into separate buffer and call agenda with buffer restriction? I just tried to build agenda after changing the keyword from PROJECT to TODO and I can see the heading in my agenda view. Are you using any non-standard agenda settings in addition to org-agenda-skip-scheduled-delay-if-deadline set to t? Can you try to rebuild agenda after running M-x org-element-cache-reset? Best, Ihor
unique syntax for reporting (submitting bugs)
Hi I am sending this email to four mailing list I am using most, and I am wondering whether this subject has came up in the past. For years I am wondering about the different syntax for sending/reporting/submitting bug reports. I know of 1. org-submit-bug-report but a. org-agenda-property-bug-report 2. TeX-submit-bug-report, but a. preview-report-bug b. reftex-report-bug 1. bbdb-submit-bug-report 2. c-submit-bug-report 3. ffap-submit-bug 4. vm-submit-bug-report 5. gnus-bug 6. report-emacs-bug So in order not to confuse myself I am using the following alias (defalias 'emacs-submit-bug-report 'report-emacs-bug) But I was wondering, couldn't GNU emacs also use this alias in its default configuration, since it seems a bit more common. And also the auctex team, which deals with preview-latex and reftex do the same (defalias 'preview-submit-bug-report 'preview-report-bug) (defalias 'reftex-submit-bug-report 'reftex-report-bug) The org team: (defalias 'emacs-submit-bug-report 'report-emacs-bug) (defalias 'org-agenda-property-submit-bug-report 'org-agenda-property-bug-report) And finally the gnus team (defalias 'gnus-submit-bug-report 'gnus-bug) Regards Uwe Brauer smime.p7s Description: S/MIME cryptographic signature
Re: [BUG] org-agenda generation missing some entries
Ihor Radchenko writes: > "Christopher M. Miles" writes: >> Now I tried your latest push. The errors gone. But org-agenda entries still >> missing. I checked >> *Messages* buffer, no error messages, including other error special buffers. >> no information. > > Agenda now uses a new algorithm to search entries. There may be a bug > there. Can you provide a minimal org file with a heading that should be > listed in agenda, but did not show up? > > Best, > Ihor Also include some scheduled repeated tasks like this: #+begin_src org ,** HABIT Write Blog -- =[C-c o c b]= / =[C-x t l n]= :repeat: SCHEDULED: <2018-10-21 Sun 19:15 .+1d/2d> :PROPERTIES: :STYLE:habit :END: ,** HABIT monthly check accounts:repeat: SCHEDULED: <2021-03-07 Sun .+1m> :PROPERTIES: :LAST_REPEAT: [2021-02-07 Sun 17:22] :STYLE:habit :END: :LOGBOOK: - State "DONE" from "HABIT" [2021-02-07 Sun 17:22] - State "DONE" from "HABIT" [2020-12-02 Wed 17:11] - State "DONE" from "HABIT" [2020-10-25 Sun 15:43] - State "DONE" from [2020-08-04 Tue 20:36] :END: #+end_src <#secure method=pgpmime mode=sign> -- [ stardiviner ] I try to make every word tell the meaning that I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
Re: [BUG] org-agenda generation missing some entries
Ihor Radchenko writes: > "Christopher M. Miles" writes: > >> I'm git bisect on the latest git-pulled org-mode. Still located bad commit >> on this bad commit. Seems >> commit also introduced other problem. > >> #+begin_example >> 0ef88e2d9 * | bad @ org-agenda.el/org-agenda-get-scheduled: Use cache >> #+end_example > > That's understandable, but not sufficient to pinpoint the bug. > >> I compared good *Org Agenda* buffer and bad *Org Agenda* buffer, bellowing >> are some of missing >> org-agenda entries: >> >> #+begin_src org >> ,* PROJECT 🅰 task A >> SCHEDULED: <2019-04-16 Tue> >> :LOGBOOK: >> - State "PROJECT"from [2019-04-16 Tue 13:37] >> :END: >> #+end_src >> >> I checked most of them, almost all missing org-agenda entries are >> "SCHEDULED" tasks with logbook or >> clocking log. > > Is it still missing if you put this heading into separate buffer and > call agenda with buffer restriction? I just tried to build agenda after > changing the keyword from PROJECT to TODO and I can see the heading in > my agenda view. > > Are you using any non-standard agenda settings in addition to > org-agenda-skip-scheduled-delay-if-deadline set to t? > > Can you try to rebuild agenda after running M-x org-element-cache-reset? > > Best, > Ihor I put this scheduled task into a separated org file and clean org-agenda-files variable, and set it to only this new separated org file. Not displayed. I changed "PROJECT" to "TODO", Not displayed. I have variable org-agenda-skip-scheduled-delay-if-deadline setted to 'post-deadline. Then I tried setting it to t or nil. Bot not displayed. I tried [M-x org-element-cache-reset], Still not displayed. <#secure method=pgpmime mode=sign> -- [ stardiviner ] I try to make every word tell the meaning that I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
Re: Shower thought: submit an IETF RFC to register Org as a MIME type
Hi Igor, > The conversation was about keywords and similar constructs (i.e. > ^#+keyword). You are looking at property drawer and properties inside. > There is no preference here, though internally properties in property > drawer are all converted to upper case. Ok, thank you very much for the clarification. >> But then c-a-p is very lenient since it lists lower and upper case block >> variants even when I typed a lower case prefix, and upper case usually >> will go first in the list, hence promoting a seemingly bad practice. > > Could you clarify what is "c-a-p"? Yes, I just meant completion-at-point. At least some org functions, which I believe are implemented using pcomplete and then exposed through the completion-at-point interface, provide completions in both lower and uppercase variants and except when completion-ignore-case is nil (not the default) uppercase candidates will be sorted first in the list. It's often quite inconvenient to scroll down a completion menu to pick the lowercase completion for a short prefix, which either promotes using the uppercase variant at hand or offsets the benefits of autocompletion. Moreover, popular external collections of snippets have already adopted the lowercase convention of org-mode, hence introducing inconsistency in the document when one mixes both sources of completion (lowercase snippets and org-mode uppercase completions). So perhaps uppercase completions should be provided only when the user explicitly typed an uppercase prefix. What do you think? Best regards, Carlos
Re: Shower thought: submit an IETF RFC to register Org as a MIME type
Hi Carlos, Just a minor point from me, this really should be a new thread IMO. While not much may have happened with the IETF RFC, it’s still something on my mind that I hope to get back to eventually. All the best, Timothy
when does :cache not cache?
You may find this John Kitchin's blog post illuminating. HTH, -- Emmanuel Charpentier
Re: when does :cache not cache?
On Saturday, 23 Oct 2021 at 11:13, Emmanuel Charpentier wrote: > You may find this John Kitchin's blog > post [...] illuminating. Unfortunately not but thank you. It is a very useful blog post but doesn't cover my case, where I use a :var header to refer to a table. The table is static so I still do not understand why :cache on the src block that references it doesn't work. I may have to dive into the code, I guess. I may be some time... ;-) -- : Eric S Fraga via Emacs 28.0.60, Org release_9.5-163-g4eab5b : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: Fwd: errors when using org-agenda
Tim, et al., > These types of errors are frequently caused by a 'mixed' installation > of org versions. This will happen if you upgrade org when org is > already loaded in the instance of emacs used to perform the upgrade. a question: is there any way that we can, as org starts up, detect either the actuality, or possibility, of a mixed installation? maybe something like (assert (eq 1 (length (seq-filter (lambda (d) (file-exists-p (concat d "/" "org.el"))) load-path or some such? (well, maybe fail in a more user-friendly way... :) cheers, Greg
Re: org-capture broken?
Ihor, > > make of org mode? (remote possibility: emacs?) > > Org mode build process is not standard. Org mode needs to create > autoload file and generate documentation in addition to normal > byte-compilation. thanks. does that mean running "make" in the org directory? cheers, Greg
Re: [BUG] org-agenda generation missing some entries
"Christopher M. Miles" writes: > I put this scheduled task into a separated org file and clean > org-agenda-files variable, and set it > to only this new separated org file. Not displayed. I finally managed reproduce the problem. It only exists in Emacs <28. byte-compiled version of agenda matcher is somehow different from raw lambda. I just pushed a workaround to main. Let me know if it fixed the issue on your side. Best, Ihor
Re: org-capture broken?
Greg Minshall writes: > Ihor, > >> > make of org mode? (remote possibility: emacs?) >> >> Org mode build process is not standard. Org mode needs to create >> autoload file and generate documentation in addition to normal >> byte-compilation. > > thanks. does that mean running "make" in the org directory? If you are pulling Org mode from git and not using straight.el, yes. Also, see https://orgmode.org/org.html#Installation Best, Ihor
Re: Fwd: errors when using org-agenda
Greg Minshall writes: > Tim, et al., > >> These types of errors are frequently caused by a 'mixed' installation >> of org versions. This will happen if you upgrade org when org is >> already loaded in the instance of emacs used to perform the upgrade. > > a question: is there any way that we can, as org starts up, detect > either the actuality, or possibility, of a mixed installation? > maybe something like > > (assert (eq 1 > (length > (seq-filter > (lambda (d) (file-exists-p (concat d "/" "org.el"))) > load-path > > or some such? (well, maybe fail in a more user-friendly way... :) > I'm not sure auto detecting is possible. It isn't so much about what files exist, but what functions are already defined and/or what libraries are already loaded when the upgrade process tries to compile the new version. The 'mixed' refers to the resulting *.elc files, which havbe been compiled with definitions from two different org versions. With package.el for example, once the upgrade has been completed, the old ELPA version doesn't exist anymore, so it isn't as simple as just checking for multiple references to org source files in the load path and at different locations. What would really be needed is some way to check when org is going to be compiled that no existing org functionality is loaded. Doubt this can be easily done within org itself because of a chicken and egg problem - you would have to load org to run the code to check if org is loaded. It could be possible to add something to the package installer, but that would mean doing something with all the package installers e.g. package.el, straight.el, etc. Some distributions, like spacemacs, manage this by separating marking of packages to be upgraded and doing the upgrade into separate sessions. You check for updates, write the list of packages to be updated, move the existing packages to a recovery area and then you have to restart Emacs. On restart, the list of packages to be upgraded (it is really an install because the previous versions have been moved out into a separate 'recovery' area) and if org is in the list, move it to the front of the list so that it is installed before any other packages (to protect against other packages loading org as part of their installation). All this means, with spacemacs, you can be pretty confident an upgrade will work without the mixed install issue. Even better, if the upgraded package has problems and you want to downgrade back to the previous version, that is supported as well. The bad aspect of spacemacs is that after you have used it for a while, your pretty much ruined when it comes to running vanilla Emacs. You get very use to the VI style modal editing and find it hard to use emacs without evil mode installed.
[PATCH] org.el (org-display-inline-image--width): Small fix
Hi, The variable display-line-numbers-width is nil by default. Regards, -- Sébastien Miquel From 2e306750caff0474aa9a6443c7d7eb68e3aca83b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= Date: Sat, 23 Oct 2021 13:28:59 +0200 Subject: [PATCH] org.el (org-display-inline-image--width): Small fix --- lisp/org.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org.el b/lisp/org.el index 474171b55..3140c4d1f 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -16867,7 +16867,7 @@ buffer boundaries with possible narrowing." (/ (or (and (bound-and-true-p visual-fill-column-mode) (or visual-fill-column-width auto-fill-function)) (when auto-fill-function fill-column) - (- (window-text-width) display-line-numbers-width)) + (- (window-text-width) (or display-line-numbers-width 0))) (float (window-total-width) width))) ((numberp org-image-actual-width) -- 2.33.1
Re: Bug: Inconsistent macro replacement [9.4.4 (release_9.4.4 @ /nix/store/jzj2bbfjlbv08xjgyljf7aqf7q2jcbm8-emacs-27.2/share/emacs/27.2/lisp/org/)]
Hello,
Vinicius Vinicius writes:
> While {{{title}}} concatenates multiple #+TITLE lines, {{{author}}} retrieves
> only the first one.
>
> MWE:
> #+TITLE: Foo
> #+TITLE: Foo2
>
> #+AUTHOR: First Author
> #+AUTHOR: Second Author
>
> {{{title}}} vs {{{author}}}
Fixed.
Thank you.
Regards,
--
Nicolas Goaziou
Citations: position="first" match not properly evaluated
Dear all,
the CSL style I use has footnotes. When a book is cited, it is once
cited with the full bibliographic information, and later footnotes then
reference the footnote in which this information first appeared,
shortening the later footnotes to the format "Author, (o. Fn. ),
...". (the spurious comma I will look into later, it's probably an error
in the CSL file). Now take this org file:
#+TITLE: Test
#+AUTHOR: testauthor
#+LANGUAGE: de
#+cite_export: csl /tmp/mwe/juristische-schulung.csl
#+bibliography: /tmp/mwe/mwe.bib
Das ist ein Test mit dem ersten Zitat [cite:@knuth1997tacp1 p. 55].
Dasselbe Zitat mit einer anderen Seite [cite:@knuth1997tacp1 p. 70].
mwe.bib:
@Book{knuth1997tacp1,
author = {Donald E. Knuth},
maintitle= {The Art of Computer Programming},
title = {Fundamental Algorithms},
year = {1997},
edition = {3},
publisher = {Addison-Wesley},
location = {Reading, Harlow, Menlo Park, Berkeley, Don Mills, Sydney,
Bonn, Amsterdam, Tokyo, Mexico City},
langid= {english},
volume= {1}}
juristische-schulung.csl is
https://github.com/citation-style-language/styles/blob/e22b8a566bad9b4c7f52720f60dd875057a5d210/juristische-schulung.csl
Exporting this gives these two footnotes:
1 Knuth, The Art of Computer Programming, 3. Aufl. (1997), 55
2 Knuth, , 70
The second footnote is incomplete. It lacks the "o. Fn." mark and the
footnote referenced. If I export the equivalent pandoc-markdown document
with pandoc:
---
title: Test
author: Testauthor
lang: de
---
Das ist ein Test mit dem ersten Zitat [@knuth1997tacp1, p. 55].
Dasselbe Zitat mit einer anderen Seite [@knuth1997tacp1, p. 70].
Then both footnotes are proper:
1. Knuth, The Art of Computer Programming, 3. Aufl. (1997), p. 55
2. Knuth, (o. Fn. 1), p. 70
So it’s not an error in the CSL file. The CSL file uses this construct
to differenciate the two cases:
This is probably a bug.
Org mode version 9.5 (release_9.5-104-g2b1fc6 @
/home/quintus/.emacs.d/org-mode/lisp/)
citeproc.el at 34e66583d95a8d80fb5b9f2960f3382ca0e6d3ab
-quintus
--
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland | kont...@guelker.eu| O<
Keyword completion list: uppercase or lowercase? (was: Shower thought: submit an IETF RFC to register Org as a MIME type)
Carlos Pita writes: >>> But then c-a-p is very lenient since it lists lower and upper case block >>> variants even when I typed a lower case prefix, and upper case usually >>> will go first in the list, hence promoting a seemingly bad practice. >> >> Could you clarify what is "c-a-p"? > > Yes, I just meant completion-at-point. At least some org functions, > which I believe are implemented using pcomplete and then exposed through > the completion-at-point interface, provide completions in both lower and > uppercase variants and except when completion-ignore-case is nil (not > the default) uppercase candidates will be sorted first in the list. > It's often quite inconvenient to scroll down a completion menu to pick > the lowercase completion for a short prefix, which either promotes using > the uppercase variant at hand or offsets the benefits of > autocompletion. Moreover, popular external collections of snippets have > already adopted the lowercase convention of org-mode, hence introducing > inconsistency in the document when one mixes both sources of completion > (lowercase snippets and org-mode uppercase completions). So perhaps > uppercase completions should be provided only when the user explicitly > typed an uppercase prefix. What do you think? I just tried with clean Emacs: #+beg #+begin_ -> list of completions, all in lower case #+BEG #+BEGIN_ -> list of completions, all in upper case Seems to be all right. Can you provide a more concrete example when you are given both uppercase and lowercase completions? Best, Ihor
Re: Keyword completion list: uppercase or lowercase? (was: Shower thought: submit an IETF RFC to register Org as a MIME type)
On Sat, Oct 23, 2021 at 9:41 AM Ihor Radchenko wrote: > > Carlos Pita writes: > > >>> But then c-a-p is very lenient since it lists lower and upper case block > >>> variants even when I typed a lower case prefix, and upper case usually > >>> will go first in the list, hence promoting a seemingly bad practice. > >> > >> Could you clarify what is "c-a-p"? > > > > Yes, I just meant completion-at-point. At least some org functions, > > which I believe are implemented using pcomplete and then exposed through > > the completion-at-point interface, provide completions in both lower and > > uppercase variants and except when completion-ignore-case is nil (not > > the default) uppercase candidates will be sorted first in the list. > > It's often quite inconvenient to scroll down a completion menu to pick > > the lowercase completion for a short prefix, which either promotes using > > the uppercase variant at hand or offsets the benefits of > > autocompletion. Moreover, popular external collections of snippets have > > already adopted the lowercase convention of org-mode, hence introducing > > inconsistency in the document when one mixes both sources of completion > > (lowercase snippets and org-mode uppercase completions). So perhaps > > uppercase completions should be provided only when the user explicitly > > typed an uppercase prefix. What do you think? > > I just tried with clean Emacs: > > #+beg #+begin_ -> list of completions, all in lower case > #+BEG #+BEGIN_ -> list of completions, all in upper case Perhaps at some point the upper case should just be removed? This raises a related question I've wondered about: Why doesn't the completion insert the full begin/end, and put point inside? It's a bit of an awkward UX to add the end line ATM. Bruce
Re: Keyword completion list: uppercase or lowercase? (was: Shower thought: submit an IETF RFC to register Org as a MIME type)
"Bruce D'Arcus" writes: >> I just tried with clean Emacs: >> >> #+beg #+begin_ -> list of completions, all in lower >> case >> #+BEG #+BEGIN_ -> list of completions, all in upper >> case > > Perhaps at some point the upper case should just be removed? I am not sure if it is a good idea from backward compatibility point of view. On the other hand, we managed to change the property drawer default position. So, I do not see why it is impossible if most users prefer lower case. > This raises a related question I've wondered about: > > Why doesn't the completion insert the full begin/end, and put point inside? > > It's a bit of an awkward UX to add the end line ATM. Adding full begin/end may not be good idea for completion-at-point: 1. It becomes awkward i.e. to insert the source block language and arguments (#+begin_src my-super-cool-programming-language :var x=1) 2. completion-at-point usually does not behave in such way. Note that Org mode provides org-tempo doing exactly what you describe. Best, Ihor
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
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. Best, Ihor
Re: Fwd: errors when using org-agenda
Ok, great -- that fixed it! I thought I had been careful to get rid of
my old org from org elpa before I installed 9.5. However, I hadn't
considered that there was an older org still installed that had been
packaged with my emacs 27.2 installation.
So thanks very much for your quick advice. It's very nice to have that
functionality back.
Bill
On 10/22/21 9:57 PM, Tim Cross wrote:
William McCoy writes:
I am modifying my previous message (that has not yet appeared on this list) with
some additional information regarding this issue:
I have been having some strange errors when using org-agenda. The errors seem
to have begun about the time I upgraded to org 9.5 from the elpa repo a couple
of weeks ago. When I activate org-agenda, I get the usual menu. When I press
'm' to search for a tag and then enter a known tag name, I get an empty *Org
Agenda* buffer and an error in the minibuffer:
Symbol’s value as variable is void: timestamp-up
With debug-on-error set, I get the following backtrace:
Debugger entered--Lisp error: (void-variable timestamp-up)
 org-entries-lessp(#(" ubuntu: Updated Pop_OS (Ubuntu) ..." 0 14 (type
"tagsmatch" priority 1000 ts-date nil todo-state$
 sort((... ... ... ... ... ... ... ... ... ... ... ... ... ... ...)
org-entries-lessp)
 org-agenda-finalize-entries((... ... ... ... ... ... ... ... ... ... ... ...
... ... ...) tags)
 org-tags-view(nil)
 funcall-interactively(org-tags-view nil)
 call-interactively(org-tags-view)
 org-agenda(nil)
 funcall-interactively(org-agenda nil)
 call-interactively(org-agenda nil nil)
 command-execute(org-agenda)
When I enter org-agenda and use 'a' for my agenda, I get the following error:
Invalid function: (date date)
And the backtrace is:
Debugger entered--Lisp error: (invalid-function (date date))
 (date date)()
org-agenda-get-day-entries("/home/wdmccoy/orgfiles/C/C-examples.org" (10 18
2021) :deadline :scheduled :timestamp :sexp)
 apply(org-agenda-get-day-entries "/home/wdmccoy/orgfiles/C/C-examples.org"
(10
18 2021) (:deadline :scheduled :timestamp :s$
 org-agenda-list(nil)
 funcall-interactively(org-agenda-list nil)
 call-interactively(org-agenda-list)
 org-agenda(nil)
 funcall-interactively(org-agenda nil)
 call-interactively(org-agenda nil nil)
 command-execute(org-agenda)
Disregard the following comments between the dashed lines. I just realized that
when I start emacs with the -Q switch, an older built-in version of org-mode
(9.4.4) is used. So I do think this is related to changes in version 9.5.
--
If I start emacs with the -Q switch and then execute my org-agenda-files
setting command in the *scratch* buffer:
(setq org-agenda-files (directory-files-recursively "~/orgfiles/" "\\.org$"))
then org-agenda appears to work fine without errors.
--
I have made a minimal init.el file and trimmed virtually everything from my
emacs-custom.el file (file attached), but the error still occurs. I just can't
figure out what's causing it. Any ideas?
Also I forgot to add:
emacs-version: GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0) of 2021-06-04
org-version: Org mode version 9.5 (9.5-g0a86ad @
/home/wdmccoy/.emacs.d/elpa/org-9.5/)
OS:Â Linux pop-os 5.13.0-7614-generic #14~1631647151~21.04~930e87c-Ubuntu SMP
Thanks, Bill
[2. text/x-emacs-lisp; init.el]...
[3. text/x-emacs-lisp; emacs-custom.el]...
These types of errors are frequently caused by a 'mixed' installation of
org versions. This will happen if you upgrade org when org is already
loaded in the instance of emacs used to perform the upgrade.
It is critically important when upgrading org that org is not already
loaded. Highly recommend you remove the version of org you have
installed, restart emacs (ensuring nothing in your init.el loads org -
comment out if there is), install org 9.5, uncomment anything in your
init.el you commented to ensure org was not loaded, restart emacs and
see if the problem is resolved.
Note that if your installing other org extensions, make sure these are
not loaded as well as it is probable they will load org as well.
Re: Problems generating the org-mode documentation
On 23/10/2021 11:06, Kyle Meyer wrote: Hoffmann, Jobst writes: But I think I found the culprit: Line 17568 of org.texi reads: @kindex C-c C-x @ and @ starts a command, which leads to the stack overflow. Line 17568 of org.texi should read @kindex C-c C-x @@ witha doubled @ at the end of the line and after applying this change org.texi the documentation org.pdf can be generated without any error. Marco Wahl fixed this entry a few days ago on the bugfix branch: 37791bb4f (org-manual: Fix one kindex entry, 2021-10-18). Shouldn't it be handled by ox-texinfo.el instead? However it is a rare case, so it is not really important. Are there cases when raw texinfo commands are requires in "#+kindex:" strings? Formally some other exporter might support kindex...
Re: when does :cache not cache?
Hello all, So, following the code: every time I ask to evaluate the gnuplot src block in the minimal example I posted yesterday, the new-hash that is calculated is different so the cache setting is ignored. Digging deeper leads to me getting lost. The hash does depend on the incorporation of the variables set using :var but I do not see why the hash should be different if the table has not changed. Anyway, that's as far as I got. For the record, I have simply put ":eval never-export" on all of my gnuplot src blocks and the export happens much more quickly now. eric -- : Eric S Fraga via Emacs 28.0.60, Org release_9.5-163-g4eab5b : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: Lisp error: (void-function org-element-keyword-parser)
On 22 October 2021, Ihor Radchenko wrote:
I cannot reproduce the problem using relatively recent Emacs master
(commit ae9bfaa891c).
A blind guess: Try to run make clean?
Thanks for checking, and the suggestion. In the end I think one or the other
two things did it:
First, rebuilding Emacs with "make cleanall && make bootstrap". I'd use "make
bootstrap" to clear out a warning I was getting about Tramp having been built
with a previous version, and it was after that that my problems started, but
whether because of it, who knows.
Second, dropping the org-bullets package that makes Org look fancier. In all my
looking at warnings and messages I saw some mention of it, so I removed it, and
then things started working again.
So if anyone out there is using org-bullets and runs into a problem, try
removing it and see if that helps.
Now I'm using org-superstar-mode¹ and liking it. In case it's helpful to
anyone, this is my use-package incantation.
(use-package org-superstar
:config
(setq org-superstar-headline-bullets-list '("⊢" "⋮" "⋱" "◉" "○"))
:hook
(org-mode . (lambda () (org-superstar-mode 1)))
)
Sometimes fiddling with Emacs and Org is like spending an afternoon working in
the kitchen cleaning out the fridge, cleaning the oven, fixing a leak in the tap
and reorganizing your pots and pans. Then you discover that when you turn on
the hot water the refrigeratoor door swings open. There's no clue why. You can
either spend days identifying the problem, or you can live with it, or you can
move. Then you ask if this has ever happened to anyone else, and someone says
they discovered it stops if your feet are bare, and five years later you're
still taking off your shoes and socks before cooking.
Bill
¹ https://github.com/integral-dw/org-superstar-mode
--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada
Re: Fwd: errors when using org-agenda
Tim, thanks. i see that it is more complicated. (and, after fifteen years of vi, and now 25 of emacs, i guess i'll skip the spacemacs experience. :) cheers, Greg
Re: Fwd: errors when using org-agenda
Greg Minshall writes: > (and, after fifteen years of vi, and now 25 of emacs, i guess i'll skip > the spacemacs experience. :) > Similar past for me as well. I used vi from early/mid 80x until mid 90s and then switched to Emacs and used standard Emacs bindings until a couple of years ago, then decided to give spacemacs a go. I realised when I did I had very much missed the vi modal editing approach. I know it isn't for everyone, but I find using it pushes my productivity through the roof. I always tried to use keyboard navigation and avoid the mouse. Being able to use simple keys rather than complex bindings involving ctl, alt, shift, is just so much faster and easier on my aging and stiffining fingers, I think I'm now a devout member of the evil-mode cult.
Re: Keyword completion list: uppercase or lowercase?
Ihor Radchenko writes: Hi Igor, > I just tried with clean Emacs: > > #+beg #+begin_ -> list of completions, all in lower case > #+BEG #+BEGIN_ -> list of completions, all in upper case > > Seems to be all right. You're right, I was under the impression that completion-ignore-case = t was the default, but it's just an ancient customization of mine that I got used to and had forgotten about. My apologies for the noise. Best regards, Carlos
Re: "begin_src R :session" opens R session when file first visited
On 17 October 2021, Jeremie Juste wrote: Many thanks for reporting your issue and many thanks to Greg for testing. Sorry, I cannot reproduce the issue either. I don't think it is related to async. Could you try with 'emacs -Q'? Thanks to you both for testing this. It was a problem with my own configuration, which, thanks to some fiddling, has now vanished. What triggered the problem I can't imagine. I have turned up a new problem that I think is reproducible with emacs -Q and I'll report that next. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Fwd: errors when using org-agenda
Tim Cross writes: Greg Minshall writes: (and, after fifteen years of vi, and now 25 of emacs, i guess i'll skip the spacemacs experience. :) Similar past for me as well. I used vi from early/mid 80x until mid 90s and then switched to Emacs and used standard Emacs bindings until a couple of years ago, then decided to give spacemacs a go. I realised when I did I had very much missed the vi modal editing approach. I know it isn't for everyone, but I find using it pushes my productivity through the roof. I always tried to use keyboard navigation and avoid the mouse. Being able to use simple keys rather than complex bindings involving ctl, alt, shift, is just so much faster and easier on my aging and stiffining fingers, I think I'm now a devout member of the evil-mode cult. Same here, though Spacemacs introduced me to modal editing. Spacemacs also helped eliminate many of my rookie errors configuring Emacs. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [BUG] org-agenda generation missing some entries
Ihor Radchenko writes: > "Christopher M. Miles" writes: > >> I put this scheduled task into a separated org file and clean >> org-agenda-files variable, and set it >> to only this new separated org file. Not displayed. > > I finally managed reproduce the problem. It only exists in Emacs <28. > byte-compiled version of agenda matcher is somehow different from raw > lambda. I just pushed a workaround to main. Let me know if it fixed the > issue on your side. > > Best, > Ihor My Emacs version (on M1 macOS) GNU Emacs 28.0.60 (build 1, aarch64-apple-darwin20.6.0, NS appkit-2022.60 Version 11.6 (Build 20G165)) of 2021-10-20 Thanks for your continuous working. I pulled latest fix, still not working. <#secure method=pgpmime mode=sign> -- [ stardiviner ] I try to make every word tell the meaning that I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
Re: Lisp error: (void-function org-element-keyword-parser)
William Denton writes: > So if anyone out there is using org-bullets and runs into a problem, try > removing it and see if that helps. Not necessarily. Recent patch (d3143feaf) removed the call to org-element-keyword-parser completely, which was probably the real fix ;) Best, Ihor
Re: Fwd: errors when using org-agenda
Tim,
i wonder if the emacs variable `load-history` might be of (approximate)
help? i submit a starter routine below. as the comments say: caveat,
caveat, caveat.
i don't think something as uncertain as this would be a candidate for
normal run-time checking (and, i'm not even sure when one would want to
run such a thing -- maybe as each module is loaded, if it were faster).
but, maybe it could be run as part of `M-x org-submit-bug-report`?
either to notify the user, or to include with the bug report?
wdyt? (such a nice acronym!)
cheers, Greg
notice the canned list of files. one could, i suspect, go find where
org.el came from, then use all the .el files there. (or the union of
all the files in *all* the directories that loaded an org.el.)
(defun org--check-load-history (&optional where)
"check to see if there *appears* to *maybe* have be a \"mixed
installation\" of org-mode running. if there appear to be more than
one directory holding org package(-like) files, the names of those
directories, along with the relevant files in each, are returned as
a vector of explanatory strings.
this routine is subject to both type I and type II errors (false
positives, false negatives). we have a canned list of org .el file
names, and we look to see if those files exist in more than one
directory that has been loaded (using the `load-list` variable).
if there does not appear to be the possibility of a \"mixed
installation\", the if the optional argument WHERE is non-nil, and
there is only one directory containing org package(-like) files,
that directory name is returned. if WHERE is nil, nil is returned."
(require 'seq)
(require 's)
(let* ((org-files
'("ob-lob.el" "oc-bibtex.el" "org-crypt.el" "org-persist.el"
"ob-C.el" "ob-lua.el" "oc-csl.el" "org-ctags.el" "org-plot.el"
"ob-R.el" "ob-makefile.el" "oc-natbib.el" "org-datetree.el"
"org-protocol.el"
"ob-awk.el" "ob-matlab.el" "oc.el" "org-duration.el" "org-refile.el"
"ob-calc.el" "ob-maxima.el" "ol-bbdb.el" "org-element.el"
"org-src.el"
"ob-clojure.el" "ob-ocaml.el" "ol-bibtex.el" "org-entities.el"
"org-table.el"
"ob-comint.el" "ob-octave.el" "ol-docview.el" "org-faces.el"
"org-tempo.el"
"ob-core.el" "ob-org.el" "ol-doi.el" "org-feed.el" "org-timer.el"
"ob-css.el" "ob-perl.el" "ol-eshell.el" "org-footnote.el"
"org-version.el"
"ob-ditaa.el" "ob-plantuml.el" "ol-eww.el" "org-goto.el"
"org-version.el~"
"ob-dot.el" "ob-processing.el" "ol-gnus.el" "org-habit.el" "org.el"
"ob-emacs-lisp.el" "ob-python.el" "ol-info.el" "org-id.el"
"ox-ascii.el"
"ob-eshell.el" "ob-ref.el" "ol-irc.el" "org-indent.el"
"ox-beamer.el"
"ob-eval.el" "ob-ruby.el" "ol-man.el" "org-inlinetask.el"
"ox-html.el"
"ob-exp.el" "ob-sass.el" "ol-mhe.el" "org-install.el"
"ox-icalendar.el"
"ob-forth.el" "ob-scheme.el" "ol-rmail.el" "org-keys.el"
"ox-koma-letter.el"
"ob-fortran.el" "ob-screen.el" "ol-w3m.el" "org-lint.el"
"ox-latex.el"
"ob-gnuplot.el" "ob-sed.el" "ol.el" "org-list.el" "ox-man.el"
"ob-groovy.el" "ob-shell.el" "org-agenda.el" "org-loaddefs.el"
"ox-md.el"
"ob-haskell.el" "ob-sql.el" "org-archive.el" "org-loaddefs.el~"
"ox-odt.el"
"ob-java.el" "ob-sqlite.el" "org-attach-git.el" "org-macro.el"
"ox-org.el"
"ob-js.el" "ob-table.el" "org-attach.el" "org-macs.el"
"ox-publish.el"
"ob-julia.el" "ob-tangle.el" "org-capture.el" "org-mobile.el"
"ox-texinfo.el"
"ob-latex.el" "ob.el" "org-clock.el" "org-mouse.el" "ox.el"
"ob-lilypond.el" "oc-basic.el" "org-colview.el" "org-num.el"
"ob-lisp.el" "oc-biblatex.el" "org-compat.el" "org-pcomplete.el"))
(possibles
(seq-map (lambda (x)
(cons (file-name-directory (car x))
(list (file-name-base (car x)
(seq-filter
(lambda (x)
(let ((bn (file-name-nondirectory (car x
(seq-contains-p org-files bn
(lambda (e elt) (s-match (concat "^" e
"$") elt)
load-history
(let ((uniques (seq-uniq (seq-map 'car possibles
(if (eq 1 (length uniques))
(if where ; this is the good outcome
(car uniques))
(seq-map
(lambda (dir)
(let ((joined
(s-join " "
(seq-map 'cadr
(seq-filter
(lambda (e)
(progn
(equal (car e) dir)))
possibles)
(s-lex-format "from ${dir} have
[PATCH] Re: Fwd: errors when using org-agenda
Tim Cross writes:
> What would really be needed is some way to check when org is going to be
> compiled that no existing org functionality is loaded. Doubt this can be
> easily done within org itself because of a chicken and egg problem - you
> would have to load org to run the code to check if org is loaded.
I attached a tentative patch checking if org is loaded. It is not
ideal, but it can capture some scenarios.
The patch will not work if older org.el is loaded before newer version
of Org. Though we may put extra checks in other lisp files.
WDYT?
Best,
Ihor
>From 2e987d60e47da0a7da8ded32bc5c2cc6bf11db04 Mon Sep 17 00:00:00 2001
Message-Id: <2e987d60e47da0a7da8ded32bc5c2cc6bf11db04.1635052126.git.yanta...@gmail.com>
From: Ihor Radchenko
Date: Sun, 24 Oct 2021 13:06:47 +0800
Subject: [PATCH] org.el: Check for mixed installation
* lisp/org.el (org-check-mixed-installation): New macro checking all
the loaded org libraries to be from the same directory and to have the
same extension (no mixing of .el and .elc).
(org-mode): Call `org-check-mixed-installation' before and after
`org-mode' loading.
---
lisp/org.el | 55 +++--
1 file changed, 53 insertions(+), 2 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index 90c645625..0d009ccb5 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -90,6 +90,55 @@ (or (eq this-command 'eval-buffer)
(message "You need to run \"make\" or \"make autoloads\" from Org lisp directory")
(sit-for 3
+(defmacro org-check-mixed-installation ()
+ "Detect mixed installation."
+ `(let* ((org-feature-list '( ob-C ob-R ob-awk ob-clojure ob-comint
+ ob-core ob-css ob-ditaa ob-dot ob-emacs-lisp
+ob-eshell ob-eval ob-exp ob-forth ob-fortran
+ob-gnuplot ob-groovy ob-haskell ob-java
+ob-js ob-julia ob-latex ob-lilypond
+ob-lisp ob-lob ob-lua ob-makefile
+ob-matlab ob-maxima ob-ocaml ob-octave
+ob-org ob-perl ob-plantuml ob-processing
+ob-python ob-ref ob-ruby ob-sass ob-scheme
+ob-screen ob-sed ob-shell ob-sql ob-sqlite
+ob-table ob-tangle ob oc-basic oc-biblatex
+oc-bibtex oc-csl oc-natbib oc ol-bbdb ol-bibtex
+ol-docview ol-doi ol-eshell ol-eww ol-gnus
+ol-info ol-irc ol-man ol-mhe ol-rmail
+ol-w3m ol org-agenda org-archive org-attach-git
+org-attach org-capture org-clock org-colview
+;; org-compat
+org-crypt org-ctags org-datetree
+org-duration org-element org-entities
+org-faces org-feed org-footnote org-goto
+org-habit org-id org-indent org-inlinetask
+org-install org-keys org-lint org-list
+org-macro org-macs org-mobile org-mouse
+org-num org-pcomplete org-persist org-plot
+org-protocol org-refile org-src org-table
+org-tempo org-timer org ox-ascii ox-beamer
+ox-html ox-icalendar ox-koma-letter ox-latex
+ox-man ox-md ox-odt ox-org ox-publish
+ox-texinfo ox))
+ (loaded-features (seq-filter
+ (lambda (f) (memq (alist-get 'provide f)
+ org-feature-list))
+load-history))
+ (loaded-files (mapcar #'car loaded-features)))
+ (unless (and (= 1 (length (cl-remove-duplicates
+ (mapcar (lambda (path) (file-name-directory path))
+loaded-files)
+ :test #'equal)))
+ (= 1 (length (cl-remove-duplicates
+ (mapcar (lambda (path) (file-name-extension path))
+loaded-files)
+ :test #'equal
+ (warn "Mixed Org mode installation detected.
+Please make sure that you deleted old Org files after upgrade and do
+not load Org/external packages depending on Org before setting the
+correct `load-path' in your init.el."
+
(eval-and-compile (require 'org-macs))
(require 'org-compat)
(require 'org-keys)
@@ -4840,6 +4889,7 @@ (define-derived-mode org-mode outline-mode "Org"
The following commands are available:
\\{org-mode-map}"
+ (org-check-mixed-installation)
(org-load-modules-maybe)
(org-install-agenda-files-menu)
(when org-link-descriptive (add-to-invisibility-spec '(org-link)))
@@ -4978,8 +5028,9 @@ (define-derived-mode org-mode outline-mode "Org"
(set-face-foreground 'org-hide foreground)))
;; Set face extension as requested.
(org--set-faces-extend '(org-block-begin-line org-block-end-line)
-
Re: [BUG] org-agenda generation missing some entries
"Christopher M. Miles" writes: > My Emacs version (on M1 macOS) > > GNU Emacs 28.0.60 (build 1, aarch64-apple-darwin20.6.0, NS appkit-2022.60 > Version 11.6 (Build 20G165)) of 2021-10-20 > > Thanks for your continuous working. I pulled latest fix, still not working. I also tested using Emacs 28.0.60, but on Linux. Can you try exactly same steps I used for testing? 1. Save the attached file to /tmp/problem.org 2. mkdir /tmp/orgmode-test cd /tmp/orgomode-test git clone git://git.sv.gnu.org/emacs/org-mode.git cd org-mode/ emacs -Q -L ./lisp -l org /tmp/problem.org 3. M-x org-agenda < a If you do not see the heading listed in agenda view after doing above steps, can you also try to go to org-element.el and change "(version< emacs-version "28")" in org-element-cache-map to "(version< emacs-version "29")". Then, try the above steps again. Best, Ihor df.org Description: Lotus Organizer
