Wrong message E764 in Windows 10

[Antonio Giovanni Colombo]

Hi everybody,

while editing a file (using Vim 8.1.1286) in Windows 10, giving a "zg" command to add a word to the wordlist, I get an unexpected message (in Italian -- which is fine)

"E764: opzione 'spellfile' non impostata", and the word is not added to the wordlist, even if I had typed

:set spell spelllang=en

and the option had evidently been accepted (as shown from the fact that only the non English words are underlined on the screen).

I tried to reproduce the problem under Linux Mint 19.1 (same version of Vim), and it works as expected (i.e. the word is added to the wordlist). Editing the very same file in the Ubuntu 18.04 APP on the same Windows PC also does NOT show the problem. So, it seems to be Windows related. The Vim executable has been downloaded from the Nightly "Vim Windows build snapshots", i.e. I did not compile it myself (while I did for the Linux Mint and Ubuntu versions).

Antonio Colombo

[Christian Brabandt]

Did this behaviour change recently?

Best,
Christian
--
Wir sollten uns mit den großen Problemen beschäftigen, solange sie
noch ganz klein sind.
-- Jadwiga Rutkowska

[Jürgen Krämer]

Hi,

it seems the 'spellfile' option is empty.

Can you check with

    :verb set spellfile

whether and where it has been cleared on your Windows computer and where it has been set on you Linux machines?

Regards,
Jürgen

--

Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us.     (Calvin)

[Antonio Giovanni Colombo]

Hi Christian and Jürgen,

I just checked, and I don't set the value in my .vimrc (neither in Linux nor in Windows).

The Windows Vim tells me that the spellfile is not set:

 spellfile=

The Ubuntu Vim tells me that the spellfile is in:

 spellfile=~/.vim/spell/en.utf-8.add 

Note that BEFORE giving a "zg" to add a word to the wordlist,

even the Ubuntu Vim tells me that there is no spellfile.

In other words, Vim does the assignment when needed.

As for the files themselves, they exist in Windows and have been used not a long time ago:

C:\Program Files (x86)\Vim>dir *.add /s 

 Il volume nell'unità C è OS

 Numero di serie del volume: BAF6-B607

 Directory di C:\Program Files (x86)\Vim\vimfiles\spell

29/03/2019  18:17               365 en.latin1.add

20/03/2019  22:20             1.593 it.latin1.add

               2 File          1.958 byte

 

Sooo, I guess that for some reason the Windows Vim can't define on the fly the spell file (maybe for some authorization problem). Of course it used to work just fine in the past.

If I try to define the spellfile (in Windows Vim) it does not seem to work. Vim silently cuts a few chars at the end of the name, it does not complain, but then the spellfile is not set.

:set spellfile="C:/Program Files (x86)/Vim/vimfiles/spell/en.latin1.add"

The final 'dd"' is dropped from the display, but the assignment is not done.

Should I try some "verbose" something?

Thanks and all the best, Antonio

[Jürgen Krämer]

Hi,

Antonio Giovanni Colombo schrieb am 08.05.2019 um 15:39:
>
> I just checked, and I don't set the value in my .vimrc (neither in Linux
> nor in Windows).
>
> The Windows Vim tells me that the spellfile is not set:
>  spellfile=
>
> The Ubuntu Vim tells me that the spellfile is in:
>  spellfile=~/.vim/spell/en.utf-8.add 
>
> Note that BEFORE giving a "zg" to add a word to the wordlist,
> even the Ubuntu Vim tells me that there is no spellfile.
> In other words, Vim does the assignment when needed.

please check with

:verbose set spellfile

from where your spellfile option was set. It might show you that some
plugin set the option on the first use of "zg".

