GNU bug report logs - #42602
Wrong (not-)casechars value for "polish" in ispell-dictionary-base-alist

Previous Next

Full log

Message #17 received at 42602 <at> debbugs.gnu.org (full text, mbox):

From: Sebastian Urban <mrsebastianurban <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 42602 <at> debbugs.gnu.org
Subject: Re: bug#42602: Wrong (not-)casechars value for "polish" in
 ispell-dictionary-base-alist
Date: Fri, 31 Jul 2020 12:52:47 +0200

>>> I don't understand this change.  Values above octal 377 cannot be
>>> right in the above regexps, because they are supposed to be in
>>> Latin-2 encoding, which is a single-byte encoding, and so can only
>>> handle values below octal 400.  How did you come up with those
>>> values?
>>
>> Basically, C-x = on a char, which gave me octal values.
>
> This gives you the Unicode codepoint, not its Latin-2 encoding.
> They are different.

So, it would work even if I would add "\999999999", because Emacs
would not recognize and simply ignore it, which means the only reason
it worked was explicitly set encoding (iso-8859-2)?

> The database in ispell.el uses Latin-2 encodings of Polish
> characters.

As base, but before ispell.el sends the string to the Aspell it
translates it to uft-8, right?  Because that's the only difference
between my custom "pl" dictionary and value of "polish" in
ispell-dictionary-alist.

> Native MinGW builds cannot use the UTF-8 encoding.

So, with my setup (not saying that it's the best one, it's just
current one, if there is a better one I can change), for Polish lang,
I have to define local dictionary with iso-8859-2 coding?

> So, do we have a problem to solve, or can this issue be closed?

If it's a problem of MinGW, and my setup, then I guess it's not an
Emacs problem, so yes, it can be closed.


S. U.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.