-
Notifications
You must be signed in to change notification settings - Fork 0
Feature Tags
English · Tiếng Việt · 中文
A tag is a single short label on a message. Since 1.4.1 a rule could set
one as mail arrived. Since 1.16.0 you can also do it yourself: press T
while reading a message, or select several and tag them all at once. Click a
tag chip anywhere and the list filters to it, or type tag: in the search box.
Bundles sort mail by what it is — newsletter, receipt, notification — and SkimMail decides that for you. A tag is the other half: a label you define, either by hand on the message you are looking at or by a condition a rule evaluates for you, so "anything from the landlord" or "invoices over the quarter" becomes one click in the toolbar instead of a search you retype.
Since 1.16.0. Three ways to reach the picker, all operator level:
- Press T while reading a message, or with one or more messages selected.
- Open the command palette (⌘K) and choose Tag as…, or pick an existing tag directly — every tag currently in use is listed there by name.
- Select several messages in the list and tag them all from the multi-select bar, in one operation.
The picker offers your existing tags first, one click each, and a text box below for a new one. With a tag already on the message or selection, an extra Remove tag entry clears it. The reading pane shows the current tag as a pill next to the subject, with an × to take it off without opening the picker at all.
Manual tagging always overwrites. If the message already carries a tag — whichever put it there — picking a new one replaces it. That is the opposite default from the rule backfill described below, and deliberately so: a rule is a standing instruction, but a person tagging the message in front of them has just said what they want it to be.
A rule can still set a tag on mail as it arrives — see Rules and signals for conditions and the other three actions a rule can take. Three behaviours to know, because they surprise people:
- A rule only tags newly arrived mail as it runs. Evaluation happens once, when a message is inserted during a sync, and never again for that message.
- Only mail less than 48 hours old is evaluated at all. A first sync that backfills months of history does not run rules over it — otherwise writing one rule would fire hundreds of notifications about mail from last spring.
- One tag per message, first matching rule wins. If two rules would both tag a message, the first matching rule in list order sets it and the others do not overwrite it. The column holds one value; tags do not stack.
Since 1.16.0, a rule with a tag action has a Backfill button on its own row in Settings ▸ Rules — it counts what the rule would tag in the mail you already have, and lets you apply it on demand, without waiting for that mail to arrive again. It never overwrites a tag already set. See Rules and signals for exactly what it counts and refuses.
Since 1.16.0, Settings ▸ Rules ▸ Tags lists every tag currently in use with its message count. A tag is not a row anywhere in the database — it exists only as text on the messages that carry it — so this panel is the closest thing to a tag registry, and it is derived, not stored: a tag with no messages simply does not appear.
One operation covers three outcomes, and the panel names all three rather than pretending they are different features:
- Rename it to something not already in the list.
- Rename it onto a tag that already exists, and the panel says so before you confirm — that merges the two: every message carrying either now carries the target name.
- Remove everywhere takes the tag off every message that has it. The mail itself is never touched, only the column.
Clearing a tag — by removing it here, by the × in the reading pane, or by
picking "Remove tag" from the picker — stores NULL, not an empty string, so
every place that checks "does this message have a tag" agrees on the answer.
This is operator level, the same as tagging itself. There was no way to take a tag off anything before 1.16.0: a rule with a typo in it ("finanace") branded every message it matched, permanently, and deleting the rule left the label behind. The eraser is what makes tagging — by a rule or by hand — safe to use freely.
Click a tag chip on any message row, or type tag: into the search box —
tag:finance, or tag:finance invoice to search within a tag, or
tag:"to read" if the tag has a space. See
Search for exactly how the operator is parsed. Either way the
toolbar shows the tag as a chip in the same colour, and the list narrows to
messages carrying it; click the ✕ on the toolbar chip to clear the filter.
Since 1.16.0 the chip stays visible while you search, so a filter can no
longer narrow your results without you seeing why.
If the filter matches nothing, you get an empty state that says so — "Nothing tagged X" — and offers to clear the filter, rather than the generic Inbox-zero screen a filter used to fall back to before 1.12.0.
Filtering is also fast on a large mailbox: the 0015_tag_index migration
(1.12.0) added an index in all three database engines, so a filter is not a
full scan of your biggest table.
A tag chip takes its colour from the tag's position in the sorted list of tags currently loaded, cycling through five accents. The same tag therefore keeps the same colour while you are looking at it, and the toolbar chip always matches the row chip it came from.
Two consequences of deriving the colour from position rather than from the name:
- With more than five distinct tags on screen, two of them share a colour.
- A tag's colour can change between views, because the set of tags loaded is different. The colour is a scanning aid, not an identity.
| Tags per message | 1 |
| Tag name length | 40 characters, counted in characters not bytes |
| Applied by | a rule on arrival, or by hand at any time |
| Role required to tag, rename or remove | operator |
| Rule evaluation window | mail newer than 48 hours |
| Chip colours | 5, by position |
| Available since | 1.4.1 (manual tagging, the eraser and rule backfill: 1.16.0) |
- Manual tagging has no time window. Unlike a rule, tagging a message by hand works on mail of any age — there is nothing to backfill because nothing was missed.
- Manual tagging always overwrites; a rule's backfill never does. Same column, opposite defaults, and the difference is who is asking — see "Tagging a message by hand" above.
- It does not stack. A message has one tag or none.
- It does not reach your mail server. A tag is SkimMail's own column. It is never written to IMAP, and no other client will see it. For the reverse direction — tags set in another client, shown here read-only — see Server keywords.
- It is not masked by screenshot-safe mode. A tag is a word you wrote, so it is left as it is; check your tags before you capture. See Screenshot-safe mode.
- Removing a tag does not tell you where it was applied from. The panel reports a message count, not a list of which rule (or hand) put it there.
- Rules and signals — the conditions that set a tag automatically, and the Backfill button that catches up existing mail
-
Search — the
tag:search operator - Server keywords — the other kind of chip, read-only and set elsewhere
- Screenshot-safe mode — what it does and does not substitute
- Operations — backups, in case a tag ends up somewhere you would rather it had not
SkimMail · skimmail@base101.app · 2026-09-15 · commit 767741a