ispell/hunspell/Windows: a fully-worked example

ispell/hunspell/Windows: a fully-worked example

[djc]

Thanks to several people, especially Eli Zaretskii, I now have ispell with hunspell working with GNU emacs 24.3.1 under Windows 7.  Here is a full explanation of my setup.

==== Step 1: install hunspell

hunspell doesn't require installation in the Windows sense: you only need to place it somewhere, anywhere.  Except as in step 2 below, it has no effect at all on Windows.

    a. Download the hunspell installation kit from

       http://sourceforge.net/projects/ezwinports/files

       I have hunspell-1.3.2-2-w32-bin.zip.

    b. Extract the contents of the zipfile to any directory. I chose

       D:\hunspell

==== Step 2: add hunspell to Windows PATH

This step may be unnecessary, and I'll probably try removing it.  But here's how:

    a. Start --> Control Panel --> System --> Advanced system settings -->
       "Advanced" tab --> Environment Variables

    b. In the "System variables" window select "Path" and click "Edit..."

    c. A window "Edit System Variable" will pop up showing the current
       value of "Path".  At the end of that string add

       ;{folder for hunspell.exe}

       which on my system is

       ;D:\hunspell\bin

    d. Click your way out: OK --> OK --> OK --> close the control panel
       window.

==== Step 3: add the dictionaries you want

There are many sources of dictionaries.

    a. Put the dictionaries where hunspell expects to find them, in

       ...\share\hunspell

       On my system that is

       D:\hunspell\share\hunspell

    b. I added these dictionaries:

       de_DE_frami (de_DE_frami.aff and de_DE_frami.dic)
       en_US (en_US.aff and en_US.dic)
       fr-classique (fr-classique.aff and fr-classique.dic)

