bug#24435: 25.1; Problem using Hunspell

bug#24435: 25.1; Problem using Hunspell

[Dmitri Paduchikh]

Hello,

Judging from ispell.el it should work with Hunspell, so I tried to use
it. But attempts to check a word produce the following error message.

| Starting new Ispell process hunspell with ru_RU dictionary...
| hunspell release 3.1.12 or greater is required (ispell-check-version)

The latest version of Hunspell is 1.4.1 as can be seen here:
https://github.com/hunspell/hunspell/releases

As I understand, the problem arises because ispell-check-version finds
version information using regexp

"(but really Hunspell \\([0-9]+\\.[0-9\\.-]+\\)?)"

The output of hunspell -vv does not match it, hence the results.

$ hunspell -vv < /dev/null
Hunspell 1.4.0
$ 

Best regards
Dmitri Paduchikh

In GNU Emacs 25.1.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.20.9)
 of 2016-09-09 built on nocturne.localdomain

bug#24435: 25.1; Problem using Hunspell

[Noam Postavsky]

On Wed, Sep 14, 2016 at 9:24 AM, Dmitri Paduchikh <dpaduchikh@gmail.com> wrote:
> Hello,
>
> Judging from ispell.el it should work with Hunspell, so I tried to use
> it. But attempts to check a word produce the following error message.
>
> | Starting new Ispell process hunspell with ru_RU dictionary...
> | hunspell release 3.1.12 or greater is required (ispell-check-version)
>
> The latest version of Hunspell is 1.4.1 as can be seen here:
> https://github.com/hunspell/hunspell/releases
>
> As I understand, the problem arises because ispell-check-version finds
> version information using regexp
>
> "(but really Hunspell \\([0-9]+\\.[0-9\\.-]+\\)?)"
>
> The output of hunspell -vv does not match it, hence the results.
>
> $ hunspell -vv < /dev/null
> Hunspell 1.4.0

I guess older Hunspell versions printed a different string. Does it
work if you change the regexp to

"\\(?:(but really \\)?Hunspell \\([0-9]+\\.[0-9\\.-]+\\)?)?"

bug#24435: 25.1; Problem using Hunspell

[Dmitri Paduchikh]

Hello,

Noam Postavsky <npostavs@users.sourceforge.net> wrote:

> On Wed, Sep 14, 2016 at 9:24 AM, Dmitri Paduchikh <dpaduchikh@gmail.com> wrote:

>> Hello,
>>
>> Judging from ispell.el it should work with Hunspell, so I tried to use
>> it. But attempts to check a word produce the following error message.
>>
>> | Starting new Ispell process hunspell with ru_RU dictionary...
>> | hunspell release 3.1.12 or greater is required (ispell-check-version)
>>
>> The latest version of Hunspell is 1.4.1 as can be seen here:
>> https://github.com/hunspell/hunspell/releases
>>
>> As I understand, the problem arises because ispell-check-version finds
>> version information using regexp
>>
>> "(but really Hunspell \\([0-9]+\\.[0-9\\.-]+\\)?)"
>>
>> The output of hunspell -vv does not match it, hence the results.
>>
>> $ hunspell -vv < /dev/null
>> Hunspell 1.4.0

> I guess older Hunspell versions printed a different string. Does it
> work if you change the regexp to

> "\\(?:(but really \\)?Hunspell \\([0-9]+\\.[0-9\\.-]+\\)?)?"

Sadly, it does not. The immediate cause of this error message is that
regexp for ispell-program-version matches the Hunspell output. Then the
corresponding check for Ispell version produces this error. The change
shown below makes the version check pass, but another problem appears:

| Starting new Ispell process hunspell with ru_RU dictionary...
| ispell-phaf: No matching entry for ru_RU in ‘ispell-hunspell-dict-paths-alist’.
|  (ispell-parse-hunspell-affix-file)

It seems that Hunspell itself does not have any difficulty locating the
dictionary.

$ hunspell -a -d ru_RU
Hunspell 1.4.0
проверкаа
& проверкаа 3 0: проверка, проверкам, проверках

