Setting: filter file tree by extension allowlist

[spamsch]

Problem

The current fileTreeContentMode setting is a binary — either notes_only (markdown + PDF + HTML) or all_files. There's no way to say "show markdown, PDF, and CSV but not everything else." Power users with mixed vaults want finer control over what shows up in the tree.

Proposed setting

Add a fileTreeExtensionFilter: string[] setting — an ordered list of extensions that should be visible. An empty array means no filter (show everything, consistent with the current all_files behaviour). Extensions stored without the leading dot: ["md", "pdf", "txt"].

High-level implementation plan

1. Settings interface (settingsStore.ts)
Add fileTreeExtensionFilter: string[] to the Settings interface alongside the existing fileTreeContentMode and fileTreeShowExtensions fields.

2. Default + normalization (settingsStore.ts)
Default to [] (no filter). In the normalization pass, ensure the value is an array of non-empty strings and strip any leading dots so input like .md and md both work.

3. Filtering logic (FileTree.tsx, visibleEntries memo ~line 1790)
After the existing fileTreeContentMode check, apply the extension filter when the list is non-empty:

if (fileTreeExtensionFilter.length > 0 && entry.extension) {
  return fileTreeExtensionFilter.includes(entry.extension.toLowerCase());
}

Folders are always shown regardless (same as today).

4. Settings UI (Developer or Navigation section in the settings panel)
A tag/chip input where users type an extension and press Enter to add it, with an ✕ to remove each one. Show a placeholder like pdf, txt, csv … when empty. Sits below the existing "Show file extensions" toggle.

Out of scope

• Glob or regex patterns (keep it simple for now)
• Per-folder overrides
• Hiding folders based on extension rules

[jsgrrchg]

This is technical debt from the initial implementation of the file tree. The app was originally intended to be a Markdown editor, and I expanded its functionality over time. Im working on a fix now with your suggested scope.

Eventually, I’m thinking of removing the distinction entirely and making the app always operate in “all files” mode. This would also align with the direction we discussed yesterday about the terminal. What are your thoughts on this?

The reason I’m leaning this way is that nobody had reported this issue before, which suggests that users are clearly using “all files” mode already.

[jsgrrchg]

Implemented in draft PR #117: #117

What changed:

• Added a fileTreeExtensionFilter setting with normalized extension chips.
• Added the Settings UI under Developers → File Tree.
• Empty filter now uses the current content mode.
• Non-empty filter acts as an explicit allowlist and overrides “Show all vault files”.
• File tree now supports a curated default set when all-files mode is off: Markdown, PDFs, images, CSV, TXT, and HTML.
• Aligned related surfaces so curated/all-files/allowlist behavior is consistent across the file tree, @ mentions, New Tab / Quick Switcher, and wikilink suggestions.
• Added tests for settings persistence, file tree filtering, curated defaults, mentions, quick switcher, and wikilink suggestions.

Looks good for now, and is clear for power users and non technical users.

[jsgrrchg]

Follow-up: this ended up being trickier than expected, because the setting was not just a file tree concern.

After the initial implementation, I aligned the rest of the file-facing surfaces so the behavior is consistent:

• New Tab / Quick Switcher now respects the curated/all-files/allowlist scope.
• Already-open tabs remain searchable in Quick Switcher even if the current allowlist would hide them from vault results.
• @ mentions now use the same curated/all-files/allowlist rules for mentionable files.
• Wikilink suggestions now include curated text-like files, respect the allowlist, and avoid stale file suggestions after vault structure changes.
• Search Files & Notes now passes an explicit file scope to advanced_search, so backend results also respect curated/all-files/allowlist behavior.
• The PR now includes frontend and Rust tests covering the setting, file tree, mentions, quick switcher, wikilinks, and advanced search scope.

So the PR now treats fileTreeExtensionFilter as a shared file-navigation/search scope rather than a tree-only filter.

If you can give it a look (only if you are able), otherwise I will review it in a couple of hours with fresh eyes and merge. Now looks solid and consistent.

I'm still considering that for simplicity of the source code and the product, maybe it would be best to keep the app in all files mode as the only mode.

[jsgrrchg]

Don’t review it yet. I’m simplifying the logic first. I used AI during the iteration process, but after reviewing everything manually, I realized the code is bloated. I’m working on making it more readable and straightforward.

[jsgrrchg]

Quick update: I ended up cleaning up the implementation quite a bit after that last note.

The PR now treats fileTreeExtensionFilter as a shared file-navigation/search scope, not just a File Tree setting. That means the behavior is aligned across the File Tree, New Tab / Quick Switcher, Search Files & Notes, @ mentions, and wikilink suggestions.

Normal mode now keeps a curated set visible: Markdown notes, PDFs, images, Excalidraw, CSV, TXT, HTML/HTM, and folders. If an extension allowlist is set, it takes over explicitly.

I also moved the shared file-scope logic into common helpers, extracted the extension filter input out of the Settings panel, and simplified the backend search matching so the code is less scattered now.

I think this is in a much better shape to review. If you can give it a spin.