Add Search / Select Bar to the Document Viewer Pane

[Alok-S-Sharma]

This request proposes enhancing the existing Viewer-side document explorer with a search/filter capability, rather than introducing a new panel.

Problem Description

While writing, I often need to quickly reference other project elements such as chapters, scenes, characters, locations, or notes.

The Document Viewer Pane already allows viewing reference material such as Characters, Locations, and other project documents without disrupting the editor. This makes it ideal for reading and cross-referencing information while writing.

However, selecting what document to view currently relies on manual navigation and scrolling via existing lists or panels. In larger projects, this becomes inefficient when the goal is to quickly locate and view a specific document.

At the same time, Find in Project already exists, but accidentally pressing Enter opens the document in the editor, which shifts focus and interrupts the writing flow when the intent is only to reference information.

This workflow breaks writing focus and adds unnecessary friction, especially in large projects with many documents. The mental and physical effort of repeatedly navigating the project tree becomes fatiguing over time.

Proposed Solution

Add a search / select bar at the top of the Document Viewer Pane, above the viewer content.

This proposal intentionally does not change the existing viewer layout, panels, or behavior. It only adds a fast, dedicated way to select which document is displayed in the Viewer.

Suggested behavior:

• Add a searchable selector bar at the top of the Viewer pane
• Clicking the bar opens a list of all project documents
  • Optionally shown as:
    • A tree (mirroring project structure), or
    • A flat, searchable list
• As the user types, the list dynamically narrows based on:
  • Document title
  • Keywords
  • Type (scene, character, location, note, etc.)
• Selecting a document instantly loads it into the Viewer pane

This turns the Viewer into a context-aware reference panel, allowing writers to keep important documents “on standby” while continuing to write.

Benefits

• Significantly reduces context switching and cognitive load
• Faster access to reference material during writing
• Especially helpful for:
  • Large projects
  • Character-heavy or location-rich stories
• Writers who frequently cross-reference documents
• Keeps the writing flow uninterrupted

Alternative Solutions Considered

• Continuing to rely on manual scrolling and selection methods for viewing documents
• Using Find in Project despite it opening documents in the editor
• Navigating the Project Tree and manually loading documents into the Viewer

All of these work, but they scale poorly as project size and reference material grow.

Screenshots / Visual Reference

(Attached screenshot shows a similar concept where a Search / Select Bar allows selecting project elements to keep visible while writing.)

Summary

This feature would be an evolution of the existing Document Viewer, not a replacement.
By adding a lightweight, searchable document selector, novelWriter can make cross-referencing faster, reduce navigation fatigue, and further strengthen its reputation as a writer-centric tool designed for long-form projects.

[vkbo]

The project search feature is still very basic, and more features are planned. Including filters on what parts of a document to search (see #2256). It does make sense to add a way to also open the result in the viewer.

A global way to quickly find and open documents by keyboard shortcut or search bar is also one I've considered. I think I would make the search work for either panel though, not just the viewer.

In the project tree, novel view and outline view, Enter opens in the editor, and Shift+Enter in the viewer. Adding this to the search tool should be easy enough as a first iteration, and a search bar could operate in the same way.

Note that I also intend to merge the now separate editor and viewer panel into a single GUI element for both panels and allow the user to switch between edit/view mode at will instead. So I'm trying not to add any new features that are tied only to one mode/panel.

[Alok-S-Sharma]

If you’re moving toward a single merged editor/viewer surface with an edit/view toggle, one idea that might preserve the “write + reference” workflow without tying features to a specific panel is a dedicated Reference pane (dockable, e.g. right side).

The reference pane could act as a combined document browser + project search: tree/flat list with a search bar at the top, keyboard navigation, and quick open behavior (Shift+Enter opens in the main surface; Enter previews/pins in the reference pane).

This would avoid disrupting writing flow (no constant mode switching on the same surface) while still matching the direction you mentioned: features remain mode-agnostic and the main editor/viewer can be refactored into one GUI element.

This also reduces the need for features that depend on a viewer panel because reference viewing happens in a separate dock that doesn’t care whether the main surface is edit or view.

[vkbo]

There will still be two panels like today, where the left is the main one that defaults to edit and the right to view, but the GUI components will be merged so it is possible to switch mode. Primarily so you can edit your notes without having to open it in the editor and disrupt whatever you were working on there. It's something I have to do often when writing myself, and it is a little annoying.

I do not plan to add more panels along the horizontal axis. I do plan to generalise the panel below the viewer to a full width panel though, where you can have various tools. At the moment there is no need as the reference panel is the only one implemented.

[vkbo]

Please don't close the feature requests.

[Alok-S-Sharma]

Got it — thanks for reopening and for the clarification. I’ll leave feature requests open going forward.