nvim-telekasten / telekasten.nvim

A Neovim (lua) plugin for working with a markdown zettelkasten / wiki and mixing it with a journal, based on telescope.nvim
MIT License
1.37k stars 86 forks source link

[FR] Add "nextworkday" and "prevworkday" to daily templates. #334

Open davvil opened 3 months ago

davvil commented 3 months ago

Please confirm

Is your feature request related to a problem? Please describe. When using daily notes in a work-related environment, weekends are usually empty, thus linking to the next day on a Friday or previous day on a Monday are mostly useless.

Describe the solution you'd like Expand the template for daily notes to include options to link to the next and previous work days.

Additional context I have a barebones implementation which works good enough for my purposes. I expect for a more complete implementation there should be a way to define workdays (with Mon-Fri being the default?) and of course documentation for the feature. Happy to help on a full-fledged PR if there's interest in the feature.

lambtho12 commented 3 months ago

I can see this feature being useful indeed.

There is currently a bit refactoring effort being carried out by @TheTaoOfSu. To avoid complicating stuff unnecessarily for this complex endeavor, I plan to only merge (urgent) bugfixes into main at the moment. Any enhancement will have to wait after refactoring.

So you could either develop against the refact branch now and we will merge later once refact is merged with main, or you just wait for the refactor to be done and start working on the full-fledged PR then.

Thank you very much for this idea and proposing to contribute yourself.

TheTaoOfSu commented 3 months ago

Agreed on this being a useful feature and one worth implementing.

As far as the refactor goes, it's going to be slow going for a moment, and I'm planning to put it aside for a moment so I can add a feature I personally need, markdown links. If the implementation @davvil is a good indication of the size of the change, it would be pretty easy to merge into refact if added to main.

The only real complication to an implementation getting merged into refact is the configuration option. It'll need some option the user can set to toggle the feature. The obvious choice is something like a boolean dailies_skip_weekends, but I think it might actually be a little better to allow the user to specify the days to be skipped, so maybe something like a table dailies_skipped_days or dailies_days_off, where setting it to skip Sunday and Saturday means setting it to dailies_skipped_days = {1, 7}. Then, the actual implementation can check if the given day falls on a weekday included in dailies_skipped_days and iterate accordingly until they hit a date that isn't in the table. This way, users who work routine schedules but don't necessarily work a standard Monday-Friday can use the feature for minimal extra effort.

TheTaoOfSu commented 3 months ago

Actually, having thought about it a bit more, it may be worth performing a check for the existence of a note before just assuming. Nothing about this prevents you from creating a daily note on a day you'd normally have off. As written, however, it would assume there's no way you ever created one on the weekends and never properly identify dailies written on those days. Perhaps you had to do overtime one Saturday or Sunday, so you ended up creating a daily note that day, but it won't link properly from the previous Friday or the following Monday now.

davvil commented 3 months ago

As I don't think this is urgent and I have a working solution, I would prefer waiting until the refactoring is finished to create the PR. I may be convinced otherwise if there is interest, though.

As for the points you raised, @TheTaoOfSu:

TheTaoOfSu commented 3 months ago

Ah, I misunderstood how you were going about it. Templates are pretty simple and straightforward, and the user can always just select a different template, so it does have some perks. However, and I haven't used the dailies feature much so I may be mistaken, this does leave them vulnerable to user error. You use the weekdays template, so it skips over the weekend for you in your template links, but then you come in on Saturday or Sunday and forget to go back and switch the links. Now, your Friday and Monday notes will link each other and skip over this extra day.

I suppose both are valid workflows, but I personally prefer to do what I can to prevent user mistakes. However, the more I think about it, the more complicated that seems. Any attempt to preemptively link the next workday's note must necessarily assume something about how regularly days off are taken. Any deviations from assumption will require manual intervention. It's either that or add something to check for the user and propose and/or make corrections, which carries its own truck full of complications, not limited to how you know exactly which links are supposed to link to the very next/previous workday.

You may be right to approach this as a pair of template keywords. nextworkday can only realistically be determined based on our assumptions as defined in the user's config. prevworkday, however, I think I would implement as a check. If yesterday was a day off, check if a note exists anyway, and keep going until you either find a note on a day off or hit a day where a daily note should reasonably be expected. Alternatively, ignore days off entirely for prevworkday and just keep checking until you find a daily and insert that date. This would also help gloss over unexpected absences like sick days where a note may not get created. It may not be worth the effort, though, since links are often set through a picker. You'd need an extra function to just find the appropriate note unguided, which requires making extra sure you're properly identifying your target.

davvil commented 3 months ago

If we want to be really "smart" about this, perhaps it is worth dropping the links altogether and instead provide two functions "goto_nextday()" and "goto_prevday()"? In that way we can dynamically check what days were skipped, for whatever reason.

TheTaoOfSu commented 3 months ago

I had considered that but wasn't sure if it was worth the effort, especially if you wanted to add it soon. A simple template keyword addition and the date calculations would be pretty easy to merge into the refactoring branch, but once we start adding more complicated functionality, it may actually be worth waiting at least until I can get markdown links added. I want to do that to the refact branch since it's going to involve refactoring how links are handled, so it'll be a good opportunity to bring some of refactor changes into main and provide a better basis for any features anyone else wants to add in the near future.

If I'm not mistaken, pretty much any code that adds a link does so through a picker, so I think you're right, I think if we want to go this route, we'll want to avoid links and add functions to move forward and backwards through daily notes. Perhaps we could generalize it a bit to just next/prev so it also works on weekly notes. My first thought is that the best way to do this would be to open a picker that preemptively tries to find the right note by generating a default search term based on how dates are formatted in the titles of daily notes. If you want to simply go to it, you can just go, and if you want to add a link, you can add a link. It wouldn't be quite as fluid for flipping through tons of notes, but it should still be pretty quick and easy if the default search is defined well, and it'd give us link insertion as a handy bonus. If that's how we do it, I think it'd be best to do it after a little more refactoring because I want to address pickers. There's some duplicated code and effort there that I think can be streamlined, and that'd impact how this is written.

davvil commented 3 months ago

Just a clarification: Using the templates the links are not inserted via pickers. E.g. if the template contains {{nextday}}, it will compute that tomorrow is 2024-06-20 and will insert that in its place (https://github.com/nvim-telekasten/telekasten.nvim?tab=readme-ov-file#templates).

It sounds that there are several moving pieces, so I think it's probably best to wait until the refactoring stabilizes.