Rollover content blocks of todos

[LarsKumbier]

I usually have some additional information on open todos in content blocks below a todo, which are left dangling in the old file now, e.g.

- [ ] call support for the state of the networking issue <-- should be rolled over
    - ticket number is 1785 <-- should be rolled over, because it's additional information
    - staffer was named Max Pain <-- should be rolled over, because it's additional information
        - [ ] try to get his phone extension for direct calls? <-- should be rolled over, because it's additional information
- some unrelated information that should NOT be rolled over, because it's on the same level as the todo

[rbutera]

This seems like it should be simple to implement.

[lumoe]

Hi @LarsKumbier, sorry for the long delay. This project was transferred to my account and is now maintained again.

This indeed looks like a very useful feature, thank you for submitting a PR! I will have a look at your PR and verify if it still works in current Obsidian versions. Are you interested in further contributing to this feature or bug fixing?

[LarsKumbier]

Hey @lumoe, thanks for taking over! I'd be happy to contribute in the future as well. Lemme double-check if the PR is still up-to-date with my private repos.

[lumoe]

Detailed description of the current behaviour and expected behaviour was provided in another FR: https://github.com/lumoe/obsidian-rollover-daily-todos/issues/70#issue-1469194060

Closed the thread in favour of this one.

[talios]

This would be a killer feature to add - often if I have more detail to add I extract that to it's own mini-page and then transclude that:

 - [ ] ![[Port build helper to error-stack]]

Which gives me the best of both worlds - but for a few small sentences rolling over the content would be awesome.

[LarsKumbier]

@talios I'll have a look at my PR tomorrow.

[LarsKumbier]

I've just had a look at @tim-hilt's PR and it's a lot better structured than mine - I think the current state of the project in general is very hacky and unstructered and I tried not to change anything big. @lumoe can we get one of either PRs (preferably tims, if there are no other reasons speaking against that) merged soonish?

[lumoe]

I agree that Tim has added some very nice improvements which should increase the general stability of the project.

I have successfully merged the PR from Tim. In addition to the automated tests, I also tested them out manually in different environments. Can I invite you @LarsKumbier & @talios to test the main branch out on your environment as well and provide us some feedback before we release the new version?

[tim-hilt]

@talios @LarsKumbier @lumoe please let me know if there are any problems. I can supply a patch. I think I discovered some shortcomings with the original implementation. I can‘t open a new PR directly because my fork diverged pretty significantly from this repo.

[talios]

@tim-hilt which fork should we be using? I cloned this repo and built it (after installing pnpm) and replacing the the JS in my fault ( seems nothing gets rolled over now tho, but no errors in the Obsidian dev console ).

[tim-hilt]

@talios use this repository. My fork lives here, however the settings panel for example look like this:

notice the difference at the top! This is useful for me, but might not be useful for the general public. That's why I'd advise to clone > build > activate the master-branch from this repository to support @lumoe .

[talios]

@tim-hilt Ooo those multiple headings to roll looks super awesome. Will take another look in the morning.

For reference:

$ git clone....
$ pnpm install
$ pnpm build
$ cp main.js ~/Documents/Obsidian/.obsidian/plugins/obsidian-rollover-daily-todos

(restart obsidian) - Is that right?

[tim-hilt]

In principal that's correct. Alternatively you could also clone obsidian-rollover-daily-todos to ~/Documents/Obsidian/.obsidian/plugins/ and build there directly. Advantage: You don't have to copy any files around.

You also don't have to restart obsidian - just deactivate and then activate Obsidian Rollover TODOs from the settings.

[LarsKumbier]

That already looks a ton better. I strongly prefer to just take @tim-hilt version as the new basis and go through the list of PRs and issues to see, which one can be closed and which ones need adaptions for the new basis.

[tim-hilt]

I'm honored, thanks! However I think @lumoe is the one in charge for this decision.

[LarsKumbier]

Absolutely - but the project has been already dead once (despite being a very popular plugin) and a good, maintainable codebase is one of the foundations for a project to work. I'm happy to help, but I'd rather work with your codebase than with the current one. And I dislike forks in OpenSource projects (because they divert devpower), so... just voicing my opinion. :)

[tim-hilt]

Again - thanks for your kind words! I'd say this isn't the right place to discuss any further. Let's wait for @lumoe to open up another issue for that if he decides to pursue this idea further.

[lumoe]

Howdy guys, thank you for your input! @tim-hilt your features look extremely promising, and I am sure that a lot of these features that you already have in your fork are extremely useful for other people.

I agree with you all, that this plugin really needs a re-write of the codebase as it is not maintainable in its current state. Still, to be honest I would love to have a re-write of the modules + unit tests before we continue adding more functionality.

What do you guys think?

[LarsKumbier]

@lumoe I'd agree, if we would not already have a very big step in the right direction by @tim-hilt - I'd much rather start any future enhancements with that (incl. tests) than trying to get the current state into a test harness and refactoring from there.

This approach would of course break any current PRs and we'd have to go through the issue list to see if the problems also exist in tim's version - but the same would be true with a major rewrite from the current base anyway.

That's why I suggest to make a hard cut with tims' version by releasing a new major version and expand from there.

[tim-hilt]

A better approach would be to

1. Make a branch release-2.0
2. Merge my fork to this branch
3. All new tests are added in the new branch
4. If we‘re confident that all missing tests/fixes are implemented we make a beta release
5. After some grace-period we make a major release from the release-branch

What do you think?

[tim-hilt]

Also: I‘d suggest to postpone this decision until @lumoe has taken a good look at my code. After that you can judge whether or not this is a good idea.

I daily-drive my implementation but I still have to add some fixes here and there.

[lumoe]

There is no doubt, that we should go with your implementation. I also agree with the steps you proposed. :+1:

[tim-hilt]

Thanks, that's an honor. Let me open up a branch later today and push my changes.

[talios]

Not sure what I did wrong, or not when trying this branch out - but it's not rolled over any of my tasks at all - no errors - but also no roll overs.

[tim-hilt]

Can you please open a new issue for that and list reproduction steps and the branch-name in the description?