Sort the rule builder's preview by count

Alphabetical order finds a payee you are already looking at, which is what the
list is for once a glob is typed. With the glob empty it answers a different
question -- what to write a rule for next -- and there the name is the least
useful thing about a row: one pattern claiming forty rows is worth more than
the first of forty claiming one, and nothing on screen said which was which
until you read the whole list.

ctrl+s switches between the two. A chord rather than a letter because the
builder is a form and every printable key belongs to the field being typed in;
the invariant that keeps q from quitting there cuts this way too. Ties fall
back to the alphabetical order so the list does not reshuffle when it is
rebuilt, and the cursor returns to the top, since the row under it is not the
row that was there a moment ago.

The header marks the column the order is read from, and the help names what the
key does next rather than where the list already is. The choice is the user's,
so it outlives the builder being left and reopened.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-08-17 20:33:46 +02:00
co-authored by Claude Opus 5
parent 6477147988
commit 656e7e1de4
4 changed files with 137 additions and 13 deletions
+12 -3
View File
@@ -123,8 +123,8 @@ nowhere else, so tagging what you are looking at means writing a rule for it on
Writing rules by hand means guessing what a glob will catch. This screen shows
the answer as you type: the form is on the left, and on the right the
still-untagged descriptions the glob currently matches, marked `▸`, grouped and
sorted alphabetically, under a running "*n* of *m* descriptions match" count.
still-untagged descriptions the glob currently matches, marked `▸`, grouped by
description, under a running "*n* of *m* descriptions match" count.
The list narrows as you type, so what is on screen is what the rule would
claim — nothing else is left there to read past. The count keeps the context
@@ -135,7 +135,7 @@ untagged description in the data — which is the other question this screen
answers, and where you go looking for the next thing to write a rule for.
```
glob Untagged description N
glob Untagged description ↓ N
╭────────────────────────────╮ ▸ LIDL SOFIA 4412 2
│ *LIDL* │ ▸ LIDL VARNA 9911 1
╰────────────────────────────╯
@@ -170,6 +170,15 @@ immediately, so the rows it caught disappear from the list. `esc` goes back.
On a short window the form gives up its spacing and then its hints, so all four
fields stay on screen.
`ctrl+s` switches the list between by name and by count, most seen first — a
chord rather than a letter, because every printable key belongs to the field you
are typing in. The `↓` in the header says which column the order is read from.
The two answer different questions: by name finds the payee you are looking at,
by count finds the rule worth writing next, since one pattern claiming forty
rows is worth more than the first of forty claiming one. Ties keep the
alphabetical order, so the list does not reshuffle under you, and the choice
lasts until you change it.
The account and tag fields complete as you type: the rest of the match is
ghosted in grey after the cursor, and `tab` (or `→` at the end of the line)
takes it. When several candidates share the prefix, the hint under the box says