Re: [FR] Allow end date and max repeat count for timestamps with repeaters (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

2023-01-16 Thread Ihor Radchenko
Samuel Wales writes: > but i just wanted to bring up the issue of 1] the possibility of > drawing a line in the sand at some point wrt creeping syntax [even if > not in tses for repeaters], [in principle in tses if tz complexity > turns out to demand more user specification etc.], and 2] 3rd

Re: [FR] Allow end date and max repeat count for timestamps with repeaters (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

2023-01-15 Thread Samuel Wales
to be clear, i won't object to that syntax, as i think it is as intuitive as anything else in tses already, but do have the concerns i raised in general. On 1/15/23, Samuel Wales wrote: > On 1/15/23, Ihor Radchenko wrote: >> My proposal is as little new syntax as I was able to come up with. >

Re: [FR] Allow end date and max repeat count for timestamps with repeaters (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

2023-01-15 Thread Samuel Wales
On 1/15/23, Ihor Radchenko wrote: > My proposal is as little new syntax as I was able to come up with. i kind of like it actually. :] but i just wanted to bring up the issue of 1] the possibility of drawing a line in the sand at some point wrt creeping syntax [even if not in tses for

Re: [FR] Allow end date and max repeat count for timestamps with repeaters (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

2023-01-15 Thread Ihor Radchenko
Samuel Wales writes: > On 1/14/23, Ihor Radchenko wrote: >> However, I do not see why we cannot implement them within the current >> Org timestamp syntax: > > my concern would be personal code and 3rd-party packages, which might > have their own peculiar parsing. I proposed a single slight

Re: [FR] Allow end date and max repeat count for timestamps with repeaters (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

2023-01-14 Thread Samuel Wales
On 1/14/23, Ihor Radchenko wrote: > However, I do not see why we cannot implement them within the current > Org timestamp syntax: my concern would be personal code and 3rd-party packages, which might have their own peculiar parsing. that parsing might even be of non-org files with org syntax