Closed Porrumentzio closed 2 years ago
The problem with this is that it collides with the current behavior because you can have more that one checkpoint
I don't understand the problem. Could you explain further?
I don't explain. The problem is that if you back to checkpoint is expected that these checkpoint will be deleted because you can have a previous checkpoint to back to it. But you can add a new checkpoint after rollback.
But if I understand well that problem would be with more than one checkpoints, but not with the initial proposal:
the checkpoint stays there for all the game, until a new checkpoint is set.
Sometimes, after having solved a sudoku part-way, I want to check why I placed a number somewhere. In these situations it would be useful to set a checkpoint, and then undo until I undid the number and can check my logic.
Either my reasoning was wrong, and I then abandon the checkpoint to try another path, or I remember how I did it and want to return to the checkpoint again.
For this reason it would be nice if the checkpoint was seperate from the undo-history, (possibly with a warning if you want to return to the checkpoint after deviating from its history).
I'm migrating Open Sudoku development from GitHub to GitLab. To make the migration as clean as possible I'm going to close this issue. If you are still interested (or if it is still relevant), please open it again in GitLab from July 26.
Thank you very much for your understanding.
This allows the users to try out possible variants and if error, go back to checkpoint. Doing this, the expected behaviour would be that the checkpoint stays there for all the game, until a new checkpoint is set. (Even then, it would be interesting to be able to set more than one checkpoint, though not very useful)