Daily Text Colors

unlisted

by benhancock

Reveals when later additions were made without changing note Markdown.

Updated 16d agoMIT
View on GitHub

Daily Text Colors

Daily Text Colors highlights additions made after a note’s creation day while keeping the Markdown source unchanged.

It is designed for chronological annotation: existing note text remains the baseline, and later additions become visually dated without adding inline markers to your files.

Behavior

  • Text written on the creation day stays uncolored.
  • Visible prose added on later calendar days receives a date-specific color immediately.
  • A configurable color cycle rotates through a note’s distinct annotation dates.
  • YAML frontmatter, fenced code, inline code, and Markdown punctuation are not colored.
  • Wiki links and external links can keep their native styling or use annotation colors.
  • Completed task strikethroughs can optionally be colored by the date the task was checked.
  • Annotation history is stored in per-note sidecars under .daily-text-colors/notes/.
  • A compact index beside the plugin bundle keeps startup fast; full note snapshots are loaded only when Daily Text Colors needs to reconcile an outside edit.
  • Notes without annotations are not persisted, avoiding full-vault snapshot growth.

Storage

Daily Text Colors never modifies Markdown to add annotation markers. For every note with annotation history, it stores one JSON sidecar containing the last reconciled content snapshot and dated ranges. The sidecars use opaque filenames and keep the note path inside the JSON record, so renames can be tracked safely.

The plugin's data.json contains settings plus a compact annotation index used to color notes without loading every sidecar at startup. If you sync a vault between devices, include the hidden .daily-text-colors folder as well as the normal Obsidian configuration folder.

Daily Text Colors is local-only. It does not make network requests or send note contents to external services.

Privacy and permissions

Daily Text Colors reads and writes only local vault/plugin data needed for annotation history. It does not use the clipboard, dynamic code execution, analytics, or network requests.

Color palette

Daily Text Colors uses the open-source Flexoki palette by Steph Ango. Light and dark themes have separate defaults, and both cycles begin with red.

Commands

  • Show day legend
  • Toggle annotations
  • Reset annotation baseline

Settings

Open Settings → Community plugins → Daily Text Colors to:

  • Choose ordered or stable-random color selection
  • Edit separate light- and dark-mode colors for every cycle position
  • Move colors earlier or later
  • Add as many colors as desired
  • Remove colors while keeping at least one
  • Restore the original Flexoki palettes
  • Loop back to the first color or keep using the final color
  • Show or hide timestamp tooltips
  • Show or hide tooltips for today’s annotations
  • Choose whether annotation colors apply to wiki and external links
  • Choose whether completed-task strikethroughs are colored by completion date

Manual install

  1. Download main.js, manifest.json, and styles.css from the latest GitHub release.
  2. Create a folder named daily-text-colors — the plugin ID — inside your vault’s .obsidian/plugins/ folder.
  3. Place those three files in .obsidian/plugins/daily-text-colors/.
  4. Reload Obsidian.
  5. Enable Daily Text Colors under Settings → Community plugins.

Limitations

  • Outside edits cannot reveal their true historical date, so newly detected text is dated when Daily Text Colors reconciles the change.
  • Already-checked tasks are not retroactively assigned a completion date.
  • Metadata sync depends on your vault and plugin-data sync configuration.
  • Color carries meaning, so use the day legend and timestamp tooltips when color alone is not enough.

Support

Please report bugs and feature requests in GitHub issues.

Development

npm ci
npm test
npm run build
npm run lint

Before submitting a release, run all three checks and attach main.js, manifest.json, and styles.css to the GitHub release whose tag matches manifest.json.

For plugin developers

Search results and similarity scores are powered by semantic analysis of your plugin's README. If your plugin isn't appearing for searches you'd expect, try updating your README to clearly describe your plugin's purpose, features, and use cases.