# Plugin API Gaps (Historical)

> **Note:** This document is historical. Current truth lives in the executable compatibility/build/test gates rather than a broad coverage document.

This document tracked API gaps discovered while implementing built-in plugins (Issue #22). Most gaps have been resolved.

## View Registration (Critical)

**Gap:** `Plugin.registerView()` stores views in a private Map but nothing renders them.

**Current State:**
- `Plugin` class has `registerView(type: string, viewCreator: ViewCreator)`
- Views are stored in `this.views` Map
- Nothing reads from this Map or renders the views

**Impact:** Plugins cannot register custom sidebar views.

**Workaround:** For FileTreePlugin, we control the existing FileTree component through callbacks passed to the plugin. The plugin doesn't own the view rendering.

**Recommended Fix:** Implement a ViewRegistry in App that:
1. Accepts view registrations from plugins
2. Provides a way for layout components to query available views
3. Renders views in designated areas (sidebar, right panel, etc.)

**Priority:** High - needed for any plugin that wants to add custom views

---

## Vault Events for Search Indexing (Deferred)

**Gap:** BackgroundIndexer uses schedule-based reindexing rather than reactive Vault events.

**Current State:**
- Vault emits create/modify/delete events with TFile objects
- TFile has path-based identity but no AutomergeUrl
- BackgroundIndexer works with AutomergeUrl-based identity
- There's no public API to look up AutomergeUrl from TFile path

**Impact:** Search index updates are periodic rather than instant on file changes.

**Status:** Intentionally deferred. The schedule-based approach is sufficient for the current use case. Reactive indexing via Vault events would require either:
1. Adding `url: AutomergeUrl` to TAbstractFile (breaking API change)
2. Exposing `Vault.getUrlForPath(path: string): AutomergeUrl | null`

**Priority:** Low - current behavior is acceptable

---

## Wikilink Plugin Implementation (Completed - Issue #23)

**Status:** Implemented

**Components Added:**
- `WikilinkPlugin` (`src/plugins/wikilink/`): Plugin class orchestrating wikilink features
- `WikilinkAutocompletePlugin` (`src/editor/plugins/`): Lexical plugin for [[ autocomplete in WYSIWYG mode
- `WikilinkClickPlugin` (`src/editor/plugins/`): Click-to-navigate on wikilinks via data-target attribute
- `BacklinksPanel` (`src/layout/`): Right sidebar component showing backlinks with context
- `Vault.getMarkdownFiles()`: List all markdown files in vault
- `Vault.getUrlForPath()`: Get Automerge URL for a file path
- `SearchService.findBacklinks()`: Find documents linking to a target
- `WikilinkNode.setLinkResolver()`: Static method for unresolved link detection

**Architecture:**
- Autocomplete only in WYSIWYG mode (source mode uses existing TextMatchTransformer)
- Backlinks computed on-demand via content scanning (no separate index)
- WikilinkNode uses existing `data-target` attribute for click handling
- Unresolved links highlighted via `data-unresolved` attribute + CSS
- Callback-based integration with AppShell (same pattern as FileTreePlugin/QuickSearchPlugin)
- WikilinkHandlers interface passed from AppShell to editor components