Below is the change I made to work arround the version check.

--- orig/ispell.el	2016-06-29 23:52:37.000000000 +0500
+++ ispell.el	2016-09-14 20:01:50.529079147 +0500
@@ -881,7 +881,7 @@
       ;; Get relevant version strings. Only xx.yy.... format works well
       (let (case-fold-search)
 	(setq ispell-program-version
-	      (and (search-forward-regexp "\\([0-9]+\\.[0-9\\.]+\\)" nil t)
+	      (and (search-forward-regexp "\\bIspell Version \\([0-9]+\\.[0-9\\.]+\\)" nil t)
 		   (match-string 1)))
 
 	;; Make sure these variables are (re-)initialized to the default value
@@ -897,7 +897,7 @@
 		       (match-string 1)))
 	    (setq ispell-really-hunspell
 		  (and (search-forward-regexp
-			"(but really Hunspell \\([0-9]+\\.[0-9\\.-]+\\)?)"
+			"\\bHunspell \\([0-9]+\\.[0-9-.]+\\)?"
                         nil t)
 		       (match-string 1)))))
 
@@ -907,12 +907,13 @@
 	    (ispell-minver    "3.1.12")
 	    (hunspell8-minver "1.1.6"))
 
-	(if (ispell-check-minver ispell0-minver ispell-program-version)
-	    (or (ispell-check-minver ispell-minver ispell-program-version)
-		(setq ispell-offset 0))
-	  (error "%s release %s or greater is required"
-		 ispell-program-name
-		 ispell-minver))
+	(cond ((or (null ispell-program-version)
+                   (ispell-check-minver ispell-minver ispell-program-version)))
+              ((ispell-check-minver ispell0-minver ispell-program-version)
+               (setq ispell-offset 0))
+              (:else (error "%s release %s or greater is required"
+                            ispell-program-name
+                            ispell-minver)))
 
 	(cond
 	 (ispell-really-aspell

bug#24435: 25.1; Problem using Hunspell

[Eli Zaretskii]

> From: Dmitri Paduchikh <dpaduchikh@gmail.com>
> Date: Wed, 14 Sep 2016 18:24:24 +0500
> 
> Judging from ispell.el it should work with Hunspell, so I tried to use
> it. But attempts to check a word produce the following error message.
> 
> | Starting new Ispell process hunspell with ru_RU dictionary...
> | hunspell release 3.1.12 or greater is required (ispell-check-version)
> 
> The latest version of Hunspell is 1.4.1 as can be seen here:
> https://github.com/hunspell/hunspell/releases
> 
> As I understand, the problem arises because ispell-check-version finds
> version information using regexp
> 
> "(but really Hunspell \\([0-9]+\\.[0-9\\.-]+\\)?)"
> 
> The output of hunspell -vv does not match it, hence the results.
> 
> $ hunspell -vv < /dev/null
> Hunspell 1.4.0
> $ 

They've changed the output in backward-incompatible ways.  Previous
versions responded thusly:

  @(#) International Ispell Version 3.2.06 (but really Hunspell 1.3.2)

Since this change breaks backward compatibility, does that mean
Hunspell is no longer compatible with the Ispell-like interface that
Emacs expects?

bug#24435: 25.1; Problem using Hunspell

[Eli Zaretskii]

> From: Dmitri Paduchikh <dpaduchikh@gmail.com>
> Date: Wed, 14 Sep 2016 20:33:53 +0500
> Cc: 24435@debbugs.gnu.org
> 
> > I guess older Hunspell versions printed a different string. Does it
> > work if you change the regexp to
> 
> > "\\(?:(but really \\)?Hunspell \\([0-9]+\\.[0-9\\.-]+\\)?)?"
> 
> Sadly, it does not. The immediate cause of this error message is that
> regexp for ispell-program-version matches the Hunspell output. Then the
> corresponding check for Ispell version produces this error. The change
> shown below makes the version check pass, but another problem appears:
> 
> | Starting new Ispell process hunspell with ru_RU dictionary...
> | ispell-phaf: No matching entry for ru_RU in ‘ispell-hunspell-dict-paths-alist’.
> |  (ispell-parse-hunspell-affix-file)
> 
> It seems that Hunspell itself does not have any difficulty locating the
> dictionary.
> 
> $ hunspell -a -d ru_RU
> Hunspell 1.4.0
> проверкаа
> & проверкаа 3 0: проверка, проверкам, проверках

What does your Hunspell output when invoked thus:

  $ hunspell -D

It should output all the dictionaries it has available -- that is what
ispell.el expects.  It was a long-standing bug in Hunspell that (some
versions of) it didn't, so I'm guessing that bug is still not fixed.
Look in their bug database for a patch, apply it, rebuild Hunspell,
and it should work (unless my guess is wrong and some other factor is
at work here).

> Below is the change I made to work arround the version check.

Thanks, but I think this part is too drastic:

> -	(if (ispell-check-minver ispell0-minver ispell-program-version)
> -	    (or (ispell-check-minver ispell-minver ispell-program-version)
> -		(setq ispell-offset 0))
> -	  (error "%s release %s or greater is required"
> -		 ispell-program-name
> -		 ispell-minver))
> +	(cond ((or (null ispell-program-version)
> +                   (ispell-check-minver ispell-minver ispell-program-version)))
> +              ((ispell-check-minver ispell0-minver ispell-program-version)
> +               (setq ispell-offset 0))
> +              (:else (error "%s release %s or greater is required"
> +                            ispell-program-name
> +                            ispell-minver)))

We cannot give up the test of ispell-program-version.  I suggest to do
this the other way around: if Hunspell reports version 1.4 or greater,
_then_ and only then skip the ispell-program-version test.

bug#24435: 25.1; Problem using Hunspell

[Dmitri Paduchikh]

Hello,

Eli Zaretskii <eliz@gnu.org> wrote:

>> | ispell-phaf: No matching entry for ru_RU in ‘ispell-hunspell-dict-paths-alist’.
>> |  (ispell-parse-hunspell-affix-file)
>> 
>> It seems that Hunspell itself does not have any difficulty locating the
>> dictionary.
>> 
>> $ hunspell -a -d ru_RU
>> Hunspell 1.4.0
>> проверкаа
>> & проверкаа 3 0: проверка, проверкам, проверках

> What does your Hunspell output when invoked thus:
>   $ hunspell -D

$ hunspell -D < /dev/null
Hunspell 1.4.0
$ hunspell -a -D < /dev/null
SEARCH PATH:
.::/usr/share/hunspell:/usr/share/myspell:/usr/share/myspell/dicts:/Library/Spelling:/home/dmai/.openoffice.org/3/user/wordbook:.openoffice.org2/user/wordbook:.openoffice.org2.0/user/wordbook:Library/Spelling:/opt/openoffice.org/basis3.0/share/dict/ooo:/usr/lib/openoffice.org/basis3.0/share/dict/ooo:/opt/openoffice.org2.4/share/dict/ooo:/usr/lib/openoffice.org2.4/share/dict/ooo:/opt/openoffice.org2.3/share/dict/ooo:/usr/lib/openoffice.org2.3/share/dict/ooo:/opt/openoffice.org2.2/share/dict/ooo:/usr/lib/openoffice.org2.2/share/dict/ooo:/opt/openoffice.org2.1/share/dict/ooo:/usr/lib/openoffice.org2.1/share/dict/ooo:/opt/openoffice.org2.0/share/dict/ooo:/usr/lib/openoffice.org2.0/share/dict/ooo
AVAILABLE DICTIONARIES (path is not mandatory for -d option):
/usr/share/hunspell/ru_RU
/usr/share/hunspell/en_NG
/usr/share/hunspell/en_PH
/usr/share/hunspell/en_DK
/usr/share/hunspell/en_NZ
/usr/share/hunspell/en_BS
/usr/share/hunspell/en_AU
/usr/share/hunspell/en_IE
/usr/share/hunspell/en_GB-large
/usr/share/hunspell/en_BW
/usr/share/hunspell/en_US
/usr/share/hunspell/en_CA
/usr/share/hunspell/en_HK
/usr/share/hunspell/en_NA
/usr/share/hunspell/en_GH
/usr/share/hunspell/en_BZ
/usr/share/hunspell/en_SG
/usr/share/hunspell/en_GB
/usr/share/hunspell/en_ZW
/usr/share/hunspell/en_TT
/usr/share/hunspell/en_ZA
/usr/share/hunspell/en_IN
/usr/share/hunspell/en_AG
/usr/share/hunspell/en_JM
/usr/share/myspell/dicts/ru_RU
/usr/share/myspell/dicts/en_NG
/usr/share/myspell/dicts/en_PH
/usr/share/myspell/dicts/en_DK
/usr/share/myspell/dicts/en_NZ
/usr/share/myspell/dicts/en_BS
/usr/share/myspell/dicts/en_AU
/usr/share/myspell/dicts/en_IE
/usr/share/myspell/dicts/en_GB-large
/usr/share/myspell/dicts/en_BW
/usr/share/myspell/dicts/en_US
/usr/share/myspell/dicts/en_CA
/usr/share/myspell/dicts/en_HK
/usr/share/myspell/dicts/en_NA
/usr/share/myspell/dicts/en_GH
/usr/share/myspell/dicts/en_BZ
/usr/share/myspell/dicts/en_SG
/usr/share/myspell/dicts/en_GB
/usr/share/myspell/dicts/en_ZW
/usr/share/myspell/dicts/en_TT
/usr/share/myspell/dicts/en_ZA
/usr/share/myspell/dicts/en_IN
/usr/share/myspell/dicts/en_AG
/usr/share/myspell/dicts/en_JM
LOADED DICTIONARY:
/usr/share/hunspell/ru_RU.aff
/usr/share/hunspell/ru_RU.dic
Hunspell 1.4.0
$ 

The information about dictionaries is output to stderr, and the version
string - to stdout. I have added -a to ispell-call-process inside
ispell-find-hunspell-dictionaries, re-customized ispell-program-name
(since ispell-find-hunspell-dictionaries seems to be called through its
customization setter), and the error with missing dictionaries
disappeared. Now when I try to check some word, after waiting for
several seconds I get this message:

| Starting new Ispell process hunspell with ru_RU dictionary...
| Hunspell 1.4.0 (ispell-init-process)

Subsequent attempts give such result:

| Checking spelling of ВПЕРЁД...
| Error checking word ВПЕРЁД using hunspell with ru_RU dictionary

The word seems to pass spellcheck using CLI interface.

$ echo вперёд | hunspell -a -d ru_RU
Hunspell 1.4.0
*

$ 

Best regards
Dmitri Paduchikh

bug#24435: 25.1; Problem using Hunspell

[Eli Zaretskii]

> From: Dmitri Paduchikh <dpaduchikh@gmail.com>
> Cc: npostavs@users.sourceforge.net,  24435@debbugs.gnu.org
> Date: Wed, 14 Sep 2016 22:44:18 +0500
> 
> > What does your Hunspell output when invoked thus:
> >   $ hunspell -D
> 
> $ hunspell -D < /dev/null
> Hunspell 1.4.0

That's the bug.

> Now when I try to check some word, after waiting for
> several seconds I get this message:
> 
> | Starting new Ispell process hunspell with ru_RU dictionary...
> | Hunspell 1.4.0 (ispell-init-process)
> 
> Subsequent attempts give such result:
> 
> | Checking spelling of ВПЕРЁД...
> | Error checking word ВПЕРЁД using hunspell with ru_RU dictionary
> 
> The word seems to pass spellcheck using CLI interface.
> 
> $ echo вперёд | hunspell -a -d ru_RU
> Hunspell 1.4.0
> *

You used a lower-case variant of the word in the CLI test, so the
results could be different.  What happens when you pass exactly ВПЕРЁД
in the CLI case?

Also, can you look (in 'ps' or some similar system utility) what is
the exact command line that Emacs invokes Hunspell in your case?

bug#24435: 25.1; Problem using Hunspell

[Dmitri Paduchikh]

Hello,

Eli Zaretskii <eliz@gnu.org> wrote:

>> Now when I try to check some word, after waiting for
>> several seconds I get this message:
>> 
>> | Starting new Ispell process hunspell with ru_RU dictionary...
>> | Hunspell 1.4.0 (ispell-init-process)
>> 
>> Subsequent attempts give such result:
>> 
>> | Checking spelling of ВПЕРЁД...
>> | Error checking word ВПЕРЁД using hunspell with ru_RU dictionary
>> 
>> The word seems to pass spellcheck using CLI interface.
>> 
>> $ echo вперёд | hunspell -a -d ru_RU
>> Hunspell 1.4.0
>> *

> You used a lower-case variant of the word in the CLI test, so the
> results could be different.  What happens when you pass exactly ВПЕРЁД
> in the CLI case?

No, I check lower-case word in Emacs as well. I thought that probably it
is because ispell.el converts the word to uppercase. Anyway, CLI test
with uppercase word gives the same result.

> Also, can you look (in 'ps' or some similar system utility) what is
> the exact command line that Emacs invokes Hunspell in your case?

It was

$ pgrep -a hunspell
5897 /usr/bin/hunspell  -d ru_RU -i UTF-8

After this I have added "-a" to ispell-extra-args and now it seems to be
working. Well, with all preceding arrangements. Thank you for hints.

Best regards
Dmitri Paduchikh

bug#24435: 25.1; Problem using Hunspell

[Agustin Martin]

On Wed, Sep 14, 2016 at 07:40:01PM +0300, Eli Zaretskii wrote:
> > From: Dmitri Paduchikh <dpaduchikh@gmail.com>
> > Date: Wed, 14 Sep 2016 18:24:24 +0500
> > 
> > Judging from ispell.el it should work with Hunspell, so I tried to use
> > it. But attempts to check a word produce the following error message.
> > 
> > | Starting new Ispell process hunspell with ru_RU dictionary...
> > | hunspell release 3.1.12 or greater is required (ispell-check-version)
> > 
> > The latest version of Hunspell is 1.4.1 as can be seen here:
> > https://github.com/hunspell/hunspell/releases
> > 
> > As I understand, the problem arises because ispell-check-version finds
> > version information using regexp
> > 
> > "(but really Hunspell \\([0-9]+\\.[0-9\\.-]+\\)?)"
> > 
> > The output of hunspell -vv does not match it, hence the results.
> > 
> > $ hunspell -vv < /dev/null
> > Hunspell 1.4.0
> > $ 
> 
> They've changed the output in backward-incompatible ways.  Previous
> versions responded thusly:
> 
>   @(#) International Ispell Version 3.2.06 (but really Hunspell 1.3.2)
> 
> Since this change breaks backward compatibility, does that mean
> Hunspell is no longer compatible with the Ispell-like interface that
> Emacs expects?

Hi,

I have been looking at hunspell git repo, 

https://github.com/hunspell/hunspell

That string is defined in src/tools/hunspell.cxx file (line 60,
HUNSPELL_PIPE_HEADING) and seems to still be there. No changes in it
since end of last January, and they were only formatting changes.

With hunspell-1.4.1 in Debian GNU/Linux (note that 1.4.0 version is wrong),

$ hunspell -vv < /dev/null
@(#) International Ispell Version 3.2.06 (but really Hunspell 1.4.0)

$ hunspell -a < /dev/null
@(#) International Ispell Version 3.2.06 (but really Hunspell 1.4.0)

Although by the way,

$ hunspell -va < /dev/null
Hunspell 1.4.0
$ hunspell -vva < /dev/null
Hunspell 1.4.0

Where does your hunspell come from?

Regards,

-- 
Agustin

bug#24435: 25.1; Problem using Hunspell

[Eli Zaretskii]

> From: Dmitri Paduchikh <dpaduchikh@gmail.com>
> Cc: npostavs@users.sourceforge.net,  24435@debbugs.gnu.org
> Date: Thu, 15 Sep 2016 01:10:29 +0500
> 
> > Also, can you look (in 'ps' or some similar system utility) what is
> > the exact command line that Emacs invokes Hunspell in your case?
> 
> It was
> 
> $ pgrep -a hunspell
> 5897 /usr/bin/hunspell  -d ru_RU -i UTF-8
> 
> After this I have added "-a" to ispell-extra-args and now it seems to be
> working.

How did it happen that Hunspell was invoked without the -a switch,
though?  AFAICS, ispell-start-process hard-codes the -a switch, so it
should have been invoked with it.

bug#24435: 25.1; Problem using Hunspell

[Agustin Martin]

On Thu, Sep 15, 2016 at 05:25:25PM +0300, Eli Zaretskii wrote:
> > From: Dmitri Paduchikh <dpaduchikh@gmail.com>
> > Cc: npostavs@users.sourceforge.net,  24435@debbugs.gnu.org
> > Date: Thu, 15 Sep 2016 01:10:29 +0500
> > 
> > > Also, can you look (in 'ps' or some similar system utility) what is
> > > the exact command line that Emacs invokes Hunspell in your case?
> > 
> > It was
> > 
> > $ pgrep -a hunspell
> > 5897 /usr/bin/hunspell  -d ru_RU -i UTF-8
> > 
> > After this I have added "-a" to ispell-extra-args and now it seems to be
> > working.
> 
> How did it happen that Hunspell was invoked without the -a switch,
> though?  AFAICS, ispell-start-process hard-codes the -a switch, so it
> should have been invoked with it.

I think it is ispell-call-process what is used for this particular purpose
by ispell-check-version. No -a seems used here.

-- 
Agustin

bug#24435: 25.1; Problem using Hunspell

[Eli Zaretskii]

> Date: Thu, 15 Sep 2016 17:22:01 +0200
> From: Agustin Martin <agustin6martin@gmail.com>
> Cc: Dmitri Paduchikh <dpaduchikh@gmail.com>, npostavs@users.sourceforge.net
> 
> On Thu, Sep 15, 2016 at 05:25:25PM +0300, Eli Zaretskii wrote:
> > > From: Dmitri Paduchikh <dpaduchikh@gmail.com>
> > > Cc: npostavs@users.sourceforge.net,  24435@debbugs.gnu.org
> > > Date: Thu, 15 Sep 2016 01:10:29 +0500
> > > 
> > > > Also, can you look (in 'ps' or some similar system utility) what is
> > > > the exact command line that Emacs invokes Hunspell in your case?
> > > 
> > > It was
> > > 
> > > $ pgrep -a hunspell
> > > 5897 /usr/bin/hunspell  -d ru_RU -i UTF-8
> > > 
> > > After this I have added "-a" to ispell-extra-args and now it seems to be
> > > working.
> > 
> > How did it happen that Hunspell was invoked without the -a switch,
> > though?  AFAICS, ispell-start-process hard-codes the -a switch, so it
> > should have been invoked with it.
> 
> I think it is ispell-call-process what is used for this particular purpose
> by ispell-check-version. No -a seems used here.

I think you are talking about checking the version, whereas I was
talking about how Hunspell is invoked for the spell-check itself.

bug#24435: 25.1; Problem using Hunspell

[Agustin Martin]

On Thu, Sep 15, 2016 at 07:20:09PM +0300, Eli Zaretskii wrote:
> > Date: Thu, 15 Sep 2016 17:22:01 +0200
> > From: Agustin Martin <agustin6martin@gmail.com>
> > Cc: Dmitri Paduchikh <dpaduchikh@gmail.com>, npostavs@users.sourceforge.net
> > 
> > On Thu, Sep 15, 2016 at 05:25:25PM +0300, Eli Zaretskii wrote:
> > > > From: Dmitri Paduchikh <dpaduchikh@gmail.com>
> > > > Cc: npostavs@users.sourceforge.net,  24435@debbugs.gnu.org
> > > > Date: Thu, 15 Sep 2016 01:10:29 +0500
> > > > 
> > > > > Also, can you look (in 'ps' or some similar system utility) what is
> > > > > the exact command line that Emacs invokes Hunspell in your case?
> > > > 
> > > > It was
> > > > 
> > > > $ pgrep -a hunspell
> > > > 5897 /usr/bin/hunspell  -d ru_RU -i UTF-8
> > > > 
> > > > After this I have added "-a" to ispell-extra-args and now it seems to be
> > > > working.
> > > 
> > > How did it happen that Hunspell was invoked without the -a switch,
> > > though?  AFAICS, ispell-start-process hard-codes the -a switch, so it
> > > should have been invoked with it.
> > 
> > I think it is ispell-call-process what is used for this particular purpose
> > by ispell-check-version. No -a seems used here.
> 
> I think you are talking about checking the version, whereas I was
> talking about how Hunspell is invoked for the spell-check itself.

Right. I stand corrected.

I was thinking about the reported error message and missed that you were
actually talking about the output of 

$ pgrep -a hunspell

when the hunspell process is launched.

Sorry for the noise,

-- 
Agustin

bug#24435: 25.1; Problem using Hunspell

[Dmitri Paduchikh]

Hello,

Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Dmitri Paduchikh <dpaduchikh@gmail.com>
>> Cc: npostavs@users.sourceforge.net,  24435@debbugs.gnu.org
>> Date: Thu, 15 Sep 2016 01:10:29 +0500
>> 
>> > Also, can you look (in 'ps' or some similar system utility) what is
>> > the exact command line that Emacs invokes Hunspell in your case?
>> 
>> It was
>> 
>> $ pgrep -a hunspell
>> 5897 /usr/bin/hunspell  -d ru_RU -i UTF-8
>> 
>> After this I have added "-a" to ispell-extra-args and now it seems to be
>> working.

> How did it happen that Hunspell was invoked without the -a switch,
> though?  AFAICS, ispell-start-process hard-codes the -a switch, so it
> should have been invoked with it.

With ispell-extra-args being empty, the eventual form to start Hunspell is

* make-process(:name "ispell" :buffer nil :command ("hunspell" "-a" ""
  "-d" "ru_RU" "-i" "UTF-8"))

However right after evaluation of this form pgrep shows this:

$ pgrep -a hunspell
6310 /usr/bin/hunspell  -d ru_RU -i UTF-8
$ tr \\0 \\n < /proc/6310/cmdline | cat -n
     1	/usr/bin/hunspell
     2	
     3	-d
     4	ru_RU
     5	-i
     6	UTF-8
$ 

Best regards
Dmitri Paduchikh

bug#24435: 25.1; Problem using Hunspell

[Dmitri Paduchikh]

Hello,

Agustin Martin <agustin6martin@gmail.com> wrote:

> Hi,

> I have been looking at hunspell git repo, 

> https://github.com/hunspell/hunspell

> That string is defined in src/tools/hunspell.cxx file (line 60,
> HUNSPELL_PIPE_HEADING) and seems to still be there. No changes in it
> since end of last January, and they were only formatting changes.

> With hunspell-1.4.1 in Debian GNU/Linux (note that 1.4.0 version is wrong),

> $ hunspell -vv < /dev/null
> @(#) International Ispell Version 3.2.06 (but really Hunspell 1.4.0)

> $ hunspell -a < /dev/null
> @(#) International Ispell Version 3.2.06 (but really Hunspell 1.4.0)

> Although by the way,

> $ hunspell -va < /dev/null
> Hunspell 1.4.0
> $ hunspell -vva < /dev/null
> Hunspell 1.4.0

> Where does your hunspell come from?

Mine is from Arch Linux.
https://www.archlinux.org/packages/extra/x86_64/hunspell/

Best regards
Dmitri Paduchikh

bug#24435: 25.1; Problem using Hunspell

[Eli Zaretskii]

> From: Dmitri Paduchikh <dpaduchikh@gmail.com>
> Cc: npostavs@users.sourceforge.net,  24435@debbugs.gnu.org
> Date: Fri, 16 Sep 2016 01:59:58 +0500
> 
> > How did it happen that Hunspell was invoked without the -a switch,
> > though?  AFAICS, ispell-start-process hard-codes the -a switch, so it
> > should have been invoked with it.
> 
> With ispell-extra-args being empty, the eventual form to start Hunspell is
> 
> * make-process(:name "ispell" :buffer nil :command ("hunspell" "-a" ""
>   "-d" "ru_RU" "-i" "UTF-8"))
> 
> However right after evaluation of this form pgrep shows this:
> 
> $ pgrep -a hunspell
> 6310 /usr/bin/hunspell  -d ru_RU -i UTF-8
> $ tr \\0 \\n < /proc/6310/cmdline | cat -n
>      1	/usr/bin/hunspell
>      2	
>      3	-d
>      4	ru_RU
>      5	-i
>      6	UTF-8
> $ 

Does it mean hunspell is a shell script, which omits the -a when it
invokes the actual program?  How else to explain the fact that -a
disappears?

bug#24435: 25.1; Problem using Hunspell

[Dmitri Paduchikh]

Hello,

Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Dmitri Paduchikh <dpaduchikh@gmail.com>
>> Cc: npostavs@users.sourceforge.net,  24435@debbugs.gnu.org
>> Date: Fri, 16 Sep 2016 01:59:58 +0500
>> 
>> > How did it happen that Hunspell was invoked without the -a switch,
>> > though?  AFAICS, ispell-start-process hard-codes the -a switch, so it
>> > should have been invoked with it.
>> 
>> With ispell-extra-args being empty, the eventual form to start Hunspell is
>> 
>> * make-process(:name "ispell" :buffer nil :command ("hunspell" "-a" ""
>>   "-d" "ru_RU" "-i" "UTF-8"))
>> 
>> However right after evaluation of this form pgrep shows this:
>> 
>> $ pgrep -a hunspell
>> 6310 /usr/bin/hunspell  -d ru_RU -i UTF-8
>> $ tr \\0 \\n < /proc/6310/cmdline | cat -n
>>      1        /usr/bin/hunspell
>>      2        
>>      3        -d
>>      4        ru_RU
>>      5        -i
>>      6        UTF-8
>> $ 

> Does it mean hunspell is a shell script, which omits the -a when it
> invokes the actual program?  How else to explain the fact that -a
> disappears?

You are right. It is my own script which I wrote away back with some
obscure purpose and did not remove.

$ cat `which hunspell`
#!/bin/sh
shift
exec /usr/bin/hunspell "$@"

After removing this script, unmodified ispell.el works as expected.
Sorry for false alarm.

Best regards
Dmitri Paduchikh

bug#24435: 25.1; Problem using Hunspell

[Eli Zaretskii]

> From: Dmitri Paduchikh <dpaduchikh@gmail.com>
> Cc: npostavs@users.sourceforge.net,  24435@debbugs.gnu.org
> Date: Fri, 16 Sep 2016 13:06:59 +0500
> 
> >> $ pgrep -a hunspell
> >> 6310 /usr/bin/hunspell  -d ru_RU -i UTF-8
> >> $ tr \\0 \\n < /proc/6310/cmdline | cat -n
> >>      1        /usr/bin/hunspell
> >>      2        
> >>      3        -d
> >>      4        ru_RU
> >>      5        -i
> >>      6        UTF-8
> >> $ 
> 
> > Does it mean hunspell is a shell script, which omits the -a when it
> > invokes the actual program?  How else to explain the fact that -a
> > disappears?
> 
> You are right. It is my own script which I wrote away back with some
> obscure purpose and did not remove.
> 
> $ cat `which hunspell`
> #!/bin/sh
> shift
> exec /usr/bin/hunspell "$@"
> 
> After removing this script, unmodified ispell.el works as expected.

Thanks, I'm therefore closing this bug report.