[FEATURE]: Add calendar UI

[vhyrro]

Shhh, it's a secret :shushing_face:

[vhyrro]

For those wondering about the state of this - it hasn't been forgotten by any means, but there are other things to do right now. Stuff like the specification (which is really important) and the semantic analyzer (which would solve a lot of shortcomings in neorg right now). Hang on tight!

[vhyrro]

Here's the current prototype UI! Ignore the 22 being highlighted in all months 😂

[andreadev-it]

Hi @vhyrro, I'm very interested in this specific feature (and dates features in general). Is there a way for me to help you with this?

[vhyrro]

Hey @andreadev-it, stoked to hear! I'll cook up a draft for the calendar UI in a markdown file, explaining how it should all work. After that you'll see what there is to work on hopefully it should be more clear where I could use some help :p

[vhyrro]

Hey @andreadev-it! About the calendar - I've added some preliminary information about how the calendar should behave in the ROADMAP.md file. It's by no means complete, so feel free to continuously ask questions about anything that's unclear :p

Sorry for taking so long with it! I was pretty damn busy the last ~2 weeks.

[andreadev-it]

Hi @vhyrro , don't worry 🙂 I've read the calendar section in the roadmap, and based on what you written, both in that section and this PR, I thought about summarizing the functionalities in this way, let me know what you think:

The calendar UI should allow users to:

• Select a date
• Select a date range
• Open multiple calendar views
• Allow to have a calendar without needing to select a date (e.g. when checking an agenda)
• Insert a date in a norg file

About the customizable sections of the calendar, these are what I could come up with:

• Default way to open the date selector calendar (either split or floating)
• Max number of months to show as a preview before/after the current month when space is available
• Localization for month names (I don't know if this belongs here, honestly)
• Default date format when adding a link

I don't necessarily think that all this functionalities should be available right off the bat, this is more of a generic goal for the module. Also, there might very well be functionalities that I didn't think of. If its fine with you, I could start work on it as an external module based on the work you've already done here (it is easier for me to work like that rather then working in the calendar branch, which is out of date) and then make a PR integrating it into neorg when the module is ready.

I also thought it might be more useful to also have a core.dates module that contains some generic and useful functionalities related to dates (e.g. parsing a date link like "27th, March 2023")

What do you think?

[vhyrro]

@andreadev-it yup you've got it! Just to clarify though - there should still be one calendar, it should just be extensible enough to support all the use cases (standalone mode, pick a date mode, pick a date range mode, and so on). Perhaps the exact behaviour could be contained in a lua table that is passed to the open_calendar function and determines how it should behave. Either that, or things that hook into the module (like the GTD module which should provide task info) should be able to determine what "mode" they're in (standalone, date picking, etc.) so that they can adapt accordingly.

Stuff that is outside of the range of a calendar (like inserting a date) shouldn't be done by this module, but rather by another module that merely calls the calendar to query what date it should insert.

I rebased this branch on top of main by the way, that way you can work on the module directly here :)

[andreadev-it]

Thanks @vhyrro ! Ok, I wrote "open multiple calendar views" based on the comment you left in the calendar.lua file at line 22, but maybe I didn't completely understand what you meant there...

I forked the repo and started working on it. I fixed an issue that is currently on the calendar module that created missing or duplicated months. To share that work, I should create a PR from the "neorg-calendar-view" branch in my fork to the branch with the same name in this repo, right?

[andreadev-it]

Just as a check, what is still needed to be able to ship the calendar module? I ask this so that I know what to prioritize 🙂

[vhyrro]

For the calendar module we still want the ?, i and movement keybinds to work, and then I think it's okay for us to ship a beta sort of version that we can improve as time goes on! The i keybind should ideally be pretty flexible, so that'll likely take the longest amount of time.

i should allow partial dates and full dates in accordance with the spec. This means that just inputting 27 should be understood as "the 27th of this month", or just Tue should be understood as "next tuesday" (if the current day is tuesday then it's unlikely the user went out of their way to type "Tue" just to get today's date), and so on. I'm unsure how practical this is, but since every field is in theory possible to disambiguate easily, we could also allow dates without any order. specified Tuesday March 5th could be supported if someone had a brainfart and just wanted to type quickly :p. Years have to be 4 digits as per the spec anyway, so even something like 2022 03 is possible to parse unambiguously.

Then there are the inbuilt movement keybinds. The most logical are w for next week and b/W for previous week (?), m and M for next month and previous month. I think that's a logical starting point.

[vhyrro]

Okay I devised some movement keys which I think are fairly sensible:

• L - move exactly one month forward
• H - move exactly one month backward
• m - move one month forward, but to the first day of that month
• M - move one month backward, but to the first day of that month
• y - move a year forward
• Y - move a year backward

Let me know what you think! (cc @andreadev-it)

Edit: Also added $ to move to the end of the current month, and 0/_ to move to the beginning of the current month! Contemplating whether or not 0 should move to the beginning of the month and _ to the beginning of the current week to reflect what happens in Neovim keybinds. Maybe ( and ) should move between weeks (in neovim this is sentence forward/sentence backward)?

[vhyrro]

All that's left now is the i keybind and also refactoring the codebase to allow for many simultaneous calendars to be open at once!

[vhyrro]

Things are looking good! Only the i keybind left.

[andreadev-it]

Awesome! For the keybindings, it looks good to me, I'll test them as soon as I can. For the i keybinds, I've already wrote some code for that, but it needs improvement (I'm trying to do as you said about allowing partial names for month/weekdays) I was also trying to have performant code in order to do some kind of "live preview" of the date while you type, but it is still just an idea

[vhyrro]

Oh a live preview would be awesome. I would wait for anticonceal to be merged (which seems like it'll happen very soon!) and then we could add hints as the user types in line (which would be kinda insane). I've also started working on the i keybind, so woops both of us ended up starting the same thing lol. What I'm doing however is implemented in a separate core.tempus module which means parsing of dates can be generalized anywhere. I'll push my changes asap, and maybe we can compare the code we wrote and see if there's anything to mix and match? Mine just uses lua patterns and a single vim regex pattern for the more complex 19:00.24 case which lua patterns can't seem to recognize, but it's still very performant imo

[vhyrro]

Oh my goodness. I just found out vim exposes an lpeg library by default :exploding_head:

I'll likely now use that instead of the vim regex which is not on the fast side.

[vhyrro]

There! No implementation of i itself yet, but the backbones to parse any date are there. It's not the most compact code in the world, but we can iterate on it as we need to acommodate for live preview etc.. I'd at one point love to refactor the whole thing into a single peg grammar with captures for maximum flexibility, but that's for later down the road :p

[vhyrro]

We're done! Now some extra bug squashes are necessary. Select date range fails, and moving across months with different sizes still sometimes gives wrong results. Additionally core.tempus ought to add support for date ranges (Tue 5th May - Fri 8th May), but that's for a separate PR :)

[vhyrro]

Okay, select date range is now working again! I'm happy to merge this as is, and we can work on the calendar as we go further along!

[vhyrro]

Okay - only bug left is the weird month-boundary movement, if you disregard that then it's just the date ranges that have to be implemented :)

Here goes the merge! @andreadev-it thank you so much for all the help with this! From now on we'll be making changes to the main branch, so if you have any code that is still of use be sure to make PRs with potential improvements :D