Editor
The Editor tab is where you configure how the writing surface itself behaves. Not the agents, not the storage, not the lore — just the editor where you actually type. The settings here are the ones that change how it feels to use Ishvana minute-by-minute: how fast it saves, how wide the text area is, whether spell check underlines misspelled words. They’re small settings but they add up, because the writing surface is where you spend the most time, and anything that feels slightly off there compounds across a long session.
This tab is the one most authors adjust within the first week of using Ishvana. The defaults are reasonable but not universal — different screen sizes, different reading habits, and different workflow preferences mean the settings that feel right for one author don’t necessarily feel right for another. Spend a few minutes here on your first real writing day and the editor will feel tuned to you.
Auto-save
Section titled “Auto-save”Two related settings: enable auto-save (toggle) and auto-save interval (slider).
When enabled, the editor automatically saves your current document at the configured interval. Default is every 2 seconds. The slider goes from 0.5 seconds (saves almost continuously) to 10 seconds (saves about every five thousand characters of fast typing).
Why 2 seconds is the default: fast enough that you essentially can’t lose more than a sentence of work if something crashes, slow enough that the save disk I/O is never perceptible. Modern SSDs can handle a save every 500ms without breaking a sweat, but there’s no practical benefit to going faster than 2 seconds — the marginal safety is tiny and some older disks can feel the 500ms cadence.
Auto-save is incremental — it only writes the changed bytes, not the entire document. That’s why the cost stays low even at aggressive intervals.
Turning off auto-save is supported but not recommended. If you turn it off, you’re responsible for manually pressing Ctrl+S before closing the editor, and if Ishvana crashes before you save, you’ll lose whatever was typed since the last manual save. The only reason to turn it off is the psychological preference some authors have for explicit saves as punctuation in their workflow — if that’s you, go ahead, but understand the tradeoff.
Spell Check
Section titled “Spell Check”A toggle: browser-level spell check (on/off).
When on, the editor uses the operating system’s native spell checker to underline misspelled words as you type. Right-click on any underlined word to see suggested corrections and add the word to your personal dictionary.
Default: On.
The spell checker is the one built into Electron (which uses your OS’s native spell check engine). It’s not a specialized writing spell checker — it won’t catch homophones, wrong-word errors, or grammar issues. It catches typos. For anything more sophisticated, use ProseGuard or Hawken’s style analysis.
There’s a custom dictionary file at data/Custom Dictionary.txt that captures words you’ve added via right-click. The dictionary persists across sessions. If you’re writing in a secondary-world fantasy with a lot of invented proper nouns, you’ll spend the first week of writing adding those nouns to the dictionary, and after that the spell checker stops underlining them.
Content Width
Section titled “Content Width”A slider: content width (600px to 1400px).
This controls the maximum width of the text column inside the editor. Outside this width, the editor area adds margins so your text doesn’t stretch edge-to-edge on wide screens.
Default: 760 pixels.
Why 760px specifically: it’s the width that produces comfortable 65-85 character lines in a typical book font at a readable size. The 65-85 character range is the standard typographic wisdom for long-form reading — anything narrower feels cramped, anything wider makes your eye lose the line break.
Slide wider if you have a very large monitor and prefer more text on screen at once. Slide narrower if you want the editor to feel like a single column on a printed page. The slider has 20-pixel steps, which is fine enough for preference and coarse enough that you don’t fuss with it.
One-time migration
Section titled “One-time migration”If you used a pre-1.0 version of Ishvana, you may have had a content width value stored in browser localStorage under the key ishvana:contentMaxWidth. Ishvana’s current version does a one-time migration on first launch: it reads the legacy value, saves it as your current content width, and deletes the legacy key.
The migration runs silently. You don’t see it happen. The only reason to know about it is if you’re wondering where a non-default value came from when you first open the new version.
Font family (future)
Section titled “Font family (future)”The Editor tab will eventually gain a font family picker — a way to choose between the default serif font, a sans-serif, a monospace, or a custom font you supply. Currently the font is fixed to a single carefully-chosen serif optimized for long-session reading.
When the font picker lands, it’ll go on this tab. For now, the setting doesn’t exist and you can’t change the editor font. If you really need a different font, the CSS theming layer has hooks, but it’s not a supported user-facing setting yet.
What the tab doesn’t include
Section titled “What the tab doesn’t include”A few things that aren’t here but are tangentially related:
- Keyboard shortcuts for the editor. Those are part of the app-wide keyboard shortcuts, which are currently hardcoded.
- Scroll behavior. Whether the editor auto-scrolls to follow the cursor, etc. Hardcoded to sensible defaults.
- Undo depth. How many undo steps the editor keeps in memory. Configurable on the Performance tab, not here, because it’s technically a performance-related setting (larger undo stacks use more memory).
- Dialogue formatting. Auto-close quotes, smart quotes, auto-dash conversion. Hardcoded — the editor does the right thing without settings for it.