Bug 1262755

Summary: [fix available] bad UTF-8 char count in pipe mode
Product: Red Hat Enterprise Linux 7 Reporter: jigar <jraising>
Component: hunspellAssignee: Caolan McNamara <caolanm>
Status: CLOSED ERRATA QA Contact: QE Internationalization Bugs <qe-i18n-bugs>
Severity: high Docs Contact:
Priority: medium    
Version: 7.1CC: caolanm, jraising, kkrothap, ksrot, paulds, phracek, smaitra
Target Milestone: rcKeywords: i18n
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: hunspell-1.3.2-15.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-04 00:06:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
testfile for reproducing issue none

Description jigar 2015-09-14 09:26:58 UTC 
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 09:28:59 UTC 
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 10:03:03 UTC 
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 10:08:52 UTC 
What do you have a hunspell version?
Comment 6 Petr Hracek 2015-09-15 10:27:08 UTC 
I have already informed upstream about it http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21482
Comment 7 Petr Hracek 2015-09-15 10:44:13 UTC 
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
encoding.

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 11:15:31 UTC 
Hi,

Following is the upstream bug report for the issue:
 
https://bugzilla.redhat.com/show_bug.cgi?id=915448

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 11:22:22 UTC 
Upstream informed me that hunspell has a patch for it.
http://sourceforge.net/p/hunspell/bugs/185/

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 13:59:25 UTC 
this is in place in fedora, but not rhel
Comment 20 Satyabrata Maitra 2016-08-08 11:49:39 UTC 
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.

Regards
Satya
Comment 27 errata-xmlrpc 2016-11-04 00:06:05 UTC 
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.

https://rhn.redhat.com/errata/RHBA-2016-2179.html