***** 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.
