v0.20.7

See CHANGELOG.md for full history.

• Improved — making a to-do repeat now reads the Repeat dialog instead of retyping what it already says. The dialog fills itself in from the to-do it was opened on: give it a to-do scheduled for a Thursday and ask for a weekly repeat, and it comes up already saying "every 1 week, on Thursday, next occurrence that Thursday". The command used to click every one of those controls anyway. It now checks them — one look at the dialog, comparing each control against what you asked for — and only touches the ones that disagree.

  Nothing is taken on trust. A control that does not already say the right thing is set exactly as it was before, and the dialog is still audited control by control before anything is committed, whether the value was typed or found. The commands land the same series either way: every shape was run twice, once reading and once typing, and the stored rules came out byte for byte identical.

  What that removes is real work. The most expensive step in the whole command was confirming that the interval box said "1" — nearly a second of it, on a Mac, to type nothing at all — and it is gone. So are the weekday, the day-of-month, the month, and the first-occurrence date, whenever the to-do's own schedule already implies them. Depending on the repeat you ask for, that is between one eighth and nearly half of everything the command says to Things, and up to half again of the parts of the dialog it has to load.

• Improved — a repeat with a deadline now starts from the right place instead of being steered there. Things anchors a series with a deadline on the due date and works the start date backwards from it. The command used to create the to-do on its start date and then walk the dialog over to the due date. It now creates it on the due date to begin with, so the dialog's own suggestion is already correct — the series still starts exactly when you asked, because the app does the subtraction.

• Fixed — an impossible "start N days earlier" on an after-completion repeat is now refused instead of being quietly changed. A series that repeats a week after each completion cannot have occurrences that start more than six days before they are due — the start would land on or before the previous one's deadline. Things enforces that, but it enforces it by replacing your number without saying so: asking for 30 days on a weekly after-completion repeat committed 6, and on a three-day one committed 0. --start-days-earlier above the limit is now refused up front, naming the limit and the two ways around it (a longer interval, or a fixed schedule, which has no limit).

• Added — THINGS_API_TRACE=1 now records which dialog controls were already correct. Each GUI repeat command's trace names the controls it checked, which of them already held the requested value, and which setter it therefore skipped — so a slow run can be read as "the dialog needed all of this driven" rather than leaving it a guess. THINGS_API_PREFILL=0 turns the whole thing off and runs the previous behaviour, unchanged.

• Improved — making a to-do repeat no longer waits on a clock. It waits for Things to say it is ready. Every step of the Repeat dialog used to guess: click a pop-up and re-ask "is your menu open yet?" every fiftieth of a second; ask a field for keyboard focus and then sleep a fixed 0.15 s in the hope it took; change the frequency and then re-read the whole section until two readings agreed. Things has been announcing all of it the whole time — macOS has an accessibility notification for "this menu opened", "this field took focus", "this control now holds the value you set" — and the app is completely silent when nothing is happening, so every announcement belongs to the thing the command just did. The command now listens, and each step ends the moment the app says it is done rather than when a timer runs out.

  The practical difference on a Mac: entering an interval took 1.21 s and now takes 0.56 s, and no step's timing depends any more on how fast the rest of the command happens to be — which is the failure this fixes at the root. A wait sized by "however long two readings take" breaks the moment the readings get faster, and that had already happened once.

  This needs the Command Line Tools, which most Macs with developer tools installed already have. Without them — or with THINGS_API_AX_OBSERVER=0 set — every command runs exactly the code that shipped before, unchanged, so nothing is lost by not having them.

• Fixed — three seconds of pure waiting removed from making a to-do repeat, reported from the field. Watching the command run on an M1 showed two pauses that were doing nothing useful, and both are gone.

  The first was a ~1.5 s stall before the dialog's "Next:" field was touched. The command was waiting for Things to recompute which dates the rule produces — a real thing to wait for — but it started waiting after the recompute had already finished, so it spent its whole budget re-reading a control thirteen times to discover nothing had changed. It now knows immediately, because it was already listening; and when the step before it changed nothing at all, it does not wait at all.

  The second was the command opening the "Next:" menu, walking its list of dates, and clicking the one the field was already showing. Since making an item repeat starts the series on the item's own scheduled date, that is the normal case rather than a corner. It now reads the field once and skips the whole thing when it already says the right date — including when the field reads "Today". Nothing about the checking changes: the dialog is still audited control by control before anything is committed, and the resulting series is still verified against the database afterwards.

  Working out which version of the Repeat dialog is open got cheaper too — the same question, asked in three questions instead of fifteen.

• Added — THINGS_API_TRACE=1 now records what each step of a GUI command WAITED for. Beside how long a step took and how many controls it read, a step's trace record now names the notification it waited for and how long the app took to send it. That is the part of the time a command cannot make smaller, so a slow run can now be read as "the app took this long" or "we asked too many questions", rather than leaving both possible.