Bug 1262755 - [fix available] bad UTF-8 char count in pipe mode
[fix available] bad UTF-8 char count in pipe mode
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: hunspell (Show other bugs)
x86_64 Linux
medium Severity high
: rc
: ---
Assigned To: Caolan McNamara
QE Internationalization Bugs
: i18n
Depends On:
  Show dependency treegraph
Reported: 2015-09-14 05:26 EDT by jigar
Modified: 2016-11-03 20:06 EDT (History)
7 users (show)

See Also:
Fixed In Version: hunspell-1.3.2-15.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-11-03 20:06:05 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
testfile for reproducing issue (16 bytes, text/plain)
2015-09-14 05:28 EDT, jigar
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2179 normal SHIPPED_LIVE hunspell bug fix and enhancement update 2016-11-03 09:17:21 EDT

  None (edit)
Description jigar 2015-09-14 05:26:58 EDT
Description of problem: When using emacs / hunspell to spell-check a UTF-8 encoded text file, emacs chokes on some accented letters, with the error message:

Starting new Ispell process [/usr/bin/hunspell::default] ...
Spell-checking testfile-fails using hunspell with default dictionary...done
ispell-process-line: Ispell misalignment: word `occuring' point 8; probably incompatible versions

Version-Release number of selected component (if applicable): 

How reproducible: Always

Steps to Reproduce:
1.Open attached file in emacs.
2."M-x ispell" to perform a full spell check using hunspell.

Actual results: Spell check fails with error message "Ispell misalignment: word `occuring' point 8; probably incompatible versions".

Expected results: Spell check completes as expected, notes misspelled word, and offers correction suggestions.

Additional info: Extremely inconvenient bug for international users who use emacs to compose documents in multibyte languages. Such users are currently unable to spell check.
Comment 1 jigar 2015-09-14 05:28:59 EDT
Created attachment 1073139 [details]
testfile for reproducing issue

Load the test file with emacs and run the command "M-x ispell"
Comment 4 Petr Hracek 2015-09-15 06:03:03 EDT
I have to find out a fix for it.
I didn't inform upstream yet whether it is solved already.
Comment 5 Petr Hracek 2015-09-15 06:08:52 EDT
What do you have a hunspell version?
Comment 6 Petr Hracek 2015-09-15 06:27:08 EDT
I have already informed upstream about it http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21482
Comment 7 Petr Hracek 2015-09-15 06:44:13 EDT
From the upstream:

Emacs 24.5 gets the necessary information about the encoding used by
each Hunspell dictionary from the dictionaries themselves.  In
previous versions of Emacs you needed to set up
ispell-dictionary-alist manually with the correct information about

I will try to compare ispell.el between version 24.3 and 24.5 but I guess that backport is not going to be so easy.

I guess that ispell-dictionary-alist is better solution.
Comment 8 jigar 2015-09-15 07:15:31 EDT

Following is the upstream bug report for the issue:

It also contains the patches which can probably be backported to fix the issue. 

Thanks & Regards,
Jigar Raisinghani
Comment 9 Petr Hracek 2015-09-15 07:22:22 EDT
Upstream informed me that hunspell has a patch for it.

Patch for it is here https://debbugs.gnu.org/cgi/bugreport.cgi?bug=7781#31

Reassigning to hunspell.
Comment 10 Caolan McNamara 2015-09-15 09:59:25 EDT
this is in place in fedora, but not rhel
Comment 20 Satyabrata Maitra 2016-08-08 07:49:39 EDT
Hi Caolan

As per your comment #13, this bug wont be fixed in RHEL7.3. But on the contrary, I see the devel_ack is "+" as well, which ideally ensures, this bug will get fixed in RHEL7.3.

Its a bit confusing for us. Please help us and clarify a bit.

In case this bug get fixed in RHEL7.3, we need to move the relevant erratum (Comment #18) from REL_PREP to NEW_FILE, in order to let you add this bug into that erratum. Otherwise we don't need to change the errata status as of now.

Please inform.

Comment 27 errata-xmlrpc 2016-11-03 20:06:05 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.