==== Step 4: set up ispell initialization in emacs, for instance in ".emacs"

    a. Tell emacs and ispell where to find the executable.  I have

       (add-to-list 'exec-path "D:/hunspell/bin/")

       (setq ispell-program-name (locate-file "hunspell"
                exec-path exec-suffixes 'file-executable-p))

    b. Initialize "ispell-local-dictionary-alist".  I have

       (setq ispell-local-dictionary-alist '(

       (nil
           "[[:alpha:]]"
           "[^[:alpha:]]"
           "[']"
           t
           ("-d" "en_US" "-p" "D:\\hunspell\\share\\hunspell\\personal.en")
           nil
           iso-8859-1)

       ("american"
           "[[:alpha:]]"
           "[^[:alpha:]]"
           "[']"
           t
           ("-d" "en_US" "-p" "D:\\hunspell\\share\\hunspell\\personal.en")
           nil
           iso-8859-1)
       ("deutsch"
           "[[:alpha:]ÄÖÜéäöüß]"
           "[^[:alpha:]ÄÖÜéäöüß]"
           "[']"
           t
           ("-d" "de_DE_frami" "-p" "D:\\hunspell\\share\\hunspell\\personal.de")
           nil
           iso-8859-1)
       ("francais"
           "[[:alpha:]ÀÂÇÈÉÊËÎÏÔÙÛÜàâçèéêëîïôùûü]"
           "[^[:alpha:]ÀÂÇÈÉÊËÎÏÔÙÛÜàâçèéêëîïôùûü]"
           "[-']"
           t
           ("-d" "fr-classique" "-p" "D:\\hunspell\\share\\hunspell\\personal.fr")
           nil
           utf-8)
        ))

       The first -- nil -- sub-list defines the default dictionary, which
       on my system is American English, so except for the names (nil and
       "american") those sub-lists are identical.

       You will use the names in the sub-lists "american", "deutsch" and
       "francais" with "ispell-change-dictionary" in ispell.

    c. After (a) and (b) above, require ispell:

       (require 'ispell)

==== Step 5: use ispell

    a. Select a dictionary for the buffer you want to check:

       M-x ispell-change-dictionary

       and select one of the names in "ispell-local-dictionary-alist".
       Otherwise ispell will use the default dictionary under the "nil" list.

    b. Invoke ispell.

Voilà!

Re: ispell/hunspell/Windows: a fully-worked example

[djc]

I may have omitted a small step.  The dictionary alist contains arguments to
specify personal word files for the three languages:

    D:\hunspell\share\hunspell\personal.en
    D:\hunspell\share\hunspell\personal.de
    D:\hunspell\share\hunspell\personal.fr

It may be necessary to create those files, empty if you wish, before using
them; that's safest, in any case.  You can choose any names for them.

Re: ispell/hunspell/Windows: a fully-worked example

[AW]

Am Freitag, 4. April 2014, 00:41:50 schrieb djc:
> I may have omitted a small step.  The dictionary alist contains arguments to
> specify personal word files for the three languages:
> 
>     D:\hunspell\share\hunspell\personal.en
>     D:\hunspell\share\hunspell\personal.de
>     D:\hunspell\share\hunspell\personal.fr
> 
> It may be necessary to create those files, empty if you wish, before using
> them; that's safest, in any case.  You can choose any names for them.

Thank you very much for you help, I used your description, but without 
success! (Win 7, Emacs 24.3) 

However, I downloaded hunspell as source code and compiled it with a recent 
installation of cygwin, so one does not depend upon binaries. I followed the 
instructions given. 

The personal dicitionary has been created.  Hunspell works, I can ask on the 
commandline for the dictionaries (hunspell.exe -D spills out the path and the 
files). 

When I start flyspell (M-x flyspell-mode), Emacs sends the message: 
»Starting new Ispell process [C:/Program files (x86)/GNU Emacs 
24.1/aspell/bin/aspell.exe::default] ...«

This is really strange, because  the path to emacs ist C:/Program files 
(x86)/GNU Emacs 24.3 and not 24.1. I run out of ideas where to look for this 
strange hint to 24.1. There is nothing in my .emacs, nothing in neither path-
variable. If somebody has an idea where I should look, I'd be really glad to 
know. Dam' Windows...

And in the list of processes of Win 7 I find "aspell.exe *32", instead of 
hunspell.exe. 


Regards,

Alexander

Re: ispell/hunspell/Windows: a fully-worked example

[Eli Zaretskii]

> From: AW <alexander.willand@t-online.de>
> Date: Fri, 04 Apr 2014 12:29:12 +0200
> 
> When I start flyspell (M-x flyspell-mode), Emacs sends the message: 
> »Starting new Ispell process [C:/Program files (x86)/GNU Emacs 
> 24.1/aspell/bin/aspell.exe::default] ...«

You have aspell (a different speller) installed at that directory, and
Emacs finds it before it find hunspell, probably beacuse of the order
of directories in your Path.

To work around this, either uninstall aspell, or put this in your
~/.emacs:

  (setq ispell-program-name "x:/path/to/hunspell.exe")

Re: ispell/hunspell/Windows: a fully-worked example

[AW]

Am Freitag, 4. April 2014, 13:42:20 schrieb Eli Zaretskii:
> > From: AW <alexander.willand@t-online.de>
> > Date: Fri, 04 Apr 2014 12:29:12 +0200
> > 
> > When I start flyspell (M-x flyspell-mode), Emacs sends the message:
> > »Starting new Ispell process [C:/Program files (x86)/GNU Emacs
> > 24.1/aspell/bin/aspell.exe::default] ...«
> 
> You have aspell (a different speller) installed at that directory, and
> Emacs finds it before it find hunspell, probably beacuse of the order
> of directories in your Path.
> 
> To work around this, either uninstall aspell, or put this in your
> ~/.emacs:
> 
>   (setq ispell-program-name "x:/path/to/hunspell.exe")

Thank you, I had written this into my .emacs, without any success. 

If I start Emacs with "emacs -q" on the commandline and than type M-x flyspell-
mode, Emacs finds hunspell and starts it without any further ado! And that 
despite the really long path to hunspell, which is burried in 
C:/cygwin64/usr/local/bin !

If I start Emacs even with an empty (everything commented out) .emacs, M-x 
flyspell-mode tries to start that aspell.exe, which no longer exists (I renamed 
the folder)!

???? What is Emacs checking, even if the .emacs is empty, and what is the 
difference to starting it with "emacs -q" ??????????????

Regards,

Alexander

Re: ispell/hunspell/Windows: a fully-worked example

[Eli Zaretskii]

> From: AW <alexander.willand@t-online.de>
> Date: Fri, 04 Apr 2014 14:47:13 +0200
> 
> ???? What is Emacs checking, even if the .emacs is empty, and what is the 
> difference to starting it with "emacs -q" ??????????????

The site-init file, if you have it.  It's in the manual.

Re: ispell/hunspell/Windows: a fully-worked example

[AW]

Am Freitag, 4. April 2014, 16:03:03 schrieb Eli Zaretskii:
> > From: AW <alexander.willand@t-online.de>
> > Date: Fri, 04 Apr 2014 14:47:13 +0200
> > 
> > ???? What is Emacs checking, even if the .emacs is empty, and what is the
> > difference to starting it with "emacs -q" ??????????????
> 
> The site-init file, if you have it.  It's in the manual.

OK, thank you, again. I found "site-start.el", which tells me that it is meant 
to load the files in a "site-start.d" directory. I removed "site-start.el", but 
now Emacs complains:

"File error: Cannot open lad file, c:/Program Files (x86)/GNU_Emacs_24.3/tex-
site.el"

The file tex-site.el is exactly there!

OK, site-start.el belongs to AUCTeX, as far as I can see. Inside the folder 
site-start.de are two files, auctex.el and preview-latex.el

I reinstalled AUCTeX and got the old error back! So the file site-start.el, 
which belongs to AUCTeX does something, which leads to a wrong path.

The file site-start.el has no more content than these lines:

;; Load files in `site-start.d' directory.
(dolist (file (directory-files
	       (concat (file-name-directory load-file-name) "site-start.d")
	       t "\\.el\\'"))
  (load file nil t t))

This is weird!

Re: ispell/hunspell/Windows: a fully-worked example

[AW]

[SOLVED]
Am Freitag, 4. April 2014, 16:00:28 schrieb AW:
> Am Freitag, 4. April 2014, 16:03:03 schrieb Eli Zaretskii:
> > > From: AW <alexander.willand@t-online.de>
> > > Date: Fri, 04 Apr 2014 14:47:13 +0200
> > > 
> > > ???? What is Emacs checking, even if the .emacs is empty, and what is
> > > the
> > > difference to starting it with "emacs -q" ??????????????
> > 
> > The site-init file, if you have it.  It's in the manual.
> 
> OK, thank you, again. I found "site-start.el", which tells me that it is
> meant to load the files in a "site-start.d" directory. I removed
> "site-start.el", but now Emacs complains:
> 
> "File error: Cannot open lad file, c:/Program Files
> (x86)/GNU_Emacs_24.3/tex- site.el"
> 
> The file tex-site.el is exactly there!
> 
> OK, site-start.el belongs to AUCTeX, as far as I can see. Inside the folder
> site-start.de are two files, auctex.el and preview-latex.el
> 
> I reinstalled AUCTeX and got the old error back! So the file site-start.el,
> which belongs to AUCTeX does something, which leads to a wrong path.
> 
> The file site-start.el has no more content than these lines:
> 
> ;; Load files in `site-start.d' directory.
> (dolist (file (directory-files
> 	       (concat (file-name-directory load-file-name) "site-start.d")
> 	       t "\\.el\\'"))
>   (load file nil t t))
> 
> This is weird!

I took the opportunity and cleaned out my site-lisp directory. Whatever it 
was, some relict *.el, it's gone now and I'll test hunspell.

Thanks to everybody who read this thread and thought about it!

Regards,

Alexander

Re: ispell/hunspell/Windows: a fully-worked example

[Robert Thorpe]

AW <alexander.willand@t-online.de> writes:

> [SOLVED]
> I took the opportunity and cleaned out my site-lisp directory. Whatever it 
> was, some relict *.el, it's gone now and I'll test hunspell.
>
> Thanks to everybody who read this thread and thought about it!

I know you've solved it now, but I think it's worth mentioning another
complication.

On MS Windows the icon link files contain a path to an executable and
another path, the current directory to run that executable in.  Let's
say you install a new version of Emacs.  Instead of installing the new
menus and links with "addpm.exe" you just change the executable path in
the icon link file on your desktop.  In that case the new version of
Emacs is starting in the current directory of the old version.  That can
make Emacs confused if it searches for things in the current directory.

If this happens starting emacs from a command window will behave
differently to clicking the icon.

BR,
Robert Thorpe

Re: ispell/hunspell/Windows: a fully-worked example

[Eli Zaretskii]

> From: Robert Thorpe <rt@robertthorpeconsulting.com>
> Date: Fri, 04 Apr 2014 22:56:37 +0100
> Cc: help-gnu-emacs@gnu.org
> 
> Let's say you install a new version of Emacs.  Instead of installing
> the new menus and links with "addpm.exe" you just change the
> executable path in the icon link file on your desktop.  In that case
> the new version of Emacs is starting in the current directory of the
> old version.  That can make Emacs confused if it searches for things
> in the current directory.

Emacs never searches for things "in the current directory", it always
fully resolves file names relative to the current buffer's value of
default-directory, before passing them to system-call APIs.  The
"Start in" directory set by the desktop shortcut only affects the
*scratch* buffer; every other buffer will have some other directory as
its default one.  E.g., buffers that visit files have that file's
directory as their default-directory.

So I wonder whether you could show a real-life case where this problem
is indeed at work.  I think such cases don't really exist, except when
you evaluate expressions in *scratch*.

Re: ispell/hunspell/Windows: a fully-worked example

[Robert Thorpe]

Eli Zaretskii <eliz@gnu.org> writes:
> Emacs never searches for things "in the current directory", it always
> fully resolves file names relative to the current buffer's value of
> default-directory, before passing them to system-call APIs.  The
> "Start in" directory set by the desktop shortcut only affects the
> *scratch* buffer; every other buffer will have some other directory as
> its default one.  E.g., buffers that visit files have that file's
> directory as their default-directory.
>
> So I wonder whether you could show a real-life case where this problem
> is indeed at work.  I think such cases don't really exist, except when
> you evaluate expressions in *scratch*.

I see.  I use *scratch* for a lot of stuff, which is probably why I saw
this.  I expect that's not typical.

BR,
Robert Thorpe

Re: ispell/hunspell/Windows: a fully-worked example

[David Masterson]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Thorpe <rt@robertthorpeconsulting.com>
>> Date: Fri, 04 Apr 2014 22:56:37 +0100
>> Cc: help-gnu-emacs@gnu.org
>> 
>> Let's say you install a new version of Emacs.  Instead of installing
>> the new menus and links with "addpm.exe" you just change the
>> executable path in the icon link file on your desktop.  In that case
>> the new version of Emacs is starting in the current directory of the
>> old version.  That can make Emacs confused if it searches for things
>> in the current directory.
>
> Emacs never searches for things "in the current directory", it always
> fully resolves file names relative to the current buffer's value of
> default-directory, before passing them to system-call APIs.  The
> "Start in" directory set by the desktop shortcut only affects the
> *scratch* buffer; every other buffer will have some other directory as
> its default one.  E.g., buffers that visit files have that file's
> directory as their default-directory.
>
> So I wonder whether you could show a real-life case where this problem
> is indeed at work.  I think such cases don't really exist, except when
> you evaluate expressions in *scratch*.

The OP is using the typical use-case.  Emacs will indeed start with the
default-directory set to the value of "Start In" for the Windows icon.
Any buffer created will inherit this value and, then, may set a new
value.  Therefore, the real-life case is that, if you go into dired, you
may not be in what you were expecting...

The answer to the OP is to set the "Start In" property of the Windows
icon for Emacs to something that will always be appropriate (like the
Documents directory in your \Users directory).

-- 
David Masterson

Re: ispell/hunspell/Windows: a fully-worked example

[Eli Zaretskii]

> From: David Masterson <dsmasterson@gmail.com>
> Date: Fri, 04 Apr 2014 23:59:33 -0700
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Emacs never searches for things "in the current directory", it always
> > fully resolves file names relative to the current buffer's value of
> > default-directory, before passing them to system-call APIs.  The
> > "Start in" directory set by the desktop shortcut only affects the
> > *scratch* buffer; every other buffer will have some other directory as
> > its default one.  E.g., buffers that visit files have that file's
> > directory as their default-directory.
> >
> > So I wonder whether you could show a real-life case where this problem
> > is indeed at work.  I think such cases don't really exist, except when
> > you evaluate expressions in *scratch*.
> 
> The OP is using the typical use-case.  Emacs will indeed start with the
> default-directory set to the value of "Start In" for the Windows icon.
> Any buffer created will inherit this value and, then, may set a new
> value.

Correction: (almost) all buffers set a new value for
default-directory.  It is not easy to find buffers that don't, if they
at all exist.

> Therefore, the real-life case is that, if you go into dired, you
> may not be in what you were expecting...

Dired asks for the directory to edit.  If you go to Dired from
*scratch*, and if you accept the default without changing it, you will
indeed get the listing of the directory where Emacs started.  But I
fail to see how this is related to the OP, whose problem was to find
the correct speller on PATH.  And even in the above case, the
directory where you run Dired is explicitly shown in the prompt, so
the user should see it and understand what she is doing.

> The answer to the OP is to set the "Start In" property of the Windows
> icon for Emacs to something that will always be appropriate (like the
> Documents directory in your \Users directory).

And my answer to the OP is that the value of "Start in" hardly
matters, although setting to something other than the directory of
another Emacs version definitely cannot do any harm.