Feature Request: exclusions, back-tracking, and appearance

geoffreysflaminglasersword commented 2 years ago

Feature Requested

First, just want to say I really appreciate this plugin! I think it would be even better if you could: 1: select plugins to exclude in the settings menu (e.g. I'm confident that plugins like Git and Sliding Panes will pretty much never be a problem so I don't ever want to disable them) 2: use the same functionality available for plugins on CSS snippets in the appearance tab 3: back-track... meaning several things:

I just found the problem plugin, I'd like to re-enable all of the plugins that were active when I started (users often have disabled plugins installed, it's a chore to figure out which one's weren't enabled)
I'm several levels deep and the problem just went away. That means the problem is in the complement of the current set from the last set. I definitely wasn't keeping track of all the plugins that were just disabled so I need to enable just the ones that were just disabled

There's a few ways do do that, and I think a few commands could replace existing ones*

save and recall commands.
1. a simple implementation would be to just save the current state and recall that exact state, that could work ok with existing commands, but you run into the issue of either not being able to back-track, or back-tracking overwriting your original list of plugins
2. Potentially you could instead have a stack of sets, with bisect/un-bisect commands
The second method above is better in my opinion, as that would make it simple to have a "re-bisect" command which does n un-bisect followed by the inverse bisection

with those three commands, a user can: bisect, bisect (problem goes away), re-bisect (or inverse bisect, idk what it should be called), bisect, bisect (found problem), un-bisect, un-bisect, un-bisect, un-bisect

Things to note:

un-bisecting the top level could either turn on all plugins (retaining history so re-bisecting goes back to the original list) or do nothing
manually enabling/disabling plugins could either reset the history, or just add/remove that one plugin from the previous bisections

* Currently you can "disable half of enabled plugins", "enable half of disabled plugins", and "toggle all plugins" but those don't work well if I'm levels deep. I could have plugins [1,2,3,4,5,6], with [0,7,8] already disabled and 5 being the problem plugin. Disable half -> [1,2,3], problem goes away, toggle -> [0,4,5,6,7,8], disable -> [0,4,5], disable -> [0,4], problem goes away, toggle -> [1,2,3,5,6,7,8]... and that problem will repeat itself even if you use enable half instead of toggle. This is hard enough to keep track of on a small example and much harder with 50+ plugins.

Bisect, un-bisect, re-bisect replace those three commands, and also get rid of the need for "enable all plugins" as un-bisecting the top level would do the same thing. Personally I also don't think there's a need for "disable all plugins" considering you can just turn on safe mode, and I don't really understand the point of the "count" command.

Relevant Screenshot

No response

Checklist

[X] The feature would be useful to more users than just me.

chrisgrieser commented 2 years ago

All of your suggestion make a lot of sense to me. However, they are all pretty time intensive to implement for me, since I am still very new to writing plugins, while at the same time, the plugin isn't high priority to me compared with all the other stuff I maintain (+ a PhD thesis somewhere in between all that 😅).

So I would very much welcome PRs for any of the suggestions, since I do not know when I'll have the time to dive into this.

claremacrae commented 2 years ago

Big thumbs up for the back-tracking request and "help wanted" label!

I'm less sure about the "good first issue" label though! :-)

claremacrae commented 2 years ago

This would also be a great candidate for writing tests on plugin code... It'll be potentially hard to get the logic right, and once it is right, it will be good to pin down the behaviour, to make sure it isn't broken by later changes...

I don't mind helping with that side of things...

geoffreysflaminglasersword commented 2 years ago

This would also be a great candidate for writing tests on plugin code... It'll be potentially hard to get the logic right, and once it is right, it will be good to pin down the behaviour, to make sure it isn't broken by later changes...

I don't mind helping with that side of things...

I'm just about done with 2 of the 3 features, will put in a PR soon

chrisgrieser commented 2 years ago

Ironically, javalent did exactly the one request you didn't implement 😊

Since now all requests of this issue are addressed, I am closing this. However, as a consequence of the feature requests being worked on at the same time, there is now the issue of making the bisections consistent #5.

chrisgrieser commented 2 years ago

@claremacrae sure, when I have familiarized myself with the rewritten code base, we can look into implementing testing

claremacrae commented 2 years ago

@claremacrae sure, when I have familiarized myself with the rewritten code base, we can look into implementing testing

That's fine - or if you like, we could use the writing to tests to familiarise you with the rewritten code base... The skill of writing tests pays back in understanding unknown code super quickly...

No pressure - just wanted to let you know about the other - opposite-way-round - option - totally up to you...

geoffreysflaminglasersword commented 1 year ago

This would also be a great candidate for writing tests on plugin code... It'll be potentially hard to get the logic right, and once it is right, it will be good to pin down the behaviour, to make sure it isn't broken by later changes...

I don't mind helping with that side of things...

Hey btw, now that the 1.0 is out, if you'd like to write some tests that'd be helpful

claremacrae commented 1 year ago

Hi @geoffreysflaminglasersword,

Hey btw, now that the 1.0 is out, if you'd like to write some tests that'd be helpful

Sure, I'm happy to pair with you to set up and write some tests together.

I'm available from Monday 28th November onwards. My email address is in my GitHub profile, if you would like to talk to set it up, to find a first mutually agreeable slot.

chrisgrieser / obsidian-divide-and-conquer