Skip to content

feat: add option to control metadata indicator visibility#2214

Open
slimslickner wants to merge 8 commits intobeancount:mainfrom
slimslickner:feat/show-metadata-indicators-option
Open

feat: add option to control metadata indicator visibility#2214
slimslickner wants to merge 8 commits intobeancount:mainfrom
slimslickner:feat/show-metadata-indicators-option

Conversation

@slimslickner
Copy link
Copy Markdown

Add a new Fava option 'show-metadata-indicators' (default: true) that allows users to disable the display of metadata indicator badges in the journal.

This addresses issue #2180 where metadata indicators were consuming valuable screen space and hiding important information like payee and narration text.

Users can now disable indicators by adding to their Beancount file:
2024-01-01 custom "fava-option" "show-metadata-indicators" "false"

The option is backward-compatible and defaults to showing indicators, maintaining existing behavior for current users.

Add a new Fava option 'show-metadata-indicators' (default: true) that allows
users to disable the display of metadata indicator badges in the journal.

This addresses issue beancount#2180 where metadata indicators were consuming valuable
screen space and hiding important information like payee and narration text.

Users can now disable indicators by adding to their Beancount file:
  2024-01-01 custom "fava-option" "show-metadata-indicators" "false"

The option is backward-compatible and defaults to showing indicators,
maintaining existing behavior for current users.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
slimslickner and others added 2 commits February 8, 2026 00:37
Update test snapshots to include the new 'show_metadata_indicators'
field in FavaOptions that was added to control metadata indicator visibility.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
@yagebu
Copy link
Copy Markdown
Member

yagebu commented Feb 15, 2026

This feels inconsistent: all the other visibility toggles are buttons above the journal - why differ on this one?

@slimslickner
Copy link
Copy Markdown
Author

@yagebu I had that thought too.

For me, this feels like a ledger-level decision because metadata usage would likely be consistent across a ledger. For example, if I want to see metadata values, I can still click the Journal "Metadata" toggle (or "m" keyboard shortcut) and the unfold works the same as before.

Maybe it's just my personal use case, but metadata is only useful in querying and seeing the actual values; badges for an all the metadata abbreviations isn't meaningful for me. The reason for this is 99% of transactions will have the same metadata abbreviations (either na for narration from autobean.narration or ma for match_id from zerosum). As such, the badges take up space and I already would expect the postings to have those metadata keys.

I appreciate the posting indicator dots because 1) it's something to click on to unfold a single transaction and 2) they are significantly smaller and are an easy reference to the "complexity" of a transaction. However, I could see an argument made that they should be "hide-able" too.

Regardless, I hear your concern and am open to a counter-argument.

@slimslickner
Copy link
Copy Markdown
Author

I thought of another reason why I would prefer a fava-option (or at least not in the existing pattern of toggles at the top of the Journal page). Every toggle at the top of the Journal page leads to additional or fewer rows being shown in the ledger, whereas this toggle would be the equivalent of showing/hiding columns (like show/hide tags or links or narrations).

Definitely want your thoughts and happy to change this implementation if I'm going against the fava design patterns.

@slimslickner
Copy link
Copy Markdown
Author

Copying some screenshots from the original issue.

Here's a before and after [partial] screenshot of my ledger, with the show_metadata_indicators option set to true then to false:

Image Image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants