Settings
Most writing tools bury their settings in a modal you visit once during setup and never again. The settings are usually either obvious (which theme, which font size) or impossibly technical. Ishvana’s settings are somewhere in the middle — enough depth that serious users can shape the tool to their workflow, but organized clearly enough that nobody has to dig through nested menus to find the thing they want to change. This section of the wiki walks through every current settings surface. Most knobs have good defaults. You probably don’t need to change most of them.
The settings modal is reachable from the gear icon in the main app, or from the Settings keyboard shortcut, or from the Getting Started quickstart flow on first launch. It opens as an overlay on top of whatever you’re currently working on and closes without disrupting your state.
What’s in this section
Section titled “What’s in this section”When to visit settings
Section titled “When to visit settings”Three times in a typical user’s life:
First launch. The Getting Started flow walks you through the essential settings during onboarding — picking a theme, activating your license, and confirming auto-save. After that, the settings sit in the background.
When something changes. Getting a new GPU and want Ishvana to use it? Visit Performance. Installing an authored-library expansion pack? Visit Divinity Engine. Buying a license for the first time? Visit Licensing. Settings visits are usually tied to a specific life event.
When something stops feeling right. The editor width isn’t working for your screen. The auto-save interval is too aggressive. The notification level is too noisy. You visit Settings, find the knob that matches, adjust it, close the modal, and get back to writing.
For most authors, the answer to “should I be touching this setting?” is “only if you know why you want to.” The defaults are tuned to work for the common case. The knobs exist for the uncommon cases.
What settings are and aren’t
Section titled “What settings are and aren’t”Settings are user preferences — how you want the app to behave. They’re distinct from:
- Project data. Your manuscripts, your Legendry, your outline — all of that is data, not settings. It lives in your project’s data directory and isn’t affected by what’s in the settings modal.
- System state. Window size, active tab, current scroll position, recent files — these are state, not settings. They persist across restarts but they’re about where you left off, not about how you’ve configured the tool.
- Engine behavior. What the Divinity Engine does under the hood — handler dispatch, tool registry, authored-library rendering, caching — is engine behavior. You influence a curated subset through settings, but most handler contracts are fixed so results stay reproducible.
The settings modal is about the user-preference surface. If you’re looking for something and can’t find it, ask whether it’s actually a preference or whether it’s project data, system state, or engine internals — the answer might be that it’s configured somewhere else.
Configuration layers
Section titled “Configuration layers”Some settings are global (apply to every project), some are per-project, and a few are per-document. The modal makes this distinction clear when it matters.
Global settings live with your user profile, not with any specific project. Theme, keyboard shortcuts, default editor width, and performance preferences follow you across every project you open.
Per-project settings live inside the project’s data directory. Project-specific name format, project-specific category tree, project-specific backup preferences — these apply only to the project they’re configured in.
Per-document settings are rare but exist. A specific document might have its own POV override, its own chapter word count target, its own ProseGuard rule exceptions. These are usually set inline from the document’s own context menu rather than from the main settings modal.
When a setting has multiple layers, the more specific layer wins. A per-document override beats a per-project default, which beats a global default.