[BUG] Going back to earlier transition and add a move you have made later in tree

[Bram28]

Description

So LEGUP has an interesting feature that you can go back to an earlier transition you made, and make some further changes to the board as long as it still follows the rule for that transition.... and those additional changes will e propagated through the rest of the proof tree you already have constructed. However, this raises a question/issue: how do you handle this when that additional change is one that you already made in the tree, but at some later transition?

In particular, what if the change you add to an earlier transition is the only thing you do at some later transition, so that effectively nothing happens at that later transition?

Not sure how to exactly handle this, but right now, LEGUP does not handle any of these cases well at all, and starts throwing errors.

Steps to Reproduce

Here is an example ... I am sure the same thing happens for any other rule and any other puzzle.

Let's do a Nurikabe puzzle, and start by adding some blacks using Surround Region:

Now we do a Black Bottleneck:

Now we add some further blacks using Surround Region:

At this point we 'realize' we could have added those blacks during the earlier Surround Rewgion, so we go back to that first transition and add one of the blacks there:

Oops! Note how the second use of Surround Region now turns red. Well, that should not be the case. Indeed if we go back to that second use of Surround Region, we see:

So the Board handles this correctly: one of the two blacks that earlier I added using Surround Region is now an already fixed black because it is part of the first use of Surround Region. But the other one is still a genuinely new (and correct) change for the second Surround Region, and is shown with the green outline. So, the Board handles all of this correctly. But, the transition should be green, not red!

Now let's see what happens if we go back to first Surround Region, and add that second black as well:

Going back to second Surround Region:

Right ... no new transitions are made by this second Surround Region, so everything is fixed. Again, the Board does the right thing .... but the transition should not be red! We are basically dealing here with an 'empty' or 'null' transition ... and logically, a 'null' transition is perfectly logically valid. Still, how do we handle 'null' transitions that might arise by moving changes from a later transition to an earlier transition?

One option is to just not allow this kind of thing ... personally I don't like that option: logically if you can make changes part of an transition, you should be able to do so.

Another option is to warn the user that adding a change to an earlier transition may 'nullify' a later transition remove this transition completely ... and that the user may proceed to do this, but that the resulting 'null' transition will be automatically removed from the tree. Again, not a fan: maybe the user wants, for some educational or other reason, to keep the 'null' transition ... again, 'null' transitions are perfectly logically valid ('perfecly/trivially' valid in fact) ... and one can always add some new changes to the board to a 'null' transition later.

So my general feeling is that we allow for 'null' transitions as part of a proof tree. Indeed, if a user desires to do so for whatever reason, they should be able to not make any changes to a board, and still 'justify' that using a rule, thus creating a 'null' transition.

Also, if you don't like to have 'null' transitions as part of a proof, we can always have something like a 'Clean proof' feature/button that will remove 'null' transitions ... (or, when a user is about to create a 'null' transition as a result of moving changes from that transitions to an earlier transition, the program could warn the user, and ask if the user wants to remove that null transition.

And hey, a related idea is that an intelligent version of a 'clean Proof' feature is that it would look for possible ways to see if later applications of a certain rule could have been done during an earlier application of that same rule. But this is all for later.

Right now, I want the transitions to remain green in any of the above scenarios ... and for now, let's accept that if we do something like this, we are also ok with ending up with an empty/null transition in the tree ... which trivially should be green!

Expected Behavior

Already explained above

Screenshots

No response

Puzzle Files

No response

Additional Context

No response

[charlestian23]

Closing this since it was resolved in #682