simon-git: puzzles (main): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  c0bd524 Fix failure to update me->ui when changing preferences.
  2d91261 Net: preference for how loop highlighting interacts with locking.

Repository:     https://git.tartarus.org/simon/puzzles.git
On the web:     https://git.tartarus.org/?p=simon/puzzles.git
Branch updated: main
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2023-04-23 14:08:13

commit c0bd524848f98e5c4a495c4bc31dd55087a28aaa
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=c0bd524848f98e5c4a495c4bc31dd55087a28aaa;hp=e2add4185cf1e3639b7a320384098d63dc2f3d67
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Apr 23 14:00:40 2023 +0100

    Fix failure to update me->ui when changing preferences.
    
    This must have been introduced during a last-minute rebase, or similar
    - I'm sure it worked a couple of days ago! Because midend_set_config
    passed a NULL game_ui to midend_set_prefs, the latter would make up a
    temporary UI and apply the changes to that. As a result, the midend's
    main UI would keep the original backend preferences, and those would
    also be the ones saved to the config file.

 midend.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

commit 2d91261eb3a37b919f48450888f8f5bfd226c053
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=2d91261eb3a37b919f48450888f8f5bfd226c053;hp=c0bd524848f98e5c4a495c4bc31dd55087a28aaa
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Apr 23 14:02:39 2023 +0100

    Net: preference for how loop highlighting interacts with locking.
    
    Net's loop highlighting detects any loop in the current state of the
    grid. I've occasionally found that to be a bit of a spoiler, since
    sometimes it can point out a deduction I should make before I've
    figured it out for myself - e.g. when I've just locked all but two of
    the squares involved in the loop, and the last two _just happen_ to be
    oriented so as to complete the loop. In that situation I'd prefer if
    the loop _didn't_ immediately light up and point out to me that I need
    to arrange that those squares aren't connected to each other.
    
    The simple answer is to only count edges connecting two _locked_
    squares, for the purposes of loop detection. But this is obviously
    unacceptable to some players - in particular, those who play without
    the locking feature at all. So it should be a user preference.

 net.c | 85 ++++++++++++++++++++++++++++++++++++++++++++++++++++---------------
 1 file changed, 66 insertions(+), 19 deletions(-)