Drop the keyboard shortcuts; add a Re-read all button
The page carried the TUI's keymap -- screens on 1-8, / u a i r, the report's arrows and s, the rule builder's ctrl+s and esc. Every one of them already had a link, button or click, so they are gone, along with the key numbers in the nav and the key hints in placeholders and tooltips. The upload box still answers Enter and Space, which is what makes it a button rather than a shortcut. The forced import was reachable only by shift-clicking Import. It is now a Re-read all button: every statement parsed again, including the ones an import skips as unchanged -- what to run after a parser fix. Both buttons disable while either runs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
@@ -123,9 +123,8 @@ LIDL SOFIA 4412
|
||||
|
||||
The account is not part of what makes a row distinct. A rule matches on the
|
||||
description and only optionally narrows to an account, so one payee seen on two
|
||||
accounts is still one pattern to write — and it is one row in the rule builder
|
||||
on `4`, which groups the same way. Pass `--account` to scope the listing
|
||||
instead.
|
||||
accounts is still one pattern to write — and it is one row in the rule builder,
|
||||
which groups the same way. Pass `--account` to scope the listing instead.
|
||||
|
||||
It composes with the other filters (`--account`, `--month`, `--search`), and
|
||||
`--limit` caps the rows printed, saying how many it held back. It cannot be
|
||||
@@ -164,11 +163,14 @@ fresh command would:
|
||||
rule there (another tab, a hand edit) the change is refused and you are asked
|
||||
to reload, rather than editing whichever rule moved into its place.
|
||||
|
||||
Shift-click **Import** for `import --force`.
|
||||
**Re-read all** is `import --force`: every statement is parsed again, including
|
||||
the ones an Import skips because they have not changed. Use it after updating
|
||||
money, when a parser has learned to read something it used to get wrong; rows
|
||||
already in the index are recognised and not duplicated.
|
||||
|
||||
### Statements
|
||||
|
||||
The Accounts screen (`1`) also lists every statement file in every account
|
||||
The Accounts screen also lists every statement file in every account
|
||||
folder, with what the index made of it:
|
||||
|
||||
| Status | Meaning |
|
||||
@@ -200,7 +202,7 @@ button says **Forget** and only clears the index.
|
||||
|
||||
### Adding statements from the browser
|
||||
|
||||
The Accounts screen (`1`) has an **Add statements** panel: pick the account,
|
||||
The Accounts screen has an **Add statements** panel: pick the account,
|
||||
drop files on it (or click to choose them) and press **Upload**. The files are
|
||||
saved into that account's folder, exactly where you would have copied them by
|
||||
hand — the folder stays the source of truth, so deleting `index.db` and
|
||||
@@ -228,28 +230,18 @@ same name (a reissue) is numbered `_2`, `_3` rather than refused. A statement
|
||||
with no date it can find keeps its own name. Only uploads are named — files
|
||||
already in a folder are never renamed, since the index records them by path.
|
||||
|
||||
### Keys
|
||||
### Navigating
|
||||
|
||||
| Key | Action |
|
||||
| --- | --- |
|
||||
| `1` – `8` | accounts · transactions · report · rule builder · rules · transfer builder · transfers · tags |
|
||||
| `/` | filter by description |
|
||||
| `u` | show only untagged transactions (matched transfer legs are not among them) |
|
||||
| `a` | clear the account filter |
|
||||
| `←` `→` | move the report's period (report) |
|
||||
| `s` | change how the report is sorted (report) |
|
||||
| `ctrl+s` | sort the rule builder's preview by name / by count |
|
||||
| `i` | import · `r` retag |
|
||||
|
||||
Inside a form every printable key belongs to the field you are typing in, so
|
||||
the single-letter keys only work outside one; that is why the builder's sort is
|
||||
a chord. Clicking an account on `1` filters the transaction list to it.
|
||||
Every screen is a link in the bar along the top, and every action is a button or
|
||||
a click; there are no keyboard shortcuts. Clicking an account on the Accounts
|
||||
screen filters the transaction list to it.
|
||||
|
||||
There is no control that tags a transaction. Tags come from `rules.toml` and
|
||||
nowhere else, so tagging what you are looking at means writing a rule for it on
|
||||
`4` — which is why that screen shows you what a glob catches before you save.
|
||||
nowhere else, so tagging what you are looking at means writing a rule for it in
|
||||
the rule builder — which is why it shows you what a glob catches before you
|
||||
save.
|
||||
|
||||
### Report (`3`)
|
||||
### Report
|
||||
|
||||
The report opens on **last month**, not on everything you have ever imported:
|
||||
an all-time total is the one number a spending report is least often asked for,
|
||||
@@ -259,8 +251,8 @@ period is empty rather than quietly showing you a different one.
|
||||
|
||||
The time axis beside the totals runs from the widest window down to the oldest
|
||||
month in the index — `all time`, `this year`, `last 12 months`, `last 3
|
||||
months`, `this month`, `last month`, then one entry per month. Click one, or
|
||||
step along it with `←` and `→`.
|
||||
months`, `this month`, `last month`, then one entry per month. Click one to
|
||||
report on it.
|
||||
|
||||
The three rolling windows run to the end of *this* month rather than to the
|
||||
last complete one — you ask for "last 3 months" to see what is happening now,
|
||||
@@ -268,12 +260,11 @@ and leaving out the days since the 1st would answer a different question. Each
|
||||
month below `last month` is a month the index actually holds; months that a
|
||||
named window above already covers are not repeated.
|
||||
|
||||
Click a column heading, or press `s` to cycle, to change how the rows are
|
||||
arranged; the marked heading says which one they are arranged by: `Out ▾`
|
||||
largest spend first (the default question a spending report answers), then
|
||||
`In ▾`, `Net ▾` lowest first so the biggest losses lead, `N ▾` most
|
||||
transactions first, and `Tag ▴` A→Z. `money report` takes the same choice as
|
||||
`--sort out|in|net|count|tag`.
|
||||
Click a column heading to change how the rows are arranged; the marked heading
|
||||
says which one they are arranged by: `Out ▾` largest spend first (the default
|
||||
question a spending report answers), then `In ▾`, `Net ▾` lowest first so the
|
||||
biggest losses lead, `N ▾` most transactions first, and `Tag ▴` A→Z. `money
|
||||
report` takes the same choice as `--sort out|in|net|count|tag`.
|
||||
|
||||
Currency is always the outer grouping and no sort changes that — there are no
|
||||
exchange rates here, so two currencies interleaved by amount would invite a
|
||||
@@ -283,12 +274,12 @@ The sort rearranges rows; it never changes which rows there are.
|
||||
|
||||
The period narrows the report and only the report. The account, the search and
|
||||
the untagged toggle are shared with the transaction list, so opening on last
|
||||
month does not hide the rest of the index from `2`.
|
||||
month does not hide the rest of the index from the transaction list.
|
||||
|
||||
`money report` takes `--month` instead; there is no command-line equivalent of
|
||||
the wider windows.
|
||||
|
||||
### Rule builder (`4`)
|
||||
### Rule builder
|
||||
|
||||
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 — glob, account, tag, note —
|
||||
@@ -310,13 +301,13 @@ point to narrow down.
|
||||
immediately, so the rows it caught disappear from the list. The account stays
|
||||
filled in, since the next rule is usually for the same one.
|
||||
|
||||
Clicking the column headings, or `ctrl+s`, switches the list between by name and
|
||||
by count, most seen first; the `↓` 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.
|
||||
Clicking the column headings switches the list between by name and by count,
|
||||
most seen first; the `↓` 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 offer completions as you type. Accounts come from
|
||||
the folders on disk and the index; tags from every tag in use plus any named in
|
||||
@@ -336,7 +327,7 @@ report leaves them out anyway.
|
||||
|
||||
#### Editing a rule
|
||||
|
||||
**Edit** on the rules screen (`5`) opens the rule in this same form with the
|
||||
**Edit** on the rules screen opens the rule in this same form with the
|
||||
fields filled in, and saving rewrites that rule where it sits instead of
|
||||
appending a new one. It keeps its position, since position still breaks ties
|
||||
between equally specific rules; `rules.toml` is edited textually, so the
|
||||
@@ -352,10 +343,10 @@ you are about to hand back to whatever rule catches it next.
|
||||
|
||||
The form has no `type` field, so a rule that sets one carries it through
|
||||
unchanged rather than losing it; it is shown under the glob as `+ type:… ·
|
||||
kept`. Saving lands back on the rules screen with the new counts; **Cancel**,
|
||||
`esc`, or leaving the screen leaves the rule as it was.
|
||||
kept`. Saving lands back on the rules screen with the new counts; **Cancel**, or
|
||||
leaving the screen leaves the rule as it was.
|
||||
|
||||
### Rules (`5`)
|
||||
### Rules
|
||||
|
||||
Every rule in file order — the order they are written in, not the order they
|
||||
are tried in — with the number of transactions it actually claims. Rules that
|
||||
@@ -390,7 +381,7 @@ it, while one separated by a blank line is treated as a section heading and
|
||||
left alone; an edited rule keeps its comments, since they say why it is there
|
||||
and changing its glob rarely changes that.
|
||||
|
||||
### Transfer builder (`6`)
|
||||
### Transfer builder
|
||||
|
||||
Same idea as the rule builder, for money moved between your own accounts. The
|
||||
form names both sides — from account, from desc, to account, to desc — plus an
|
||||
@@ -425,7 +416,7 @@ A half-written definition previews too: fill in one side and its legs show up as
|
||||
unpaired, which is the quickest way to see that a glob is wrong before you have
|
||||
written the other half.
|
||||
|
||||
### Transfers (`7`)
|
||||
### Transfers
|
||||
|
||||
Every definition in file order, with what it currently pairs.
|
||||
|
||||
@@ -471,7 +462,7 @@ once, both after asking. Definitions marked `⚠` are never pruned — they are
|
||||
doing something, just not finishing it, and deleting one would hide the problem
|
||||
rather than fix it. **Refresh pairing** re-reads what is currently in the index.
|
||||
|
||||
### Tags (`8`)
|
||||
### Tags
|
||||
|
||||
Every distinct tag, A→Z: the ones your transactions carry and any `rules.toml`
|
||||
names, with how many transactions carry each and the rules that write it.
|
||||
@@ -547,7 +538,7 @@ tag = "groceries"
|
||||
Every tag comes from this file, so a tag is never something you have to keep
|
||||
safe: `money retag` recomputes all of them from the current rules and is safe
|
||||
to run whenever you change it. A transaction no rule matches simply stays
|
||||
untagged, and shows up under `money ls --untagged`, the `u` view, and
|
||||
untagged, and shows up under `money ls --untagged`, **Untagged only**, and
|
||||
`(untagged)` in the report — unless it is one leg of a matched transfer, which
|
||||
is already spoken for and is left out of all three.
|
||||
|
||||
@@ -649,7 +640,7 @@ that is the number your spending is short by:
|
||||
transfers excluded: 2 legs in EUR, 500.00 out, 495.00 in, 5.00 in fees
|
||||
```
|
||||
|
||||
The report screen (`3`) shows the same thing under its `TOTAL`, the fee on its
|
||||
The report screen shows the same thing under its `TOTAL`, the fee on its
|
||||
own row (for whichever period it is on):
|
||||
|
||||
```
|
||||
@@ -675,7 +666,7 @@ An *unpaired* leg is not a transfer and still counts, tagged like anything
|
||||
else. That is deliberate: money that left an account and cannot be shown to
|
||||
have arrived is exactly what you want to see, not something to quietly drop.
|
||||
`money import` and `money retag` report unpaired legs on stderr, and the
|
||||
transfers screen (`7`) shows which definition they belong to.
|
||||
transfers screen shows which definition they belong to.
|
||||
|
||||
The pairing is derived state, like the tags: it lives in the index, is
|
||||
recomputed wholesale by `money retag` and after every import, and disappears
|
||||
|
||||
Reference in New Issue
Block a user