Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Repeaters for dates #702

Open
1 task done
pianocomposer321 opened this issue Jan 3, 2023 · 13 comments
Open
1 task done

Repeaters for dates #702

pianocomposer321 opened this issue Jan 3, 2023 · 13 comments
Labels
feature Issues related to feature proposals. Please attach a module.

Comments

@pianocomposer321
Copy link

Issues

  • I have checked existing issues and there are no existing ones with the same request.

Feature description

In org files, a date can have a repeater like so:

<2023-01-03 +1w>

The +1w makes the timestamp repeat every week, and it will show up in the agenda every week as if there was a date for each one of them, but without having to add them in manually.

I couldn't find any equivalent functionality in neorg. I looked through the spec file (though it's so large it's entirely possible I missed something in there), searched through reddit, the issues here, and the discussions, and I'm kinda surprised nobody else has even brought it up...

Is there a way to do this already that I just entirely missed somehow, and if not, is there a plan to add it?

Help

Yes, but I don't know how to start. I would need guidance

Implementation help

I'm willing, but not totally sure about able ;-). I'm kinda busy with stuff right now, but I could probably work on this off and on if it's not already a feature. Would obviously need help though, it would be my first contribution to this project. Not sure how I would get started at all.

@pianocomposer321 pianocomposer321 added the feature Issues related to feature proposals. Please attach a module. label Jan 3, 2023
@katawful
Copy link
Contributor

katawful commented Jan 3, 2023

This would be a GTD issue, which is in the process of being reimplemented. The norg spec doesn't need to specify this as there are generic ways to modify groups

Follow #695 for more info

@pianocomposer321
Copy link
Author

This would be a GTD issue, which is in the process of being reimplemented.

Ah, yes this makes sense. I read back over the spec again and any "agenda" seems to be an extra thing from GTD, you're right.

The norg spec doesn't need to specify this as there are generic ways to modify groups

I'm not sure I understand...what are groups? What "generic ways to modify" them are there?

@max397574
Copy link
Contributor

I'm not completely familiar with the new spec yet
but with the old one you could add tags like #time.due 11-11-2023

@pianocomposer321
Copy link
Author

pianocomposer321 commented Jan 3, 2023

@max397574 Unless I'm mistaken, there is not yet a new spec for GTD - the new spec for the 1.0 release is only for the syntax of .norg files itself. As far as base neorg is concerned, #time.due is just a regular old tag. It was the GTD module that identified a tag starting with time as special, and because GTD has been "nuked", adding this tag will not do anything more than any other tag would, unless I'm mistaken.

It still seems to me that neorg's documentation is not totally comprehensive. I'm sure now that 1.0 has been released this is probably an area that will improve shortly, but for now concepts such as dates, times, what was part of GTD and what was and still is a part of base neorg, and what exactly changed when 1.0 was released, etc., etc., etc. is a little fuzzy. For example, in the main spec there seems to be mention of timestamps with the following syntax: <day>,? <day-of-month> <month> <year> <time> <timezone>, but then there also seem to be dates in the format @max397574 mentioned above with the #time.due tag: dd-mm-yyyy - but I didn't see documentation for these anywhere, in the spec or elsewhere.

All this is a bit confusing, and I do hope that documentation improves with time. I understand that in the grand scheme of things this project is fairly new, particularly for such an ambitions undertaking as defining a new file format from the ground up. Can't wait to see where this goes in the future, and I also hope the video tutorials that I've seen mentioned a few times happen as well.

@max397574
Copy link
Contributor

the spec is done the way it is
it's just the formal spec for norg
what you wrote

<day>,? <day-of-month> <month> <year> <time> <timezone>

is part of the new syntax

what I mentioned above was an example for this

What "generic ways to modify" them are there?

this was how it was done with the old spec
not sure how it would look in the new one but I'm sure something similar is possible

@pianocomposer321
Copy link
Author

Ok, thanks that makes a little more sense.

But I still don't really understand what is meant by the phrase "generic ways to modify groups". What is a group?

The reply from @katawful is very vague and hard to understand tbh.

The norg spec doesn't need to specify this as there are generic ways to modify groups

What is "this", what are "groups", and what does it mean to "modify" them, what is meant by them being "generic"...I could go on. None of this makes sense without context.

@katawful
Copy link
Contributor

katawful commented Jan 3, 2023

"Detached modifiers" modify whatever is grouped below. It's generic because it applies to many things, you can modify links, lists, headers, definitions, etc...

See: https://github.com/nvim-neorg/norg-specs/blob/main/1.0-specification.norg

Also includes dating syntax

@vhyrro
Copy link
Member

vhyrro commented Jan 3, 2023

Hi! There are a few syntax elements built in to the new spec to help us with times and dates, but the date syntax is not fully complete, and will be improved upon as we go in incremental iterations to the spec (1.1, 1.2 etc).

I see you've read the default syntax present in the spec, in which case this:

{@ Tue 3rd January 2023 19:00 GMT}

should be familiar (I hope :p). There is a way to recur dates by omitting information:

{@ Tue} <- Matches every tuesday
{@ Tue January} <- Matches every tuesday in january

but this is about as far as it gets in the format as is. It's on the TODO to make recurring dates work better, I haven't found a way to do it rigorously/unambiguously yet :p

@pianocomposer321
Copy link
Author

@vhyrro Thanks, that answers my question! Should I close this or keep it open for tracking said iterations to the spec as they relate to this issue?

@vhyrro
Copy link
Member

vhyrro commented Jan 3, 2023

You can keep it open here for reference :)

@pianocomposer321
Copy link
Author

Oh, and just one more question to clarify, with the new spec dates such as 2023-01-03 should no longer be used anywhere?

@vhyrro
Copy link
Member

vhyrro commented Jan 3, 2023

This is a topic worth discussing. Currently the spec only allows for the format present in my message, but having a fully rigorous YYYY-mm-dd format would be nice to have in the toolbelt for cases when you really need it. I don't know how I want this to play in with the current syntax though without complicating things too much 🤔. I'll give it some thought overnight today, and will report tomorrow if I have any observations! For now though treat YYYY-mm-dd as unsupported by neorg

@pianocomposer321
Copy link
Author

Awesome, sounds good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Issues related to feature proposals. Please attach a module.
Projects
None yet
Development

No branches or pull requests

4 participants