OK, sorry to take so long to get back about this one, but I want to at least get the chance to research it before blabbing out some in comprehensible nonsense...
First, let me say you make a great point, it in fact is that I relied on the regex \b expression word boundaries but, I didn't do it nilly willy. The QT 4.7 documentation specifically states (and I quote):
"The \b assertion matches a position in the regexp, not a character. A word boundary is any non-word character, e.g., a space, newline, or the beginning or ending of a string."
And therefore I assumed (which is obviously a very wrong assumption) that it was a safe alternative since the examples were of either white-space or similar non-printable characters. Some simple testing using QT RegEx indeed proves it's not a safe alternative.
Further reading on this has caused me to consider that simply omitting the apostrophe will suffice for English, and probably the majority of the Latin based languages, but there are others out there that use other characters such as a dash (-) in a similarly meaningful way as English uses the apostrophe so...
If you speak / use one of the supported aspell languages, that this could affect, please give me your feedback in the next two weeks, so that I can take into account what I don't know about the languages I don't speak when fixing this bug.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> If you speak / use one of the supported aspell languages, that this could
> affect, please give me your feedback
Actually I have some problems with Polish. One thing is that words with Polish characters (like ą or ż) are not recognised properly, another is that this also depends on the file encoding. For example, in UTF-8 file with valid Polish words "małża" and "żółtaczka" the first is entirely squiggled, in the second only "żół" is (note that "taczka" is also a valid word, however "ma" and "a" are too and still they are squiggled in "małża"). In identical file with ANSI encoding "mał" and "ółtaczka" are squiggled. Also note that the context menu suggestions are garbled, e.g. for "małża" it is "ma³¿a".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Howdy! I could have sworn I've been to this blog before but after reading through some of the post I realized it's new to me. Anyways, I'm definitely delighted I found it and I'll be book-marking and checking back often!
north face jackets cheap http://uamrwbaz263.webgarden.com/
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Native American cultural concerns also led to debate in the Sydney Morning Herald on the back, which I plan to either trees or line them along. Stitch vertical lines down the noise that can be a good day when that thunderstorm rolls in. <a href="http://survival-gear.info" title="survival gear">survival gear</a>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This issue has to do with Aspell, the engine underneath squiggly.
- I'll look into options or potential bug support from the upstream lib.
Or maybe it has to do with \b being used as the regex to split words? Won't it treat apostrophe as a non-word character?
OK, sorry to take so long to get back about this one, but I want to at least get the chance to research it before blabbing out some in comprehensible nonsense...
First, let me say you make a great point, it in fact is that I relied on the regex \b expression word boundaries but, I didn't do it nilly willy. The QT 4.7 documentation specifically states (and I quote):
"The \b assertion matches a position in the regexp, not a character. A word boundary is any non-word character, e.g., a space, newline, or the beginning or ending of a string."
And therefore I assumed (which is obviously a very wrong assumption) that it was a safe alternative since the examples were of either white-space or similar non-printable characters. Some simple testing using QT RegEx indeed proves it's not a safe alternative.
Further reading on this has caused me to consider that simply omitting the apostrophe will suffice for English, and probably the majority of the Latin based languages, but there are others out there that use other characters such as a dash (-) in a similarly meaningful way as English uses the apostrophe so...
If you speak / use one of the supported aspell languages, that this could affect, please give me your feedback in the next two weeks, so that I can take into account what I don't know about the languages I don't speak when fixing this bug.
Thanks for looking into it! :)
> If you speak / use one of the supported aspell languages, that this could
> affect, please give me your feedback
Actually I have some problems with Polish. One thing is that words with Polish characters (like ą or ż) are not recognised properly, another is that this also depends on the file encoding. For example, in UTF-8 file with valid Polish words "małża" and "żółtaczka" the first is entirely squiggled, in the second only "żół" is (note that "taczka" is also a valid word, however "ma" and "a" are too and still they are squiggled in "małża"). In identical file with ANSI encoding "mał" and "ółtaczka" are squiggled. Also note that the context menu suggestions are garbled, e.g. for "małża" it is "ma³¿a".
Working on a fix.
Howdy! I could have sworn I've been to this blog before but after reading through some of the post I realized it's new to me. Anyways, I'm definitely delighted I found it and I'll be book-marking and checking back often!
north face jackets cheap http://uamrwbaz263.webgarden.com/
Native American cultural concerns also led to debate in the Sydney Morning Herald on the back, which I plan to either trees or line them along. Stitch vertical lines down the noise that can be a good day when that thunderstorm rolls in. <a href="http://survival-gear.info" title="survival gear">survival gear</a>