> As for the files themselves, they exist in Windows and have been used not a
> long time ago:
>
> C:\Program Files (x86)\Vim>dir *.add /s 
>  Il volume nell'unità C è OS
>  Numero di serie del volume: BAF6-B607
>
>  Directory di C:\Program Files (x86)\Vim\vimfiles\spell
>
> 29/03/2019  18:17               365 en.latin1.add
> 20/03/2019  22:20             1.593 it.latin1.add
>                2 File          1.958 byte
>  
> Sooo, I guess that for some reason the Windows Vim can't define on the fly
> the spell file (maybe for some authorization problem). Of course it used to
> work just fine in the past.

Yes, it's probably not a good idea to have files, which are meant to be
modified, under C:\Program Files (x86). Better create a _vimfiles\spell
directory under your user directory, e.g., "C:\Users\antonio\_vimfiles\spell".

> If I try to define the spellfile (in Windows Vim) it does not seem to work.
> Vim silently cuts a few chars at the end of the name, it does not complain,
> but then the spellfile is not set.
>
> :set spellfile="C:/Program Files (x86)/Vim/vimfiles/spell/en.latin1.add"
>
> The final 'dd"' is dropped from the display, but the assignment is not done.

Everything after the first double quote sign is considered a comment, so the
actual command Vim executes is

:set spellfile=

which clears the option.

[Antonio Giovanni Colombo]

Hi Jürgen,

it turns out that executing the same commands on the same file on the same PC, using Windows Vim and using Ubuntu Vim, Vim does exactly the same things, but in one case the message E764 is issued (Windows), while in the other case it is not (Ubuntu). The situation can be appreciated looking at lines 406-407 (Windows - file verbosew.out) and at line 359 (Ubuntu - file verboseu.out) of the attached files.

The commands are:

:set spell spelllang=en

and

zg 

I could try to solve the thing setting the option in my _vimrc/.vimrc, but it is not a real solution, since I normally use different spell files in the same session, (usually English and Italian), and one cannot simply specify in which directory they all are.

But I feel that there is something done differently in Windows. I could try to trace where it happens, but I am not sure to be able to propose a correction.

All the best, Antonio

[Jürgen Krämer]

Hi Antonio,

I still think the reason for the different behaviour lies in some plugin that
initializes your 'spellfile' option on Ubuntu but does not on Windows -- either
because it's missing or it does not work or behaves differently.

Please check on Ubuntu how the 'spellfile' option was set by executing the
command

:verbose set spellfile

Ah, I just saw this paragraph at ":help 'spellfile'":

When a word is added while this option is empty Vim will set it for
you: Using the first directory in 'runtimepath' that is writable. If
there is no "spell" directory yet it will be created. For the file
name the first language name that appears in 'spelllang' is used,
ignoring the region.

Is at least one directory in you runtimepath writable?

[Antonio Giovanni Colombo]

Hi Jürgen,

> Is at least one directory in you runtimepath writable?

As far as I can tell, they should all be writable (I usually start Vim from an Administrator cmd session).

As a matter of fact, "zg" worked fine at least up to March 20. I update regularly Vim, through the nightly distribution and through recompiling under Ubuntu. The nightly build Vim update, of course, would fail if I had no proper authorizations.

I also regularly update Windows (I am in Windows Insiders). Maybe the thing is WIndows related.

We could put this on hold, and I will try again with the next version of Windows.

And, always as far as I can tell, both in the WIndows and in the Ubuntu environments, "spellfile" gets a value only AFTER I give a "zg" command. From that side, maybe the problem is in some Windows related "ifdef". I will try and see if I can get to it.

Also, I am not aware of any plugin that deals with "spellfile" (I am not in the "plugin" business, per se, but I gladly accept what comes with the Vim distribution).

[Antonio Giovanni Colombo]

Hi Jürgen,

I got a new version of Windows Insiders (Build 18894.1000), and the problem is still there. Sooo, maybe it is some further check in Windows that it is here to stay or whatever.

Looking into the help for 'runtimepath', in Windows, the first place checked for a writable directory is $HOME/vimfiles (which in my case did not exist yet). I just created that directory, (which for sure I am authorized to use) and now everything is fine. I will just move my old "en.latin1.add" etc. files there.

I would stop at that, and close the problem.

Thanks for your help!

Antonio