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 Radchenko]

Samuel Wales <samologist@gmail.com> writes:

> your idea of expanding to other date-like things is an interesting
> idea, and so is making an analogy with log mode.
>
> another possibility is to satisfy the preferences users have expressed
> [and those with n>1 needs] using a single variable that contains the
> contexts that should show in daily/weekly agenda.  org uses multi-item
> variables more frequently in recent years [e.g.
> org-show-context-detail or visibility for sparse trees] which reduces
> vars.  you might have had log mode items in mind, which is similar.

Your idea about multi-term variables reminds me about
org-agenda-log-mode-items. So, the proposed broad matching of anything
time stamp-like under headlines might be a new option in that variable:

org-agenda-log-mode-items is a variable defined in org-agenda.el.
Documentation
List of items that should be shown in agenda log mode.

This list may contain the following symbols:

  closed    Show entries that have been closed on that day.
  clock     Show entries that have received clocked time on that day.
  state     Show all logged state changes.
Note that instead of changing this variable, you can also press C-u l in
the agenda to display all available LOG items temporarily.

> [one problem now being that users can be not merely surprised, but
> unaware that stuff is missing from agenda.]

To clarify, this bug report came after another commit I introduced. That
commit fixed a user complaint that it was literally impossible to
prevent headlines from being shown in agenda when, for example, a
timestamp was inside a code block or quote block.
https://orgmode.org/list/20220101122409.GA29829@itccanarias.org

So, in the past, agenda showed every headline containing matching active
(or inactive, if inactive timestamps where set to be included in agenda)
timestamp anywhere under headline regardless of the context.
I changed that, causing the bug report here.

Now, I fixed the regression noticing that agenda views where intended to
catch timestamps inside property drawers according to
(org-at-timestamp-p 'agenda)

The current fix did not restore the initial behaviour of including every
possible timestamp regardless of the context, but that behaviour appears
to be unintentional given the docstring of org-at-timestamp-p:

Non-nil if point is inside a timestamp.

By default, the function only consider syntactically valid active
timestamps.  However, the caller may have a broader definition
for timestamps.  As a consequence, optional argument EXTENDED can
be set to the following values

...
  agenda

    Include timestamps allowed in Agenda, i.e., those in
    properties drawers, planning lines and clock lines.

> another context [not to create controversy but also for in principle
> orthogonality] is line comments, which some think should mean tses and
> links therein should not show up in agenda and not fontify and not be
> clickable [rule = "remove tses and links from org semantics and
> fontification including agenda but not including certain org searchers
> like org-occur-in-agend-files"], while others think should mean
> "remove from all export" [use case: so you as author can document
> exportable stuff inline using comments and still have your tses show
> up in daily/weekly if you want that and have clickable links without
> having those exposed to the recipient of the exported document, etc.].
> links in line comments can be worked around with a bit of code, but
> idk about tses.  some will want tses commentable.  some not.
>

Could you elaborate? Maybe provide an example.

Best,
Ihor