GNU bug report logs - #25825
25.1; ispell-find-hunspell-dictionaries not working on Windows

Previous Next

Package: emacs;

Reported by: S W <sw9 <at> outlook.com>

Date: Tue, 21 Feb 2017 04:33:01 UTC

Severity: normal

Tags: moreinfo

Found in version 25.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: sw9 <at> outlook.com, 25825 <at> debbugs.gnu.org
Subject: bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows
Date: Wed, 26 Aug 2020 22:39:57 +0300
> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Wed, 26 Aug 2020 12:21:02 -0700
> Cc: sw9 <at> outlook.com, 25825 <at> debbugs.gnu.org
> 
> But for some reason, hunspell is very sensitive and will not give any
> loaded dictionary if $LANG is unset.  (IMO, very unhelpful behaviour.)

Maybe this is worth a bug report against Hunspell.  But is this really
relevant to how Hunspell is invoked from Emacs?  It certainly isn't on
Windows, because we inject LANG into the environment there.  But what
about Posix hosts?

> One idea to improve the situation on our end is to look for "Can't
> open affix or dictionary files for dictionary named 'default'." and
> raise a better error in these cases.

Fine with me.

> Or, if we want to really go out of our way, we could retry with
> "LANG=en_US.UTF-8".

That cannot fly: we cannot second-guess the user's locale, and we
shouldn't force some arbitrary locale on them.  It's basically a
mis-configured system, so signaling an error is good enough, IMO.




This bug report was last modified 4 years and 183 days ago.

Previous Next


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