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/)]

[Samuel Wales]

***** x2
> Could you elaborate? Maybe provide an example.

idk if this answers your q or not.

it rambles.

for context some goals include orthogonality, satisfying
strong differing views/needs with little complexity, and
having simple rules or transparency for knowing behavior
e.g. what shows up in an agenda view.

by line comments i mean "# " in recent org since 9 or so and
"#" in org up until then.  with leading spaces or whatever.

for clarity i will treat COMMENT quasi-kw separately if at
all.  it is like ARCHIVE.

fundamentally line comments prevent lines from being
exported.  so you could do

\* my header to be exported via subtree export
# NOTE TO SELF: see https://google.com for more on this.
# fixme see https://whatever.whatever for new change
something that will actually export

and that was just for yourself.  it would not get exported.
for reference.

and the link would be for this case highlighted and
clickable [and show up in agenda text view].

idr the details now, but links were clickable without being
highlighted at one point, and accidental clicks were
dangerous.  you could work around that with font lock and
idk what changes have occurred since then.

i have just described the "line comments mean don't show in
export" rule.  the intuition of some has been that links
should as above still be useful, even though they do not
export.  comenting is mostly related to exporting.

others have thought commenting means commenting.  they think
there should be no semantics at all when you comment links.
thus, links are inert pieces of text.  if you want to go to
google then you copy the text and paste it into a browser.

===

up to here i have described links.  but ts issues are
similar to links.  e.g. fontifying and clicking.

they are supposed to show up in daily/weekly for the date of
the ts.  except when they are not supposed to.  which varies
by preference.  (which is reolated to the currentish
controversyish wrt drawers and blocks --- i am saying line
comments are a valid similar consideration.  i have a
possible solution for all.)

for a non-exporting entry, you might want to comment out a
ts so it does not show up.  what is canonical there?  the
second type of user says just comment it.  the first type of
user says tses should be useful in comments.

\* my header to be exported via subtree export
# i wrote this paragraph on this date: [2022-03-23 Wed]
something that will actually export

or the active ts version.  tses are also highly useful to
see fontified and be clickable analogously to links.  (to
the first type of user.)  you might want to know the changes
you made to your docuyment on that date, so it shows in
daily/weekly agenda [stndard disclaimes like in log mode if
inactive etc.].  you should not be restricted to text search
to find a ts or a range of tses.

you want things to be able to show up nd still not be
exported.

some would say if it is fontified, you know it is a ts; it's
visually useful even if you do not use the semantics.

some might make the point that fundamentally active tses are
meant to show up by default in daily/weekly and if you want
something to not show up in non-log-mode you should just
make it inactive.

you could consider daily/weekly being different from text
search to be an inconsistency which requires fixing by
making it transparent, one possibility being making it in a
variable saying where tses will show up.

===

so to a solution for most of this.  i rambled and idk what
you are asking for.

first, i made a mistake due to brain not working, in my
parenthetical examples, but i think you got the idea.

just to get that part nailed down even though it was
probably obvious, vars can contain sets.  thus, a single var
can dictate e.g. what shows up in daily/weekly agenda.  if a
ts is in a context that is mentioned in a member of var,
then it shows up in daily/weekly agenda view.  the var's
value could be e.g. '(properties-drawers line-comments).
(perhaps modulo some reasonable thing to do for body text,
headers, etc. where it is not worth having them be
explicitly members in that var or so.)

thus if some users want tses in properties drawers (or
source blocks, or line comments) to show up in daily/weekly
and other users do not, then this might be a solution for
satisfying both types of users, and also those who have n>1
use case (sometimes one and soetimes the other).  and
changing default would be trivial and user can change it and
user can c-h v thus the user does not have to guess about
behavior or think about org versions or pull hair out trying
to comment something out from showing up or GET it to show
up.

note that this reduces a bunch of potential variables down
to just one.  merely: what shows up in daily/weekly view.

for some purposes, you cn sticik this variable in a custom
command clause.

for completeness, other considerations exist like
clickability (viz. in what contexts should a ts or link be
clickable?  perhaps all thus no need to specify in a var?),
fontifying (perhaps simplest rule is "if a ts or link is
clickable, it should be fontified and vice-versa" with no
need to specify in a var?), what should show up in text
search view (an analogous var or not necessary because
everything shows up?) and org-occur-in-agenda-files
(currently inconsistent with the second type of user) and
isearch --- personally it drives me crazy tht parts of links
are not isearchable without doing visible-mode first but
that is just me.  there are inconsistencies of various
strengths.  some of them probably fixable while satisfying
desieratda if there is a desire to.