bug#61190: 28.2; ispell personal dictionary location for hunspell engine

bug#61190: 28.2; ispell personal dictionary location for hunspell engine

[O G]

[-- Attachment #1: Type: text/plain, Size: 6005 bytes --]

The ispell package in Emacs is not using the user-specified location of
the personal dictionary for hunspell.

In particular, neither of these two settings are being respected:

(setq ispell-personal-directory "/c/Users/xxxx/.hunspell_en_US")
(setq ispell-cmd-args "-p /c/Users/xxxx/.hunspell_en_US")

Instead, it appears that ispell is hardwired to use the file
%USERPROFILE%hunspell_en_US regardless of whether or not the user has
specified another choice for their personal dictionary.

Note that a file named %USERPROFILE%hunspell_en_US is being created at
the save prompt when adding a new spelling regardless of whether or not
a file named .hunspell_en_US already exists in the user's home directory
(the default file path for a personal directory) and that the Windows
macro %USERPROFILE% is not being properly expanded either (so it becomes
part of the dictionary name in unexpanded form).

Hunspell is the latest version (1.7.2) installed from the MINGW64 repository
in the MYSYS2 project.  It is otherwise working just fine with Emacs
using the following two settings:

(setq ispell-program-name "hunspell")
(setq ispell-local-dictionary "en_US")

Note that the HOME variable is set in my Emacs init file and points
to C:/Users/xxxx/

A comment in this stack exchange post suggests others may be
experiencing this issue as well:

https://emacs.stackexchange.com/questions/58844/where-is-personal-dictionary-for-ispell-located

---------------------------------------------------------------

In GNU Emacs 28.2 (build 2, x86_64-w64-mingw32)
 of 2022-10-11 built on fv-az365-328
Repository revision: b35f9af313a5d5c42988eb5a7751209b4234a67e
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 10.0.22621
System Description: Microsoft Windows 10 Pro (v10.0.2009.22621.1105)

Configured using:
 'configure --prefix=/mingw64 --host=x86_64-w64-mingw32
 --build=x86_64-w64-mingw32 --with-modules --without-dbus
 --without-compress-install --with-native-compilation
 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe'
 CPPFLAGS=-D__USE_MINGW_ANSI_STDIO=1 LDFLAGS=-pipe'

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LIBXML2 MODULES NATIVE_COMP NOTIFY
W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XPM
ZLIB

Important settings:
  value of $LANG: en_US
  locale-coding-system: cp1252

Major mode: Lisp Interaction

Minor modes in effect:
  TeX-PDF-mode: t
  TeX-source-correlate-mode: t
  global-corfu-mode: t
  corfu-mode: t
  all-the-icons-completion-mode: t
  marginalia-mode: t
  savehist-mode: t
  vertico-multiform-mode: t
  vertico-mode: t
  override-global-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  global-prettify-symbols-mode: t
  prettify-symbols-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
c:/Users/xxxx/.emacs.d/elpa/hydra-0.15.0/lv hides
c:/Users/xxxx/.emacs.d/elpa/lv-20200507.1518/lv

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived gnus-util rmail rmail-loaddefs
text-property-search mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mule-util time-date aide tex crm texmathp le-thesaurus
request mailheader autorevert filenotify mail-utils foldout noutline
outline corfu orderless all-the-icons-completion all-the-icons
all-the-icons-faces data-material data-weathericons data-octicons
data-fileicons data-faicons data-alltheicons marginalia compat compat-29
savehist vertico-multiform vertico-posframe posframe vertico
use-package-bind-key bind-key easy-mmode ryo-modal org-macs format-spec
avy expand-region text-mode-expansions er-basic-expansions thingatpt
expand-region-core expand-region-custom two-column hydra lv
disable-mouse edmacro kmacro smart-mode-line-powerline-theme powerline
comp comp-cstr warnings rx powerline-separators ring color
powerline-themes smart-mode-line advice rich-minority zenburn-theme loop
ht s dash cl-extra help-mode use-package-ensure use-package-core
finder-inf cus-edit pp cus-load wid-edit server tex-site epg rfc6068
epg-config gnu-elpa-keyring-update info package browse-url url url-proxy
url-privacy url-expand url-methods url-history url-cookie url-domsuf
url-util mailcap url-handlers url-parse auth-source cl-seq eieio
eieio-core cl-macs eieio-loaddefs password-cache json subr-x map
url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel dos-w32 ls-lisp disp-table
term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice
button loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads w32notify w32 multi-tty
make-network-process native-compile emacs)

