Pavel Sanda wrote:
> Jürgen Spitzmüller wrote:
> > > Hunspell and Apples native spell checker both "like" it. :)
> >
> > OK. I'll commit this if Pavel gives me OK.
>
> go for it.
> pavel
Done (r37946).
Jürgen
Jürgen Spitzmüller wrote:
> > Hunspell and Apples native spell checker both "like" it. :)
>
> OK. I'll commit this if Pavel gives me OK.
go for it.
pavel
Stephan Witt wrote:
> > AFAIK Aspell has no proper support for composites with hyphens. It just
> > cannot deal with hyphens in input, as it were.
>
> Ok, it shouldn't propose it then perhaps.
Yes.
> > Of course we can make Aspell ignore the hyphens, but IMHO this does not
> > really solve the
Am 15.03.2011 um 12:12 schrieb Jürgen Spitzmüller:
> Stephan Witt wrote:
>> One strange observation I've made: when using Aspell it suggests
>> "key-bindings" as one possible replacement of "keybindings". If I choose
>> it it remains marked with the misspelled line.
>
> AFAIK Aspell has no proper
Le 15/03/2011 12:20, Jürgen Spitzmüller a écrit :
The intent is that a letter is part of a word, but a character maybe a
letter or punctuation. Of course, it is worth auditing the code to see
how it is used.
I see. So making NOBREAKDASH isLetter() is correct given the assumptions I
outlined, is
Jean-Marc Lasgouttes wrote:
> > Another version. It looks sensible to me to make NOBREAKDASH isLetter(),
> > as far as the use of this variable is concerned.
> >
> > (the description of it is not very clear, especially the differentiation
> > from isChar())
>
> The intent is that a letter is part
Stephan Witt wrote:
> One strange observation I've made: when using Aspell it suggests
> "key-bindings" as one possible replacement of "keybindings". If I choose
> it it remains marked with the misspelled line.
AFAIK Aspell has no proper support for composites with hyphens. It just cannot
deal wi
Le 15/03/2011 10:59, Jürgen Spitzmüller a écrit :
Jürgen Spitzmüller wrote:
I propose the attached patch (this is the second option).
Another version. It looks sensible to me to make NOBREAKDASH isLetter(), as
far as the use of this variable is concerned.
(the description of it is not very cl
Am 15.03.2011 um 10:59 schrieb Jürgen Spitzmüller:
> Jürgen Spitzmüller wrote:
>> I propose the attached patch (this is the second option).
>
> Another version. It looks sensible to me to make NOBREAKDASH isLetter(), as
> far as the use of this variable is concerned.
>
> (the description of it
Jürgen Spitzmüller wrote:
> I propose the attached patch (this is the second option).
Another version. It looks sensible to me to make NOBREAKDASH isLetter(), as
far as the use of this variable is concerned.
(the description of it is not very clear, especially the differentiation from
isChar())
Jürgen Spitzmüller wrote:
> So my question is, should we
>
> * limit the change to the hunspell checker only, which means that we set up
> an extra isWordSeparator function (or an option) for the spellchecker?
>
> * treat hard hyphens not as word separators in general, i.e. ditch the
> canHandl
Stephan Witt wrote:
> * make it a property of the language? Add a list of characters to include
> in words? We have to add this anyway to drop the escape chars field from
> spell checker settings. Give the spell checker backend some control over
> this list - aspell e. g. can remove the dash from i
Am 08.03.2011 um 18:56 schrieb Jürgen Spitzmüller:
> IIRC somebody already brought up this issue some time back.
JMarcs mail from 2011-02-02 with subject "Spell checking and breaking words".
Yes, we should do something about this.
> Hunspell can check both complex composites constructed with (h
IIRC somebody already brought up this issue some time back.
Hunspell can check both complex composites constructed with (hard) hyphens (as
in "fifty-year-old chap") and, more interestingly, "elliptical" or "fractal"
composites who use a hard hyphen in order to refer to a "shared" morpheme in a
14 matches
Mail list logo
