SpellCheckHighlighting for vw8.0?

Until 7.10.1 there was SpellCheckHighlighting and SpellChecker2. With
this you could easily add a SpellChecker with its controller to every
TextEditor widget.

With 8.0 however, things have changed dramatically in this area.
Controllers no longer have the tasks they had before, and with
DocumentView for Text2 (which has interesting potential in this case)
also the "old" highlighting doesn't work and also doesn't fit anymore.
So the goodie should be worked on.

I took a quick look at how this would have to be done, but it doesn't
seem that easy.
Has anyone already started to port the SpellingHighlighter to 8.0?

Thomas
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

> On 6 Feb 2015, at 8:54 pm, Thomas Brodt <[hidden email]> wrote:
>
> Until 7.10.1 there was SpellCheckHighlighting and SpellChecker2. With this you could easily add a SpellChecker with its controller to every TextEditor widget.
>
> With 8.0 however, things have changed dramatically in this area. Controllers no longer have the tasks they had before, and with DocumentView for Text2 (which has interesting potential in this case) also the "old" highlighting doesn't work and also doesn't fit anymore. So the goodie should be worked on.
>
> I took a quick look at how this would have to be done, but it doesn't seem that easy.
> Has anyone already started to port the SpellingHighlighter to 8.0?
>

We left it out of 8.0 because the quality of the spellchecking results was too poor. I’ll be interested to hear your progress if you decide to do it though. You’ll have to make a choice as to what kind of widget you want to do it to - text editing in general, or code editing.

The source code editor is designed with the idiom that the style of the content is not under the users control, while regular text editing is the opposite, that the styling is part of their content and should not be destroyed. It should be easy to integrate spellchecking in to the source code editor, but possible a bit harder to do it in the regular text editor. I haven’t given it too much thought so I’m not sure if that assessment is entirely true.

Cheers,
Michael
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hi Michael

thanks for your explanation. Our use of the SpellChecker wasn't for
source code, but for user comments in report logs. The quality wasn't
perfect, but at least there was some highlighting for typos. Checking is
quite difficult in our languages (swiss) german, french and italian, anyway.

We have regular text fields where users can add comments to reports or
other values that are entered in some forms. The text is not or only
poorly formatted (just some colors, bold, italic, etc. but no font sizes
or paragraph formatting or even graphics). Some years ago, our users
requested a spell checker for these comments, so I added the
SpellCheckHightlighting to the text widgets which was really easy to do
in e.g. a postBuildWith: method in ApplicationModels.

For the new DocumentView, if I understand that correctly, I have two
choices: Either reimplement some of the infrastructure for text
decorations that are used in class SourceCodeEditor in a subclass of the
regular DocumentView (or extend DocumentView itself), adapted for my
needs. That way I have control over what I want to include or leave out.
Or, on the other hand, use SourceCodeEditor as "our" text editor and get
rid of all the stuff that has to do with text decoration for source code.

I would prefer the first, because the parsing and analyzing in
SourceCodeEditor is hardwired to RBParser, not to a natural language
scanner based on whitespaces, and much code is too code centric. But
that way I have to add more code around that to get my spell checking
DocumentView instead a regular one from a texteditor spec in a window
spec. You know what, I would have preferred the (empty) infrastructure
for decorations in DocumentView, so I could just add mine for the spell
checking in the regular one ;-)! Or a subclass between the two. Could I
have a wish for the next release, please?

I will let you know when I got somewhere with my spell checking support.

Cheers!

Thomas

Am 06.02.2015 um 21:08 schrieb Michael Lucas-Smith:

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

>
> I would prefer the first, because the parsing and analyzing in SourceCodeEditor is hardwired to RBParser, not to a natural language scanner based on whitespaces, and much code is too code centric. But that way I have to add more code around that to get my spell checking DocumentView instead a regular one from a texteditor spec in a window spec. You know what, I would have preferred the (empty) infrastructure for decorations in DocumentView, so I could just add mine for the spell checking in the regular one ;-)! Or a subclass between the two. Could I have a wish for the next release, please?
>
> I will let you know when I got somewhere with my spell checking support.
>

Sure I’ll look in to putting a subclass in the middle for decorating and plugin support.

Cheers,
Michael


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc