Spell checking for IDE source editor -- Lazarus 4.99

[Martin_fr]

Btw, not sure if you saw, and also for anyone else.

The color config section has an entry for "misspelled token". And aside from the color/underline for the text, it also offers a color for the overview gutter. So its possible to see all locations that have been found by spell checking.

[paweld]

Should be fixed.

Thank you very much, now it's OK.

The color config section has an entry for "misspelled token".

I hadn't seen this before, but I looked it up and it really is pretty customizable.

But for now, I’m still figuring out whether spell-checking makes sense for my projects (initially yes, because I have to display a lot of messages for users, and I often make mistakes: switch the order of characters), on the other hand, I use a lot of SQL in my programs, and with queries as well as field and parameter names, the highlighting is often misleading.

[Martin_fr]

Well, for the SQL, you can add tables and fields to your own dictionary. (there is a field to specify the file). Though its global => for all projects.
=> its a plain text file. So you can edit it in case of mistakenly added words.

Also, fields (and idents in source) are often based on words. Though, if your text is not English, your code still may be based on English => then you need both languages. (there may be some way using .multi files / according to google / as I said, not yet looked into adding config in the IDE for that...)

Of course they often have prefixes. E.g. in Sources many words are prefixed by T, F, I (Interface), P (pointer type)... => "List of chars (prefix) to ignore at start...": TFfPI   (case sensitive)

And "PasswordHash"  => words are broken at camel casing, and each part tested. (and "_" snake is not a word-char, so password_hash is always 2 words.)

Short words, or short "camel parts" can be ignored (ok, then they are not checked in strings either).


I do need to document all of that still...

But in most of my sources, I get few false positives. On the other hand, some files in the RTL have concatenated all lowercase idents => they can't be broken down, and show up.

Of course all of those rules are based on my experience with English based code. (Albeit, I think they would work for German based too). If there are common enough other cases for other languages....


another issue is "don't" => because the ' isn't a word char (and the spelling is done word-wise in order to deal with above extra checks.

Also in Pascal "don't" can only appear in a comment. In a string it would be "don''t" (escaped '). But the escaping is language specific, and the spell check works for all files...

[paweld]

Well, for the SQL, you can add tables and fields to your own dictionary. (there is a field to specify the file). Though its global => for all projects.
=> its a plain text file. So you can edit it in case of mistakenly added words.

I know you can add entries to the dictionary, but unfortunately that won't work for me (in terms of SQL) because the databases I connect to use Polish tables and columns names, which would cause spell-checking to stop working - table and column names don't contain Polish characters, so for example there is a column wartosc, but the correct spelling is wartość: Once I add “value” to the dictionary, it will stop underlining incorrect words in messages.
I had an idea to be able to disable string checking for specific methods in specific structures, e.g., for TSQLQuery in SQL.Add, SQL.Text, ParamByName, FieldByName, etc. For now, I’m exploring this possibility, and given my skills, it might take some time.

And "PasswordHash"  => words are broken at camel casing, and each part tested. (and "_" snake is not a word-char, so password_hash is always 2 words.)

I noticed it right away, and it's a really cool idea.

[Martin_fr]

I had an idea to be able to disable string checking for specific methods in specific structures, e.g., for TSQLQuery in SQL.Add, SQL.Text, ParamByName, FieldByName, etc. For now, I’m exploring this possibility, and given my skills, it might take some time.

I had just put the same idea to my "reflecting on" list in the back of my mind.

The config would need to have start/stop pairs of some kind. Then default could be checking on or off, and inside the blocks that would be reversed. So you can either exclude blocks of code. Or you can only check those blocks.

Doing that multiline will however be costly, as the indicator could be far away (albeit, once found it can be remembered, it would just be a search list form MarkupMatchAll...

Blocks could be hardcoded tokens => then you can configure "{SPELL OFF}" which is a comment. Or they can be regex. (Though multi line regex will be a problem, as the text is stored per line)

Of course you could do start at "SQL|Query" => stop at ";" (though that would need to be outside of strings, tricky)

[Martin_fr]

Doing that multiline will however be costly, as the indicator could be far away (albeit, once found it can be remembered, it would just be a search list form MarkupMatchAll...

Just to clarify a bit more... If you plan to do anything... (I might, but not immediate / got other stuff)

Spellchecking just is a TSynEditMarkupHighlightAllBase => search all words matching a certain criteria.(the criteria being "not in dictionary").

Finding start/stop tokens could be just yet another TSynEditMarkupHighlightAllBase. Albeit, it does not need to actually highlight the found tokens, just store them. But it would have all the code to find them and keep the list of them. (it could even have "find only non-comment..." checks, etc)

Of course Spellchecking then needs code to "wait for" the token search. And then it can just check if it is or is not between a pair of enable/disable tokens.