Spell checking in the composer: cheap to switch on, awkward to get dictionaries for

[typedev]

What's missing

Nothing in the composer checks spelling — not the message body, not the subject. Mail is the one place where a typo is permanent: it arrives, it's read, and there's no editing it afterwards. Every other mail client on the desktop underlines the word before it goes out.

I went looking for what it would take, and the answer turned out to be lopsided in an interesting way: the checking itself is nearly free, and the dictionaries are the whole problem.

The body is two calls

The composer's editor is a WebKit view with a contenteditable body, and WebKitGTK has spell checking built in — squiggles, and suggestions in its own context menu. The bindings expose it on the web context:

ctx.set_spell_checking_enabled(true);
ctx.set_spell_checking_languages(&["en_US"]);

Both are present in the pinned webkit6 0.4. RichEditor::new already builds its view on message_view::shared_web_context(), so a single call there covers the composer; the reader's view shares that context but isn't editable, so nothing gets checked there.

Nothing in rich_editor.rs overrides context-menu, so WebKit's native menu — the one that carries the suggestions — should already come up in the editor. Worth confirming against the GNOME-styled menus used elsewhere, but it looks like no work is needed to get suggestions, only to switch checking on.

The dictionaries are the real problem

This is the part I'd want a decision on, because it decides whether the feature is honest or quietly broken.

Inside the runtime, /usr/share/hunspell/ lists 160 dictionaries. On a stock install, 18 of them resolve — every one an English variant, all hardlinks to the same data. English ships in the base runtime; the other 142 entries are symlinks into share/runtime/locale, which the org.gnome.Platform.Locale extension fills in.

That extension is installed, but only for the languages Flatpak has been told about — with nothing configured it follows the session locale, so a system running an English session gets Subdirectories: /en and 512 bytes of it. Every other dictionary is a dangling symlink.

Worth stressing because it is a trap: installing dictionaries through the distribution — Ubuntu's Language Support, hunspell-ru, and so on — puts them on the host, where a sandboxed app cannot see them. The user does the obvious thing, watches nothing change, and has no way to tell why. Flatpak wants flatpak config --set extra-languages, which is not a step anyone would guess at.

So set_spell_checking_languages(&["en_US"]) works everywhere, and any other language silently checks nothing. Not an error, not a warning — enchant simply has no provider for it, and the user sees a composer that underlines nothing and concludes the feature is broken.

Roughly three ways out, and they're not exclusive:

1. Ask the runtime what it actually has. The resolvable set can be read directly (/usr/share/hunspell/*.dic that are real files), or through enchant's own broker listing. Offer only those, and say plainly when a wanted language isn't installed.
2. Point at the locale extension. Missing dictionaries are a packaging matter the user can fix — but only if something tells them so. A line in Preferences beats silence.
3. Carry dictionaries in the manifest. Reliable, and it makes the download bigger for everyone regardless of what they write in.

Which language, though?

This is where mail differs from a text editor. A document has one language; a mailbox often doesn't — the same person may write to one correspondent in one language and to another in a second, and switch inside a single message when quoting.

The UI locale is the obvious default and the wrong answer on its own. Some possibilities:

• Follow the UI locale, with an override in Preferences.
• Let several languages be enabled at once — set_spell_checking_languages takes a list, and enchant will accept a word that any of them knows. Fewer false positives, at the cost of missing real errors in one language that are words in another.
• Per-account, for people whose accounts split along language lines.
• Per-message, chosen in the composer.

My instinct is the second as the default with the first as the setting, but this is a taste question about how much configuration the app wants to carry, so it's yours.

The subject line

Worth saying that this doesn't come for free. The subject is an adw::EntryRow, and GTK4 has no built-in checking for entries — libspelling isn't in the runtime or the SDK either, so it would mean a new dependency in the manifest for one field. Might be better left out entirely than half-done.

Questions

• Is this something you'd want in Vireo, or deliberately out of scope?
• If yes: does the missing-dictionary case get surfaced to the user, or does the app just check what it can and stay quiet?
• Multiple languages at once, or one at a time?
• Subject line too, or body only?

Happy to prototype any of it, or to leave it with you.

[hyprlab]

Yes we definitely should have spelling in this app including in the subject line. I will work on enabling it via Webkit and check in on the language support. Honestly I need to integrate more languages than English in this app. it's on my future radar. If that's something you'd be willing to do and offer a pull request for I'd certainly be open to it!

[hyprlab]

Shipped in stable 1.20.0, out now. Thank you for the proposal and the dictionary research, @typedev. What landed: WebKit's checker runs in the message body, and the subject line asks the same enchant engine directly since GTK entries have no checker of their own. Both check the word being typed, with a short pause before the word under the cursor is marked. Settings gains a Spelling section: an on-by-default switch, a language dropdown listing exactly the dictionaries actually installed, each named in its own language, and an "Added words" list for the personal dictionary that Learn Spelling feeds. The Flatpak bundles dictionaries for eleven languages beyond English. Update with flatpak update.