Memory information:
((conses 16 398612 190497)
 (symbols 48 23253 131)
 (strings 32 115775 27414)
 (string-bytes 1 3416306)
 (vectors 16 35445)
 (vector-slots 8 732330 252268)
 (floats 8 565 625)
 (intervals 56 363 174)
 (buffers 992 11))

[-- Attachment #2: Type: text/html, Size: 6687 bytes --]

bug#61190: 28.2; ispell personal dictionary location for hunspell engine

[Eli Zaretskii]

> From: O G <opngid@gmail.com>
> Date: Mon, 30 Jan 2023 19:53:19 -0500
> 
> The ispell package in Emacs is not using the user-specified location of
> the personal dictionary for hunspell.
> 
> In particular, neither of these two settings are being respected:
> 
> (setq ispell-personal-directory "/c/Users/xxxx/.hunspell_en_US")
> (setq ispell-cmd-args "-p /c/Users/xxxx/.hunspell_en_US")

These are incorrect settings: the native Windows build of Emacs
doesn't understand the MSYS /c/foo/bar notation.  Please use the
native Windows format "c:/Users/xxx/" or "C:\\Users\\xxx\\" instead
(both should work, but backslashes need to be escaped in Emacs
strings).

> Instead, it appears that ispell is hardwired to use the file
> %USERPROFILE%hunspell_en_US regardless of whether or not the user has
> specified another choice for their personal dictionary.
> 
> Note that a file named %USERPROFILE%hunspell_en_US is being created at
> the save prompt when adding a new spelling regardless of whether or not
> a file named .hunspell_en_US already exists in the user's home directory
> (the default file path for a personal directory) and that the Windows
> macro %USERPROFILE% is not being properly expanded either (so it becomes
> part of the dictionary name in unexpanded form).
> 
> Hunspell is the latest version (1.7.2) installed from the MINGW64 repository
> in the MYSYS2 project.  It is otherwise working just fine with Emacs
> using the following two settings:

Does it work for you as expected if you invoke Hunspell from the shell
prompt like this:

  hunspell -d en_US -p c:/Users/xxx/.hunspell_en_US SOME-FILE

(which starts Hunspell with its own text-mode user interface), and
then use the 'i' command inside Hunspell to save some words in the
personal dictionary?  (I presume that your Hunspell supports the
interactive invocation like above.)  If that doesn't save in the
correct file either, then it's a Hunspell bug, and you should report
it to the folks who develop Hunspell or those who produced the Windows
port you are using.  Because all Emacs does when you set
ispell-personal-directory is to invoke Hunspell with the "-p PDICT"
command-line argument.  If you have Process Explorer installed, you
should be able to verify that Hunspell is indeed invoked with the -p
option as above, and if that is so, then the part of Emacs and
ispell.el works correctly, and the problem is in Hunspell itself.

bug#61190: 28.2; ispell personal dictionary location for hunspell engine

[Eli Zaretskii]

> Cc: 61190@debbugs.gnu.org
> Date: Tue, 31 Jan 2023 15:47:30 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> Does it work for you as expected if you invoke Hunspell from the shell
> prompt like this:
> 
>   hunspell -d en_US -p c:/Users/xxx/.hunspell_en_US SOME-FILE
> 
> (which starts Hunspell with its own text-mode user interface), and
> then use the 'i' command inside Hunspell to save some words in the
> personal dictionary?  (I presume that your Hunspell supports the
> interactive invocation like above.)  If that doesn't save in the
> correct file either, then it's a Hunspell bug, and you should report
> it to the folks who develop Hunspell or those who produced the Windows
> port you are using.  Because all Emacs does when you set
> ispell-personal-directory is to invoke Hunspell with the "-p PDICT"
> command-line argument.  If you have Process Explorer installed, you
> should be able to verify that Hunspell is indeed invoked with the -p
> option as above, and if that is so, then the part of Emacs and
> ispell.el works correctly, and the problem is in Hunspell itself.

I looked into the Hunspell's sources, and I think I know why this
happens.  Hunspell has a peculiar logic when looking for the personal
dictionary.  The outcome of that peculiar logic is that if Hunspell is
invoked with "-p PDICT" command-line argument, and PDICT is an
absolute file name, that file must already exist, or else Hunspell
will decide it cannot use it.  And Emacs always invokes Hunspell with
an absolute file name of the personal dictionary.

This is arguably a bug in Hunspell, but a workaround is to create an
empty file at the location where you want the personal dictionary to
be, and then restart the speller.

bug#61190: 28.2; ispell personal dictionary location for hunspell engine

[Eli Zaretskii]

[Please use Reply All to reply, to keep the bug tracker CC'ed.]

> From: O G <opngid@gmail.com>
> Date: Tue, 31 Jan 2023 17:57:44 -0500
> 
> > This is arguably a bug in Hunspell, but a workaround is to create an
> > empty file at the location where you want the personal dictionary to
> > be, and then restart the speller.
> 
> I did try this before filing the bug report because I also wondered about whether or not the personal dictionary
> file needs to exist before saving a new word to it.  
> 
> This time around I tested by setting the ispell-local-dictionary variable, and then the ispell-cmd-args variable,
> by using in each instance the escaped backslash form of the absolute file path
> (C:\\Users\xxxx\.hunspell_en_US), which I created beforehand as an empty file.
   ^^^^^^^^^^^^^^^^^^^^^^^
If the above is the literal value you tried, it is again incorrect:
each backslash should be doubled.  If you did double them all, or used
forward slashes, then there's a different bug in your version of
Hunspell; it worked for me once I understood the problem.

Did you veryfy that Hunspell is invoked by Emacs with the correct -p
switch?

bug#61190: 28.2; ispell personal dictionary location for hunspell engine

[O G]

[-- Attachment #1: Type: text/plain, Size: 1658 bytes --]

On Tue, Jan 31, 2023 at 10:35 PM Eli Zaretskii <eliz@gnu.org> wrote:

> [Please use Reply All to reply, to keep the bug tracker CC'ed.]
>
> > > This is arguably a bug in Hunspell, but a workaround is to create an
> > > empty file at the location where you want the personal dictionary to
> > > be, and then restart the speller.
>
> > This time around I tested by setting the ispell-local-dictionary
> variable, and then the ispell-cmd-args variable,
> > by using in each instance the escaped backslash form of the absolute
> file path
> > (C:\\Users\xxxx\.hunspell_en_US), which I created beforehand as an empty
> file.
>    ^^^^^^^^^^^^^^^^^^^^^^

If the above is the literal value you tried, it is again incorrect:
> each backslash should be doubled.  If you did double them all, or used

forward slashes,


Indeed I had doubled them in my emacs init file and used backslashes ...
that was a typo above.


> then there's a different bug in your version of
> Hunspell; it worked for me once I understood the problem.
>
> Did you veryfy that Hunspell is invoked by Emacs with the correct -p
> switch?
>

I just checked process explorer and obtained the following command line
args:

c:\msys64\mingw64\bin\hunspell.exe -a "" -d en_US -i UTF-8

This did not change regardless of what string I used for ispell-cmd-args in
my emacs init file.  I tried first "-p C:\\Users\\xxxx\\.hunspell_en_US,"
under the assumption that ispell would append this to the existing default
set of cmd args, after creating an empty .hunspell_en_US file in my home
directory, and then tried setting it to

"-d en_US -i UTF-8 -p C:\\Users\\xxxx\\.hunspell_en_US"

again to no avail.

[-- Attachment #2: Type: text/html, Size: 2628 bytes --]

bug#61190: 28.2; ispell personal dictionary location for hunspell engine

[Eli Zaretskii]

> From: O G <opngid@gmail.com>
> Date: Wed, 1 Feb 2023 00:58:56 -0500
> Cc: 61190@debbugs.gnu.org
> 
>  Did you veryfy that Hunspell is invoked by Emacs with the correct -p
>  switch?
> 
> I just checked process explorer and obtained the following command line args:
> 
> c:\msys64\mingw64\bin\hunspell.exe -a "" -d en_US -i UTF-8
> 
> This did not change regardless of what string I used for ispell-cmd-args in my emacs init file.  I tried first "-p
> C:\\Users\\xxxx\\.hunspell_en_US," under the assumption that ispell would append this to the existing default
> set of cmd args, after creating an empty .hunspell_en_US file in my home directory, and then tried setting it
> to
> 
> "-d en_US -i UTF-8 -p C:\\Users\\xxxx\\.hunspell_en_US"
> 
> again to no avail.

Please be sure you are testing this correctly.  Here's a step by step
procedure starting from "emacs -Q":

  emacs -Q
  M-: (setq ispell-program-name "hunspell") RET
  M-: (setq ispell-personal-dictionary "C:/Users/xxxx/.hunspell_en_US") RET

Now go to some word in *scratch* and type M-$.

Then look with Process Explorer how Emacs invoked Hunspell.

When I do the above, I clearly see the "-p PDICT" command-line
arguments with which Emacs invokes Hunspell.  I made a point of
testing this on Windows with Emacs 28.2, which is what you have, and
it worked for me.

If the above procedure works for you, please see what you are doing
differently in your "normal" Emacs sessions.  In any case, using
ispell-cmd-args is not the recommended method; you should instead
customize the variable ispell-personal-dictionary, which is provided
for this purpose, and customize it before starting the spell-checker,
or restart the spell-checker with "M-x ispell-change-dictionary" after
customizing.

bug#61190: 28.2; ispell personal dictionary location for hunspell engine

[Juri Linkov]

> I looked into the Hunspell's sources, and I think I know why this
> happens.  Hunspell has a peculiar logic when looking for the personal
> dictionary.  The outcome of that peculiar logic is that if Hunspell is
> invoked with "-p PDICT" command-line argument, and PDICT is an
> absolute file name, that file must already exist, or else Hunspell
> will decide it cannot use it.  And Emacs always invokes Hunspell with
> an absolute file name of the personal dictionary.
>
> This is arguably a bug in Hunspell, but a workaround is to create an
> empty file at the location where you want the personal dictionary to
> be, and then restart the speller.

This bug exists even on GNU/Linux, so requires such customization:

  (unless (file-exists-p "~/.hunspell")
    (shell-command "touch ~/.hunspell"))
  (setq ispell-personal-dictionary "~/.hunspell")

bug#61190: 28.2; ispell personal dictionary location for hunspell engine

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: opngid@gmail.com,  61190@debbugs.gnu.org
> Date: Wed, 01 Feb 2023 19:58:17 +0200
> 
> > I looked into the Hunspell's sources, and I think I know why this
> > happens.  Hunspell has a peculiar logic when looking for the personal
> > dictionary.  The outcome of that peculiar logic is that if Hunspell is
> > invoked with "-p PDICT" command-line argument, and PDICT is an
> > absolute file name, that file must already exist, or else Hunspell
> > will decide it cannot use it.  And Emacs always invokes Hunspell with
> > an absolute file name of the personal dictionary.
> >
> > This is arguably a bug in Hunspell, but a workaround is to create an
> > empty file at the location where you want the personal dictionary to
> > be, and then restart the speller.
> 
> This bug exists even on GNU/Linux, so requires such customization:
> 
>   (unless (file-exists-p "~/.hunspell")
>     (shell-command "touch ~/.hunspell"))
>   (setq ispell-personal-dictionary "~/.hunspell")

Yes, the code which does that in Hunspell is not Windows-specific.

bug#61190: 28.2; ispell personal dictionary location for hunspell engine

[O G]

[-- Attachment #1: Type: text/plain, Size: 1413 bytes --]

On Wed, Feb 1, 2023 at 7:30 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: O G <opngid@gmail.com>
> > Date: Wed, 1 Feb 2023 00:58:56 -0500
> > Cc: 61190@debbugs.gnu.org
> >
> >Please be sure you are testing this correctly.  Here's a step by step
> >procedure starting from "emacs -Q":
>
> >  emacs -Q
> >  M-: (setq ispell-program-name "hunspell") RET
> >  M-: (setq ispell-personal-dictionary "C:/Users/xxxx/.hunspell_en_US")
> RET
>
> > Now go to some word in *scratch* and type M-$.
>
> > Then look with Process Explorer how Emacs invoked Hunspell.
>
> >When I do the above, I clearly see the "-p PDICT" command-line
> >arguments with which Emacs invokes Hunspell.  I made a point of
> >testing this on Windows with Emacs 28.2, which is what you have, and
> >it worked for me.
>

Thanks for the detailed suggestions -- it now works.

From what I can tell, the issue was the double backslashes not being
accepted
in the file path for the hunspell personal dictionary.


> If the above procedure works for you, please see what you are doing
> differently in your "normal" Emacs sessions.  In any case, using
> ispell-cmd-args is not the recommended method; you should instead
> customize the variable ispell-personal-dictionary, which is provided
> for this purpose, and customize it before starting the spell-checker,
> or restart the spell-checker with "M-x ispell-change-dictionary" after
> customizing.
>

[-- Attachment #2: Type: text/html, Size: 2214 bytes --]

bug#61190: 28.2; ispell personal dictionary location for hunspell engine

[Eli Zaretskii]

> From: O G <opngid@gmail.com>
> Date: Sat, 11 Feb 2023 12:07:36 -0500
> Cc: 61190@debbugs.gnu.org
> 
>  >  emacs -Q
>  >  M-: (setq ispell-program-name "hunspell") RET
>  >  M-: (setq ispell-personal-dictionary "C:/Users/xxxx/.hunspell_en_US") RET
> 
>  > Now go to some word in *scratch* and type M-$.
> 
>  > Then look with Process Explorer how Emacs invoked Hunspell.
> 
>  >When I do the above, I clearly see the "-p PDICT" command-line
>  >arguments with which Emacs invokes Hunspell.  I made a point of
>  >testing this on Windows with Emacs 28.2, which is what you have, and
>  >it worked for me.
> 
> Thanks for the detailed suggestions -- it now works.

So I guess we can close this bug now?

> From what I can tell, the issue was the double backslashes not being accepted 
> in the file path for the hunspell personal dictionary.

It should works either way.  Maybe you didn't double every backslash?

bug#61190: 28.2; ispell personal dictionary location for hunspell engine

[O G]

[-- Attachment #1: Type: text/plain, Size: 1780 bytes --]

On Sat, Feb 11, 2023 at 12:14 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: O G <opngid@gmail.com>
> > Date: Sat, 11 Feb 2023 12:07:36 -0500
> > Cc: 61190@debbugs.gnu.org
> >
> >  >  emacs -Q
> >  >  M-: (setq ispell-program-name "hunspell") RET
> >  >  M-: (setq ispell-personal-dictionary
> "C:/Users/xxxx/.hunspell_en_US") RET
> >
> >  > Now go to some word in *scratch* and type M-$.
> >
> >  > Then look with Process Explorer how Emacs invoked Hunspell.
> >
> >  >When I do the above, I clearly see the "-p PDICT" command-line
> >  >arguments with which Emacs invokes Hunspell.  I made a point of
> >  >testing this on Windows with Emacs 28.2, which is what you have, and
> >  >it worked for me.
> >
> > Thanks for the detailed suggestions -- it now works.
>
> So I guess we can close this bug now?
>

Yes, with the caveat that it would be nice to document this somewhere.  I
opened
up a bug report on the hunspell github repository about this issue and did
not
receive a response, so I'll respond to my own issue with this latest
information.


> > From what I can tell, the issue was the double backslashes not being
> accepted
> > in the file path for the hunspell personal dictionary.
>
> It should works either way.  Maybe you didn't double every backslash?
>

Just double-checked my setup and indeed the problem reappears when I
substitute
double backslashes for all of the forward slashes.  Also tried using the
cygwin-style "/c/..."
convention since everything is running (emacs + hunspell) inside an
uptodate installation
of msys2 using the mingw64 repository, and that does not work either.  Only
the
"C:/Users/..." path is accepted apparently.

Elsewhere within my init.el file the double backslash inside elisp strings
works just
fine for Windows file paths.

[-- Attachment #2: Type: text/html, Size: 2731 bytes --]

bug#61190: 28.2; ispell personal dictionary location for hunspell engine

[Eli Zaretskii]

> From: O G <opngid@gmail.com>
> Date: Sat, 11 Feb 2023 13:16:21 -0500
> Cc: 61190@debbugs.gnu.org
> 
>  So I guess we can close this bug now?
> 
> Yes, with the caveat that it would be nice to document this somewhere.

I'll try to find a place to mention this.

>  > From what I can tell, the issue was the double backslashes not being accepted 
>  > in the file path for the hunspell personal dictionary.
> 
>  It should works either way.  Maybe you didn't double every backslash?
> 
> Just double-checked my setup and indeed the problem reappears when I substitute 
> double backslashes for all of the forward slashes.

Doesn't happen here.  Please show the exact settings you used.  Was
that in "emacs -Q" or with your customizations?  If the latter,
perhaps some of your customizations get in the way.

bug#61190: 28.2; ispell personal dictionary location for hunspell engine

[O G]

[-- Attachment #1: Type: text/plain, Size: 1574 bytes --]

Okay, the double backslash works with emacs -Q on my system as well.

Back in my customizations, it looks like I had not rechecked by setting the
ispell-personal-dictionary variable ... was still using the ispell-cmd-args
approach unfortunately.  So it looks like the latter is the issue, because
everything works now per your suggested settings.

I had originally tried using ispell-personal-dictionary before turning to
ispell-cmd-args and now believe that I may have failed to touch the
.hunspell_en_US file first (a known quirk) while I was testing the double
backslashes among other ways of specifying the file path.

So it's safe to close the bug now.

On Sat, Feb 11, 2023 at 1:29 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: O G <opngid@gmail.com>
> > Date: Sat, 11 Feb 2023 13:16:21 -0500
> > Cc: 61190@debbugs.gnu.org
> >
> >  So I guess we can close this bug now?
> >
> > Yes, with the caveat that it would be nice to document this somewhere.
>
> I'll try to find a place to mention this.
>
> >  > From what I can tell, the issue was the double backslashes not being
> accepted
> >  > in the file path for the hunspell personal dictionary.
> >
> >  It should works either way.  Maybe you didn't double every backslash?
> >
> > Just double-checked my setup and indeed the problem reappears when I
> substitute
> > double backslashes for all of the forward slashes.
>
> Doesn't happen here.  Please show the exact settings you used.  Was
> that in "emacs -Q" or with your customizations?  If the latter,
> perhaps some of your customizations get in the way.
>

[-- Attachment #2: Type: text/html, Size: 2216 bytes --]

bug#61190: 28.2; ispell personal dictionary location for hunspell engine

[Eli Zaretskii]

> Cc: 61190@debbugs.gnu.org
> Date: Sat, 11 Feb 2023 20:29:01 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: O G <opngid@gmail.com>
> > Date: Sat, 11 Feb 2023 13:16:21 -0500
> > Cc: 61190@debbugs.gnu.org
> > 
> >  So I guess we can close this bug now?
> > 
> > Yes, with the caveat that it would be nice to document this somewhere.
> 
> I'll try to find a place to mention this.

Now done.

bug#61190: 28.2; ispell personal dictionary location for hunspell engine

[Eli Zaretskii]

> From: O G <opngid@gmail.com>
> Date: Sat, 11 Feb 2023 14:19:17 -0500
> Cc: 61190@debbugs.gnu.org
> 
> Okay, the double backslash works with emacs -Q on my system as well.  
> 
> Back in my customizations, it looks like I had not rechecked by setting the ispell-personal-dictionary variable
> ... was still using the ispell-cmd-args approach unfortunately.  So it looks like the latter is the issue, because
> everything works now per your suggested settings.  
> 
> I had originally tried using ispell-personal-dictionary before turning to ispell-cmd-args and now believe that I
> may have failed to touch the .hunspell_en_US file first (a known quirk) while I was testing the double
> backslashes among other ways of specifying the file path.
> 
> So it's safe to close the bug now.

Thanks, closing.

bug#61190: follow-up on ispell-personal-dictionary issue for hunspell

[O G]

[-- Attachment #1: Type: text/plain, Size: 1747 bytes --]

> Okay, the double backslash works with emacs -Q on my system as well.

> Back in my customizations, it looks like I had not rechecked by setting
the
> ispell-personal-dictionary variable
> ... was still using the ispell-cmd-args approach unfortunately.  So it
looks
> like the latter is the issue, because
> everything works now per your suggested settings.

> I had originally tried using ispell-personal-dictionary before turning to
> ispell-cmd-args and now believe that I
> may have failed to touch the .hunspell_en_US file first (a known quirk)
while
> I was testing the double
> backslashes among other ways of specifying the file path.

> So it's safe to close the bug now.

I have more information now regarding this issue, which as it turns out was
not related to my testing the ispell-cmd-args approach or because
I had failed to touch the .hunspell_en_US file per the known quirk on
windows.

In my init.el file, after the lines:

(setq ispell-local-dictionary "en_US")
(setq ispell-personal-dictionary "C:\\Users\\...\\test-personal-dictionary")
; the personal dictionary file has to exist, otherwise hunspell will
; silently fail to use it
(unless (file-exists-p ispell-personal-dictionary)
  (write-region "" nil ispell-personal-dictionary nil 0))

I had the following line:

(use-package flyspell
  :ensure t)

When I removed this line, flyspell started to recognize the
custom ispell-personal-dictionary that I had specified.

Since flyspell is now built into emacs, I'm a little unclear on
why reloading the package without changing any other options
would block an underlying ispell setting.

This also explains why everything worked just fine when I tested
setting a custom location for the personal dictionary using emacs -Q.

[-- Attachment #2: Type: text/html, Size: 2164 bytes --]