[FEATURE]: Improve handling of mix-case words

[daogilvie-9fin]

Feature Description

Hi! Thanks for a great bit of software, I've dropped nvim's built-in spellcheck due to issues with tree-sitter and I'm really liking using codebook-lsp instead!
That said, I've noticed that mixed-case words, such as "PostgreSQL", don't quite work as I would expect. This seems to be because the splitter code here is splitting on case changes.
It would be really great if there was a way to enable/disable case-based splitting to account for proper nouns such as "PostgreSQL" — a word that codebook knows about out-of-the-box!

I am not filing this is a bug because I don't think it's something not working as intended per-se, but you might prefer that it is one? Please let me know.

Use Case

In my case I have comments/docs that refer to PostgreSQL, and codebook detects that "Postgre" is not a word it knows, and helpfully offers to replace it with PostgreSQL, which then makes the word PostgreSQLSQL 😂 Which is, of course, still flagged as a mis-spelling.

Proposed Solution

The simplest solution is a config-driven toggle, to control whether the splitter splits on case boundaries at all?

Alternative Solutions

A more complicated solution would be to have the splitter return the whole word as the first potential split for case based splits (not just the individual parts), and if that happens (and is a valid word), then it could ignore the subsequent split elements?

Examples

This is an example of the problem, and what I'd like to see instead

Screen.Recording.2025-09-24.at.12.31.45.mov

Additional Context

I am not really a rust dev, so I might have missed something very obvious when reading the code. That said, I am happy to try my hand at writing some rust for this as a PoC, if you'd want to see the code explored at least a little bit first.

[blopker]

Hey! Thanks for the kind words. I see the issue, and yeah, it's not an easy problem to fix generally. To keep Codebook fast, the processing is greedy to avoid having to scan documents multiple times. This means the case splitting happens early on and the spell checking happens after.

Are there other words that are causing issues? My initial thought is to just add "postgre" to the default wordlist and move on :)

[daogilvie-9fin]

Are there other words that are causing issues? My initial thought is to just add "postgre" to the default wordlist and move on :)

Right now there's only a small collection of proper nouns, most of which are internal jargon to my work anyway. I have already added 'postgre' to the wordlist in config 😂 This is definitely not derailing my use of codebook! It was something that I wanted to raise because it felt inconsistent that it would suggest PostgreSQL as a replacement, when the algorithm is physically incapable of recognising it as a word.

I am curious as to the reverse of your question: what is an example of a case-separated word string that we would want spellchecked as segments? Is it something common in the domains you have worked in, or do work in?

Happy to close this issue if you don't think there's any reasonable approach to take — it's a very minor annoyance for me with something that otherwise works like a treat.

[blopker]

I agree, there's an issue here that should be addressed. I'll need more examples to see what would make a sensible fix though. I've changed the title of this issue to get more at the general problem. Maybe someone will chime in with more painpoints.

[daogilvie-9fin]

Wonderful thank you! As mentioned, I'm not really a rustacean, but if I can help I'd love to give it a go. If I come across any other examples of mixed-case words (working as intended or not), as I roll out codebook across my new job's repositories, I will add them here.

[vorchunpaul]

Hi. I also ran into this problem. I work at embedded, and we have different abbreviations such as ISOtest, IEEEmask, SPIconf, etc. As far as I understand, codebook sees two words instead of one. Example of ISOtest = IS + Otest, and I have to add Otest to the dictionary so that there is no warning. It would be great if we could solve this problem.