I'm not convinced this is safe to apply as it is. What happens exactly after a timeout? Does the sketch just get stuck in an inconsistent state? I think a timeout should cause an undo, not leave the sketch broken.

It stays broken with red background. Just a CTRL-Z away from being fixed. It was not as easy to brake as I thought since redundant constraints are dropped now. H didn't work. Distance didn't work. I finally got it fail by applying Y. This area of the code is not my thing, I'm not that comfortable poking in there yet. Just applied those changes to master. Why would we not want to keep the existing behaviour of turning the screen red?

The timeout was to prevent it from locking up figuring out which constraints could be removed to fix it. Automatic undo would 1) not be informative and 2) feel like nothing happened with no explanation.

Need to make auto ctrl+z in SolveSpace everywhere. Red background shouldn't exist at all.

Wondering if it would be better not to pass isTimeout all the way down. Ultimately the flag is set in FindWhichToRemoveToFixJacobian() which already has a pointer to the group. The flag should be in g->solved.timeout. The pointer passed in (or NULL) is being used as a flag to determine if the flag should be written. I'd rather just write the true/false to g->solved.timeout every time and not change a bunch of function signatures. It just seems more complicated than need be.

EDIT: Yes, the new patch is much less invasive.

@whitequark I've added the configuration value and fed it down to the solver, but if you could complete the text window I'd really appreciate that. It may also want to be a float (seconds) in the UI.

Added the adjustable timeout to the configuration screen at the bottom. It works as intended - increasing the timeout value allowed it to find a constraint to remove that previously was not identified, while still stopping short of finding them all after the timeout period.

Thanks, good work!