From: Samuel Wales <email@example.com>
To: Ignacio Casso <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.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/)]
Date: Mon, 21 Mar 2022 17:50:38 -0700 [thread overview]
Message-ID: <CAJcAo8u13RejQ=YXy1MgCgLa=S4zZ7xgmChcWC7pVed1unxzgA@mail.gmail.com> (raw)
this is merely intuition, but i can
- understand why planning line tses should not be matched in various
places; they are closely tied to real org entries
- not quite grasp why bare active and inactive tses should not be
matched by ts agenda almost anywhere including blocks. perhaps the
idea is that you might wnt to store lots of data with tses and they
would be too much clutter?
- understand that there are probably plenty of implementation issues
that might obtrude and should be respected
so i guess i am interested in the rationale. example of ts [and text]
search being useful might be an example or ledger block that contains
ledger source, or something like that. i can get why bare ts not
being matched inside links might be useful.
otoh i can get why text [not ts] and isearch search inside of links
can be useful.
idk if my intuitions match those of others. i am partly trying to
think of what a newcomer might expect to work [and the simplicity of a
rule that he or she would have to remember in order to know what the
behavior will be].
On 3/21/22, Ignacio Casso <email@example.com> wrote:
>>> 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
>> :Created: <2022-03-06 Sun 22:42>
>> 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.
The Kafka Pandemic
A blog about science, health, human rights, and misopathy:
next prev parent reply other threads:[~2022-03-22 0:51 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-12 10:06 Ignacio Casso
2022-03-12 12:28 ` Ihor Radchenko
2022-03-21 15:58 ` Tom Davey
2022-03-21 23:21 ` Ignacio Casso
2022-03-22 0:50 ` Samuel Wales [this message]
2022-03-22 10:02 ` Ihor Radchenko
2022-03-22 10:17 ` Ihor Radchenko
2022-03-22 21:02 ` Tim Cross
2022-03-23 12:07 ` Ihor Radchenko
2022-03-23 0:10 ` Samuel Wales
2022-03-23 12:21 ` Ihor Radchenko
2022-03-24 3:38 ` Samuel Wales
2022-03-22 3:43 ` Tom Davey
2022-03-22 9:47 ` Ihor Radchenko
2022-03-22 10:00 ` 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
2022-03-22 21:10 ` Tim Cross
2022-03-22 23:16 ` Tom Davey
2022-03-23 0:25 ` Tim Cross
2022-03-23 13:13 ` Ihor Radchenko
2022-03-22 23:05 ` Timestamp parsing inside node properties and other contexts out of org-element-object-restrictions Nicolas Goaziou
2022-03-23 13:06 ` Ihor Radchenko
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).