GNU bug report logs -
#24435
25.1; Problem using Hunspell
Previous Next
Reported by: Dmitri Paduchikh <dpaduchikh <at> gmail.com>
Date: Wed, 14 Sep 2016 13:27:01 UTC
Severity: normal
Found in version 25.1
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 24435 in the body.
You can then email your comments to 24435 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24435
; Package
emacs
.
(Wed, 14 Sep 2016 13:27:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Dmitri Paduchikh <dpaduchikh <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Wed, 14 Sep 2016 13:27:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24435
; Package
emacs
.
(Wed, 14 Sep 2016 13:48:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 24435 <at> debbugs.gnu.org (full text, mbox):
On Wed, Sep 14, 2016 at 9:24 AM, Dmitri Paduchikh <dpaduchikh <at> 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\\.-]+\\)?)?"
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24435
; Package
emacs
.
(Wed, 14 Sep 2016 15:35:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 24435 <at> debbugs.gnu.org (full text, mbox):
Hello,
Noam Postavsky <npostavs <at> users.sourceforge.net> wrote:
> On Wed, Sep 14, 2016 at 9:24 AM, Dmitri Paduchikh <dpaduchikh <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24435
; Package
emacs
.
(Wed, 14 Sep 2016 16:41:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 24435 <at> debbugs.gnu.org (full text, mbox):
> From: Dmitri Paduchikh <dpaduchikh <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24435
; Package
emacs
.
(Wed, 14 Sep 2016 16:58:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 24435 <at> debbugs.gnu.org (full text, mbox):
> From: Dmitri Paduchikh <dpaduchikh <at> gmail.com>
> Date: Wed, 14 Sep 2016 20:33:53 +0500
> Cc: 24435 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24435
; Package
emacs
.
(Wed, 14 Sep 2016 17:45:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 24435 <at> debbugs.gnu.org (full text, mbox):
Hello,
Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24435
; Package
emacs
.
(Wed, 14 Sep 2016 18:51:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 24435 <at> debbugs.gnu.org (full text, mbox):
> From: Dmitri Paduchikh <dpaduchikh <at> gmail.com>
> Cc: npostavs <at> users.sourceforge.net, 24435 <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24435
; Package
emacs
.
(Wed, 14 Sep 2016 20:11:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 24435 <at> debbugs.gnu.org (full text, mbox):
Hello,
Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24435
; Package
emacs
.
(Thu, 15 Sep 2016 13:42:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 24435 <at> debbugs.gnu.org (full text, mbox):
On Wed, Sep 14, 2016 at 07:40:01PM +0300, Eli Zaretskii wrote:
> > From: Dmitri Paduchikh <dpaduchikh <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24435
; Package
emacs
.
(Thu, 15 Sep 2016 14:26:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 24435 <at> debbugs.gnu.org (full text, mbox):
> From: Dmitri Paduchikh <dpaduchikh <at> gmail.com>
> Cc: npostavs <at> users.sourceforge.net, 24435 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24435
; Package
emacs
.
(Thu, 15 Sep 2016 15:23:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 24435 <at> debbugs.gnu.org (full text, mbox):
On Thu, Sep 15, 2016 at 05:25:25PM +0300, Eli Zaretskii wrote:
> > From: Dmitri Paduchikh <dpaduchikh <at> gmail.com>
> > Cc: npostavs <at> users.sourceforge.net, 24435 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24435
; Package
emacs
.
(Thu, 15 Sep 2016 16:21:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 24435 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 15 Sep 2016 17:22:01 +0200
> From: Agustin Martin <agustin6martin <at> gmail.com>
> Cc: Dmitri Paduchikh <dpaduchikh <at> gmail.com>, npostavs <at> users.sourceforge.net
>
> On Thu, Sep 15, 2016 at 05:25:25PM +0300, Eli Zaretskii wrote:
> > > From: Dmitri Paduchikh <dpaduchikh <at> gmail.com>
> > > Cc: npostavs <at> users.sourceforge.net, 24435 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24435
; Package
emacs
.
(Thu, 15 Sep 2016 17:37:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 24435 <at> debbugs.gnu.org (full text, mbox):
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 <at> gmail.com>
> > Cc: Dmitri Paduchikh <dpaduchikh <at> gmail.com>, npostavs <at> users.sourceforge.net
> >
> > On Thu, Sep 15, 2016 at 05:25:25PM +0300, Eli Zaretskii wrote:
> > > > From: Dmitri Paduchikh <dpaduchikh <at> gmail.com>
> > > > Cc: npostavs <at> users.sourceforge.net, 24435 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24435
; Package
emacs
.
(Thu, 15 Sep 2016 21:01:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 24435 <at> debbugs.gnu.org (full text, mbox):
Hello,
Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Dmitri Paduchikh <dpaduchikh <at> gmail.com>
>> Cc: npostavs <at> users.sourceforge.net, 24435 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24435
; Package
emacs
.
(Thu, 15 Sep 2016 21:43:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 24435 <at> debbugs.gnu.org (full text, mbox):
Hello,
Agustin Martin <agustin6martin <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24435
; Package
emacs
.
(Fri, 16 Sep 2016 06:30:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 24435 <at> debbugs.gnu.org (full text, mbox):
> From: Dmitri Paduchikh <dpaduchikh <at> gmail.com>
> Cc: npostavs <at> users.sourceforge.net, 24435 <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24435
; Package
emacs
.
(Fri, 16 Sep 2016 08:08:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 24435 <at> debbugs.gnu.org (full text, mbox):
Hello,
Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Dmitri Paduchikh <dpaduchikh <at> gmail.com>
>> Cc: npostavs <at> users.sourceforge.net, 24435 <at> 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
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Fri, 16 Sep 2016 08:35:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Dmitri Paduchikh <dpaduchikh <at> gmail.com>
:
bug acknowledged by developer.
(Fri, 16 Sep 2016 08:35:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 24435-done <at> debbugs.gnu.org (full text, mbox):
> From: Dmitri Paduchikh <dpaduchikh <at> gmail.com>
> Cc: npostavs <at> users.sourceforge.net, 24435 <at> 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.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 14 Oct 2016 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 8 years and 251 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.