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)

[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 party
> and personal code that ... who knows what parsing lurks.  unintended
> consequences and all that.
>
> i checked my very old own code and indeed i'm not trying to get the
> repeater with strict re character group, but in principle i can
> imagine code by others could have.

Well. I'd say that repeat count has been requested enough to strongly
consider adding it. I guess an alternative could be setting a heading
property to limit the number of repetitions.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

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)

[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.
>
> 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 repeaters], [in principle in tses if tz complexity
> turns out to demand more user specification etc.], and 2] 3rd party
> and personal code that ... who knows what parsing lurks.  unintended
> consequences and all that.
>
> i checked my very old own code and indeed i'm not trying to get the
> repeater with strict re character group, but in principle i can
> imagine code by others could have.
>
>>
>> --
>> Ihor Radchenko // yantar92,
>> Org mode contributor,
>> Learn more about Org mode at .
>> Support Org development at ,
>> or support my work at 
>>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

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)

[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 repeaters], [in principle in tses if tz complexity
turns out to demand more user specification etc.], and 2] 3rd party
and personal code that ... who knows what parsing lurks.  unintended
consequences and all that.

i checked my very old own code and indeed i'm not trying to get the
repeater with strict re character group, but in principle i can
imagine code by others could have.

>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

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)

[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 change in timestamp syntax:

<2023-01-14 Sat +1w/5x>

However, it is almost the same with what we have for habits:

<2023-01-14 Sat +1w/2w>

I do not see how things are going to break even if third-party packages
use some home-grown parsers.

> if otoh org provides really good api that can even do that, then i
> suppose you could tell those devs to use that api.

`org-get-repeat', `org-get-wdays', and `org-element-timestamp-parser'.

> also my personal preference is for less new org syntax.  which is one
> reason why i like cl-style sexp kw for future features and
> subfeatures.  syntax can be hard to look up in the org manual, hard to
> remember, etc.  but that's mho.

My proposal is as little new syntax as I was able to come up with.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

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)

[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 that is
embedded in another syntax.  [like, parsing diffs of org, with
planning line tses and perhaps trying to accommodate various user
settings for org indentation where possible.]

if otoh org provides really good api that can even do that, then i
suppose you could tell those devs to use that api.

also my personal preference is for less new org syntax.  which is one
reason why i like cl-style sexp kw for future features and
subfeatures.  syntax can be hard to look up in the org manual, hard to
remember, etc.  but that's mho.

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

[Ihor Radchenko]

Russell Adams  writes:

>> > I know they include better repeat information. Maybe we can
>> > build on that?
>>
>> Is it really better? Apart from sexps, diaries support cron-like
>> repeaters, but more limited.
>
> They have repeat with a end date or max iterations.

Good point. These two features are also frequently requested by users.
However, I do not see why we cannot implement them within the current
Org timestamp syntax:

1. <2023-01-14 Sat +1w>--<2024-01-14 Sun>
   can be treated as a repeater with end date.

2. <2023-01-14 Sat +1w/5x>
   can be treated as a repeater with limited number of iterations

The above are backwards-compatible with Org timestamp syntax.

Supporting these cases will require:
1. Updating syntax spec
2. Changing `org-auto-repeat-maybe' to decrease +1w/5x to +1w/4x upon
   updating the timestamp and not repeating when the limit has been
   reached.
3. Updating org-agenda to not display timestamps beyond the limit.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at