From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#49982: 27.2; ispell.el fails to find a Hunspell dictionary to use as default despite ispell-dictionary being set Date: Tue, 10 Aug 2021 19:03:07 +0300 Message-ID: <83h7fxfft0.fsf@gnu.org> References: <59517c95-6568-f646-7097-c601cc9657c9@kisaragi-hiu.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20292"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 49982@debbugs.gnu.org To: Kisaragi Hiu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 10 18:04:26 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mDUEr-0004tO-5l for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 10 Aug 2021 18:04:25 +0200 Original-Received: from localhost ([::1]:59402 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mDUEp-0002fb-L9 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 10 Aug 2021 12:04:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51320) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mDUEV-0002bs-VY for bug-gnu-emacs@gnu.org; Tue, 10 Aug 2021 12:04:06 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49002) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mDUEU-00010I-Ez for bug-gnu-emacs@gnu.org; Tue, 10 Aug 2021 12:04:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mDUEU-0002tE-6l for bug-gnu-emacs@gnu.org; Tue, 10 Aug 2021 12:04:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Aug 2021 16:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49982 X-GNU-PR-Package: emacs Original-Received: via spool by 49982-submit@debbugs.gnu.org id=B49982.162861139711055 (code B ref 49982); Tue, 10 Aug 2021 16:04:02 +0000 Original-Received: (at 49982) by debbugs.gnu.org; 10 Aug 2021 16:03:17 +0000 Original-Received: from localhost ([127.0.0.1]:60548 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mDUDl-0002sE-40 for submit@debbugs.gnu.org; Tue, 10 Aug 2021 12:03:17 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:42420) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mDUDg-0002rx-5Q for 49982@debbugs.gnu.org; Tue, 10 Aug 2021 12:03:16 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:55186) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mDUDZ-0000PN-Ly; Tue, 10 Aug 2021 12:03:05 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2122 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mDUDR-00006t-Sz; Tue, 10 Aug 2021 12:03:05 -0400 In-Reply-To: <59517c95-6568-f646-7097-c601cc9657c9@kisaragi-hiu.com> (bug-gnu-emacs@gnu.org) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:211522 Archived-At: > Date: Wed, 11 Aug 2021 00:12:06 +0900 > From: Kisaragi Hiu via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > This configuration should be everything that's needed for ispell.el to > work with Hunspell, regardless of system locale: > > (setq ispell-program-name (executable-find "hunspell") > ispell-dictionary "en_US")) > > However, when system locale (the LANG environment variable) does not > have a corresponding Hunspell dictionary, > `ispell-find-hunspell-dictionaries` returns the error "Can't find > Hunspell dictionary with a .aff affix file", despite ispell-dictionary > being set. > > ispell.el relies on Hunspell to load a default and report it, but > Hunspell just errors out if it can't find a dictionary for the system > locale. And because ispell.el is trying to get Hunspell's default > dictionary, it doesn't pass `ispell-dictionary' onto Hunspell. > > This behavior is surprising. If `ispell-dictionary` is non-nil, that > means the user has already specified their preferred dictionary, and it > should not matter that Hunspell cannot find the dictionary it would use > when a preferred dictionary isn't specified. > > It's ispell.el that needs to be fixed here because the user specifies > their preference in Emacs, and it is its job to communicate that > preference to Hunspell. > > `ispell-find-hunspell-dictionaries` should pass "-d > ${ispell-dictionary}" to Hunspell if `ispell-dictionary` is set. This > invocation: > > hunspell -d "en_US" -D /dev/null > > works as expected regardless of the system locale. Thanks for the report and the analysis. Frankly, I'm a bit wary of making the proposed change unconditionally. First, yours is an unusual use case, I think: when Hunspell is installed, the dictionary that corresponds to the locale is always installed, because otherwise Hunspell will not work reliably from the shell command line. And second, relying on the non-nil value of ispell-dictionary is fragile: the value could be a remnant from some previous invocation or from an unsuccessful customization that has nothing to do with the user's choice or his/her current intent. Moreover, if you manually set ispell-dictionary, then what would be the purpose of calling ispell-find-hunspell-dictionaries at all? So maybe we should add a new user option that would force using the value of ispell-dictionary right from the start. That would at least avoid the risk of breaking somebody else's use case. I wonder if anyone else has an opinion about this.