[BUG] Contents of the *Warnings* buffer, which has begun popping up at random intervals
I was prompted by a buffer named *Warnings* to send an email to
emacs-orgmode@gnu.org<mailto:emacs-orgmode@gnu.org>.
This buffer appears seemingly at random every few days or so (I use
Emacs and Org mode for about eight hours a day). The warnings began
after I upgraded to Org 9.6.3. Find the contents of that buffer below.
Thank you for the work on Org mode, which is magnificent and
without peer.
Tom Davey
■ Warning (org-element-cache): org-element--cache: Org parser error in
journal.org::18359990. Resetting.
The error was: (error "Invalid search bound (wrong side of point)")
Emacs : GNU Emacs 29.0.50 (build 1, x86_64-w64-mingw32)
of 2022-09-14
Package: Org mode version 9.6.3 ( @
c:/Users/tdavey/Documents/Dropbox/Emacs/Prod/.emacs.d/load-path-subdirs/td-esdf/td-startup-lisp/Elpa/org-9.6.3/)
current state:
==
(setq
org-archive-location "%s_archive::datetree/"
org-link-elisp-confirm-function 'yes-or-no-p
org-directory "~/org-files"
org-yank-adjusted-subtrees t
org-tag-faces '(("PROJ" :background "indianred3" :foreground "cornsilk2"
:weight bold))
org-agenda-custom-commands '(("c" "Computers and Project Tags"
((agenda "") (tags-todo "project") (tags-todo
"orgmode") (tags-todo "emacs")
(tags-todo "computers"))
)
("e" "Email tag" ((tags-todo "email") (agenda
"")))
("g" "Microscheduling tag" ((tags-todo
"microscheduling") (tags-todo "today") (agenda "")))
("h" "Housing tags"
((tags "+Strivers") (tags "+SGCagenda") (tags
"+SGCbudget") (tags "+SGCcuo")
(tags "+SGCdiscussion") (tags "+SGChouseRules")
(tags "+SGCminutes") (tags "+SGCstaff")
(tags "+SGCunit") (tags "+SGCvote") (tags
"+improvement") (tags "+household"))
((org-columns-default-format "%CATEGORY %75ITEM
%TODO %TAGS %25CREATED %25TIMESTAMP")))
("n" "Agenda and all TODOs" ((agenda "") (alltodo
"")))
("p" "People tags"
((agenda "") (tags-todo "atrajkov") (tags-todo
"apotter") (tags-todo "dmcewan")
(tags-todo "espector") (tags-todo "jbousley")
(tags-todo "kmandel") (tags-todo "rosoria")
(tags-todo "twasson") (tags-todo "cfrappier")
(tags-todo "cmorales") (tags-todo "cwolan")
(tags-todo "dbolen") (tags-todo "jterranella")
(tags-todo "lortiz") (tags-todo "malzuru")
(tags-todo "dhalsey") (tags-todo "jkendall")
(tags-todo "kolson"))
)
("b" "Tom's basic block agenda"
((agenda "") (tags-todo
"+homeImprovement-household") (tags-todo "FAredesign")
(tags-todo "rhaass") (tags-todo "kolson")
(tags-todo "dhalsey") (tags-todo "hr")
(tags-todo "lhammes") (tags-todo
"StaffMeeting") (tags-todo "cfrappier") (tags-todo "espector")
(tags-todo "ahenry") (tags-todo "atrajkov")
(tags-todo
"+work-rhaass-kolson-cfrappier-jmcgrath-tkatavic-egosselin-aqualls-cshehadi-espector-pituk-ahalliday-metchison-nfreiberg-lhammes-emacs-lifelongLearning")
(tags-todo "computers") (tags-todo "desk")
(tags-todo "errands") (tags-todo "household")
(tags-todo "lifelongLearning") (tags-todo
"reading") (tags-todo "social"))
)
)
org-log-into-drawer t
org-use-fast-tag-selection t
org-agenda-files '("~/org-files/")
org-capture-templates '(("a" "Appointments & Meetings:appt:
timestamp" entry
RE: Timestamp parsing inside node properties and other contexts out of org-element-object-restrictions (was: [BUG] Agenda no longer works for timestamps inside properties drawer [9.5.2 (release_9.5.2-
Hi Tim, Thanks for these thoughtful comments. I agree that the Org developers (to whom I, as a mere user, owe enormous thanks) must be wary before making changes to how timestamps are handled. This argues, I would say, for keeping what I believe was the status quo since at least Org version 9.4.4: Agenda views would display entries with active timestamps in property drawers. That has been my historical experience. Tim, has your historical experience been different? In the invoicing example you give, were the timestamps in the properties drawer active, or inactive? I have just verified with a simple test that Org version 9.4.4, which was shipped with Emacs 27.2 I believe, does display entries with an active timestamp as the value of a property in the ordinary :PROPERTIES: drawer. That's the situation I'm calling the "status quo." I'm wondering if my experience coincides with the experience of others. Here's the simple entry that will be shown on the Week/Day Agenda view in 9.4.4: * TODO Test of active timestamps :PROPERTIES: :Created: <2022-03-22 Tue 18:30> :END: And note this: adding a second active timestamp to the test entry, e.g., to accompany a SCHEDULED: keyword, results in the entry appearing on the Agenda twice, as would be expected: * TODO Test of active timestamps SCHEDULED: <2022-03-22 Tue 18:30> :PROPERTIES: :Created: <2022-03-22 Tue 18:30> :END: This second example shows why the variable org-agenda-skip-additional-timestamps-same-entry is valuable. I rarely want an entry to display twice on the same day. Tom Davey -- Tom Davey t...@tomdavey.com New York NY USA -Original Message- From: Emacs-orgmode On Behalf Of Tim Cross Sent: Tuesday, March 22, 2022 5:10 PM To: Ihor Radchenko Cc: Ignacio Casso ; emacs-orgmode@gnu.org; t...@tomdavey.com; Nicolas Goaziou Subject: Re: Timestamp parsing inside node properties and other contexts out of org-element-object-restrictions (was: [BUG] Agenda no longer works for timestamps inside properties drawer [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]) Ihor Radchenko writes: > Ihor Radchenko writes: > >> After further reading the source code, I figured that agenda is, in >> fact, supposed to handle timestamps inside property drawers. Optional >> arguments for org-at-timestamp-p imply that, in agenda specifically, >> timestamps inside node properties are considered timestamps despite >> they are not being parsed as timestamps by org-element. > > Even though I fixed the reported issue with agenda not showing > headings with matching timestamps inside property drawers, this > situation is revealing a big inconsistency in Org mode's handling of timestamps. > > org-at-timestamp-p usage implies that Org syntax for timestamps is not > only context-dependent, but also depends on current command! > > org-at-timestamp-p is called with non-nil argument in a number of > functions in Org: > - org-clock-timestamps-change > - org-mouse-delete-timestamp > - org-mouse-context-menu > - org-follow-timestamp-link > - org-get-repeat > - org-auto-repeat-maybe > - org-time-stamp > - ... many more in org.el > > So, depending on the current command, Org may on may not treat objects > matching org-ts-regexp-both as timestamps. > > This situation complicates syntax and makes org-element unreliable > when dealing with Org buffers. > > Should we just simply allow timestamps to be a part of node property > values? Should we _not_ treat timestamp-looking text outside their > allowed contexts (like quotes, source blocks, etc) as timestamps? > I think we have to be very wary here. I can see any changes here causing lots of breakage for people. I know for my own use case, I use timestamps a lot in property draws and various source blocks. I never want any of them showing up in my agenda. As an example, I was recently working for a company which required that you put a timestamp in both a file header and in comments. The format they used was pretty much the same as an org-mode active timestamp. I use org mode to tangle the source files I write (as well as manage my client data, such as todos, invoicing, contacts etc), so these files are searched for agenda items, but I do not want any of those timestamps causing lines in my agenda views. These timestamps are most commonly found in source and example blocks. I think the only time an org timestamp should be recognised in a source block is when that source block is an org-mode source block. I don't think they should ever be 'recognised' in example blocks. IN addition, my invoicing solution, which is based on org, uses timestamps to track invoice periods etc. None of these should ever appear in the agenda. This information is typically tracked in property draws. Unfortunately, I think org times
RE: [BUG] Agenda no longer works for timestamps inside properties drawer [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]
Ignacio writes: > I've located the line in org-agenda.el responsible of the new behavior, > and the following patch seems to fix it. I suggest it is incorporated > into the repository, maybe with a variable org-agenda-skip-timestamps- > in-properties-drawer defaulting to t if not everyone agrees. I second that suggestion for the repository! Thanks very much for the patch. I think you are correct in supposing that when Emacs 28.1 is released, many Org users who upgrade will be mystified at the new timestamp behavior and will spend time without success trying to figure out what changed. Perhaps the new variable you propose, org-agenda-skip-timestamps-in-properties-drawer, should default to nil to preserve the historical behavior? -- Tom Davey t...@tomdavey.com New York NY USA -Original Message- From: Emacs-orgmode On Behalf Of Ignacio Casso Sent: Monday, March 21, 2022 7:21 PM To: t...@tomdavey.com Cc: emacs-orgmode@gnu.org Subject: Re: [BUG] Agenda no longer works for timestamps inside properties drawer [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)] >> What you see in the new Org version is not a bug. Property values are >> treated as plain text by Org. >> >> I was unable to find a place in manual describing that timestamps >> cannot be placed inside property values: >> I personally see allowing timestamps (and links) inside property values as a useful feature. >> Would it be of interest for other users? > > Yes, it's a quite useful feature. For years, via my Capture templates, I've been adding a property named :Created: to the properties drawer as follows: > > :PROPERTIES: > :Created: <2022-03-06 Sun 22:42> > :END: > > Now, in 9.5.2, literally hundreds of entries that formerly appeared on the built-in Agenda views cannot be easily found. It seems that I'm not the only one using this unintended feature in previous versions of org, and probably there will be many others who don't use the latest version of org and have not noticed yet but will have the same problem when they upgrade. I think that even if timestamps were never intended to be used inside property drawers before, the fact that it worked for a long time and nothing in the documentation suggested otherwise makes it a de facto feature, even if unintended, and should be preserved. I've located the line in org-agenda.el responsible of the new behavior, and the following patch seems to fix it. I suggest it is incorporated into the repository, maybe with a variable org-agenda-skip-timestamps-in-properties-drawer defaulting to t if not everyone agrees.
RE: [BUG] Agenda no longer works for timestamps inside properties drawer [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]
Ihor writes: > I personally see allowing timestamps (and links) inside property values as a > useful feature. > Would it be of interest for other users? Yes, it's a quite useful feature. For years, via my Capture templates, I've been adding a property named :Created: to the properties drawer as follows: :PROPERTIES: :Created: <2022-03-06 Sun 22:42> :END: Now, in 9.5.2, literally hundreds of entries that formerly appeared on the built-in Agenda views cannot be easily found. Regards to all, Tom PS The variable 'org-agenda-skip-additional-timestamps-same-entry seemed expressly made for my use case, to clean up same-day clutter in entries with a TODO timestamp. -- Tom Davey t...@tomdavey.com New York NY USA -Original Message- From: Emacs-orgmode On Behalf Of Ihor Radchenko Sent: Saturday, March 12, 2022 7:29 AM To: Ignacio Casso Cc: emacs-orgmode@gnu.org Subject: Re: [BUG] Agenda no longer works for timestamps inside properties drawer [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)] Ignacio Casso writes: > In Emacs 27.2, with an up to date version of org from ELPA (9.5.2), > org-agenda considers timestamps that appear in property drawers, so > the entry below appears in the daily agenda view. > > * Heading > :PROPERTIES: > :timestamp: <2022-03-12 sáb> > :END: > > However, in the latest Emacs version built from source (29.0.50), with > the built-in version of org (also 9.5.2, but the latest release, I > assume), this is no longer the case and that entry does not appear in > the agenda view. > > I know that maybe it's unorthodox, but I have some org files that rely > in the previous behavior, with entries like the following: > > * Some friend > :PROPERTIES: > :birth-date: <1994-03-12 sáb +1y> > :END: > > Is this a bug? If it's not, can someone point me to the functions I > need to touch to restore the previous behavior? Or maybe I should stop > doing this and start moving those timestamps out of the properties > drawer in my files? What you see in the new Org version is not a bug. Property values are treated as plain text by Org. In the older versions, agenda code did not rely on Org's internal parsing and matched timestamps in places where timestamps are not allowed (inside code blocks, for example). See https://orgmode.org/list/20220101122409.ga29...@itccanarias.org Dear all, I was unable to find a place in manual describing that timestamps cannot be placed inside property values: >> A timestamp is a specification of a date (possibly with a time or a >> range of times) in a special format, either ‘<2003-09-16 Tue>’ or >> ‘<2003-09-16 Tue 09:39>’ or ‘<2003-09-16 Tue 12:00-12:30>’(1). A >> timestamp can appear anywhere in the headline or body of an Org tree >> entry. Its presence causes entries to be shown on specific dates in >> the agenda (see *note Weekly/daily agenda::). We distinguish: I personally see allowing timestamps (and links) inside property values as a useful feature. Would it be of interest for other users? In any case, we should probably clarify manual in this regard. Best, Ihor
RE: Bug: doc string for "org-end-of-meta-data"
Hi Marco, You make sense. What you propose to substitute is easier to understand and concise: When FULL is non-nil but not t, skip planning information, properties, clocking lines and logbook drawers. Thank you! -- Tom Davey t...@tomdavey.com New York NY USA -Original Message- From: Marco Wahl Sent: Wednesday, September 15, 2021 5:04 PM To: Tom Davey Cc: 'emacs-org list' Subject: Re: Bug: doc string for "org-end-of-meta-data" Hello Tom, > I believe the last paragraph of the doc string for the function > "org-end-of-meta-data" contains an error. That one-sentence paragraph > currently reads: > > When FULL is non-nil but not t, skip planning information, > clocking lines and only non-regular drawers, i.e. properties > and logbook drawers. > > I believe that should be "regular drawers," not "non-regular drawers." > IMO, the last paragraph could be clearer were it rewritten as follows: > >When FULL is non-nil but not t, skip only planning information, >clocking lines and regular drawers, i.e. properties and logbook >drawers. If any non-regular drawers exist and do not follow the >two regular drawers, stop at the first non-regular drawer instead. > > I believe that this expansion of the paragraph corrects the error and > adds coverage of a rare case. I think the use of the word "regular" is not a good idea in their documentation of org-end-of-meta-data. I could not find any occurance of the term "regular drawer" in the org-info manual. There is a section where the property drawer is called "special". In conclusion I'd say that the logic of the recent documentation is okay with "regular" meaning "non-special". Finally I propose to remove completely the categorisation due to "regular" from the documentation. Which reads: When FULL is non-nil but not t, skip planning information, properties, clocking lines and logbook drawers. WDYT?
Bug: doc string for "org-end-of-meta-data"
Hello everybody, I believe the last paragraph of the doc string for the function "org-end-of-meta-data" contains an error. That one-sentence paragraph currently reads: When FULL is non-nil but not t, skip planning information, clocking lines and only non-regular drawers, i.e. properties and logbook drawers. I believe that should be "regular drawers," not "non-regular drawers." IMO, the last paragraph could be clearer were it rewritten as follows: When FULL is non-nil but not t, skip only planning information, clocking lines and regular drawers, i.e. properties and logbook drawers. If any non-regular drawers exist and do not follow the two regular drawers, stop at the first non-regular drawer instead. I believe that this expansion of the paragraph corrects the error and adds coverage of a rare case. Many thanks to all the developers of Org-mode. -- Tom Davey t...@tomdavey.com New York NY USA
Re: [O] org-speed-commands-default 1 2 3
Rainer writes: Using 0 as speed key I end up with: That's lovely! I hadn't thought of using a user-defined speed key. Much more convenient. Regards, Tom Davey -- Tom Davey t...@tomdavey.com New York NY USA
Re: [O] org-speed-commands-default 1 2 3
Olen writes: Level 2 is very useful - and cannot, unlike Level 1, be reached by S-TAB. Actually, it can. S-TAB takes a numeric prefix key. The doc string says: When ARG is a numeric prefix, show contents of this level. So, you can directly open or close the outline to _any_ desired level N with C-N S-TAB. I find that feature to be incredibly handy. It encourages me to nest my outlines as deeply as I wish. Here's a little navigation utility I wrote to take advantage of S-TAB's ability. Sometimes I'll want to collapse the outline to the level at point in order, say, to clean things up by closing all lower levels. However, it's not always obvious to me what level I'm on. And without knowing what level I'm on, I can't hit the right numeric prefix for S-TAB. The following utility does it all automagically by passing the result of org-outline-level() to S-TAB. C-S-TAB is a logical binding for this function. (defun open-org-outline-to-current-level () Opens or closes the Orgmode outline to the level at point. (interactive) (org-shifttab (org-outline-level)) (message The current outline level is %s. (org-outline-level))) Regards, Tom Davey On Thu, Aug 8, 2013 at 9:02 AM, Oleh ohwoeo...@gmail.com wrote: On Thu, Aug 8, 2013 at 9:01 AM, Carsten Dominik carsten.domi...@gmail.com wrote: On 23.7.2013, at 15:48, Oleh ohwoeo...@gmail.com wrote: Hi all, I've recently started using `org-use-speed-commands', and I like it a lot, except I had to make one tweak: (setq org-use-speed-commands t) (setq org-speed-commands-user '((1 . (org-shifttab 1)) (2 . (org-shifttab 2)) (3 . (org-shifttab 3 The corresponding values of `org-speed-commands-default' aren't that useful for GTD: (1 org-priority 65) (2 org-priority 66) (3 org-priority 67) That depends on wether you work with priorities. I find S-TAB easy enough, so I do not really see the need for speed commands here. Maybe I should elaborate my point of view on the usability. Priorities don't normally need buttons to jump between states, a knob is enough: only increase/decrease priority, not jump to priority 1, jump to priority 2 etc. Outlines, on the other hand, can benefit from the ability to jump between the levels of expansion. Level 1 is very useful - it minimizes everything, showing the structure of the file. S-TAB is useful and simple, but you have to repeat several times, checking each time if it has brought you to the level that you wanted to be on. Level 2 is very useful - and cannot, unlike Level 1, be reached by S-TAB. For my gtd.org, it shows the tasks and appointments, without expanding them, as well as the project names, but not what they contain. This gives a nice overview of my projects. Level 3 is very useful - and cannot be reached by S-TAB. It shows me the separate TODOs for my projects, without revealing my notes on them, just the headings. I even bound the rest of the digits to levels and it is useful sometimes. In my opinion, these shortcuts make org-mode a better outlining tool, and should be given priority before the priority shortcuts. Slightly off-topic, these type of shortcuts is why I use Ubuntu Unity (I think I managed to turn off the spying). It's got a feature that Super+1-9 switches between applications in the sidebar slots 1-9. Sure, it's possible to do with Alt-TAB, and that's what most other desktops do, but Super+1-9 is superior, since you don't have to wait for feedback, you instantly get what you want. regards, Oleh -- -- Tom Davey t...@tomdavey.com New York NY USA
Re: [O] Problem with org-insert-heading on multi-line items?
Hi Nick Thanks for the reply, and thanks for trying to reproduce what I'm seeing. You've made me realize that I have filed a weak bug report. I owe the list a reproducible test case. I will get going on that. Regards, Tom Davey -- Tom Davey t...@tomdavey.com New York NY USA
[O] Problem with org-insert-heading on multi-line items?
Hi folks, I'm using Org 8.0.3 and Emacs 24.3.1. I noticed with interest this note in the Org 8.0 release notes: When a list item has a checkbox, inserting a new item uses a checkbox too. I'm finding, however, that Org will in many cases insert a new checkbox even if the current item has none. Specifically, invoking org-insert-heading on the second or subsequent lines of a multi-line item will create a new checkbox item every time, whether the current item has a checkbox or not. To illustrate: 1. org-insert-heading invoked here creates a new plain item 2. org-insert-heading invoked on this second item does the same 3. However, org-insert-heading, invoked on the SECOND line of this creates a following checkbox item: 4. [ ] However, invoking org-insert-heading on the first line of a multi-line item creates new items of the correct type, checkbox or not. So it seems like the first line is determinative. May I ask if anybody else is seeing this behavior? Is it as designed? Regards, Tom Davey -- Tom Davey t...@tomdavey.com New York NY USA
Re: [O] New maintainer
Hi everybody, I'm just an Org user, one of the many anonymous persons who have benefited from this fantastic piece of software. Over the past two years I have come to use Org every day, all day long, more than any other application with the possible exception of a Web browser. It's hard to overestimate the value I receive from Org, the sheer personal effectiveness I've gained. Bastien, a thousand thanks for your work as maintainer. Thanks as well to all the other skillful and creative programmers on this list who make org continually more powerful and astonishing. Especial thanks to Carsten, both for the past and now in advance as the new maintainer. With grateful regards to all, Tom Davey -- Tom Davey t...@tomdavey.com New York NY USA
Re: [O] Babel related bug in elpa version 20121231
Hi folks, This is a very interesting discussion. I too have run into this issue, and addressed it in a different way. My init.el contains only a defun and an add-hook. The defun is simple. It adds a few miscellaneous directories to load-path and then makes the call to Eric's starter kit via org-babel-load-file(). The trick is this: I add the defun to the hook after-init-hook. This ensures that my personal initialization, including the Starter Kit .org files, doesn't begin to execute until all the ELPA packages are initialized. That way my own initialization can depend on a fully stabilized Emacs. (add-hook 'after-init-hook 'my-after-init-hook-functions) I found this useful because my personal initialization makes little tweaks to my ELPA packages. It seems to give me the control over the order of initialization that I need. Regards to all, Tom Davey -- Tom Davey t...@tomdavey.com New York NY USA
Re: [O] How to convert to odt with specific styles?
But considering that no one made such a request, he removed it from org-e-odt.el. I can re-instate the removed changes in to org-e-odt.el. I agree, that would be great. I have the same use case as Joakim: frequent exports to MS Word templates with predefined style sets. Thanks very much! Tom Davey On Tue, Jan 1, 2013 at 5:52 PM, Bastien b...@altern.org wrote: Jambunathan K kjambunat...@gmail.com writes: But considering that no one made such a request, he removed it from org-e-odt.el. I can re-instate the removed changes in to org-e-odt.el. That'd be great. Thanks! -- Bastien -- -- Tom Davey t...@tomdavey.com New York NY USA
Re: [O] [BUG] [ODT] ODT export (old) fails with wrong-type-argument
Christian writes: I confirm -- this is fixed in release_7.9.2-513-gad17c4. Great news. Bastien, many thanks! Tom -- Tom Davey t...@tomdavey.com New York NY USA
