>
>
> On Wed, Jul 6, 2011 at 11:36 AM, Gary Johnson wrote:
>
> On 2011-07-06, Alexandre Provencio wrote:
> > I can also confirm that this is really an issue with the Ubuntu Natty's
> > version. I've just run a livecd, installed vim-gnome, set .vimrc to 'set
> spell
> > spelllang=en' and the same behavior described occurs.
>
> That's very good--that should give us a starting point that other
> people can use to verify and/or diagnose this problem. I'm losing
> track of exactly what behavior you're seeing, though. After
> creating a ~/.vimrc file containing only "set spell spelllang=en",
> what steps do you take and what do you observe? Give enough detail
> that anyone could unambiguously repeat your steps. If you're
> opening a file that contains spelling errors that aren't being
> highlighted as you expect, include the contents of that file here,
> or at least some small part of it that exhibits the problem.
>
> Ok.
>
> 1) Create (or use existing) 2 files with spelling errors
I first moved my ~/.vim and ~/.vimrc aside and created a new
~/.vimrc containing only this line:
set spell spelllang=en
Then I created two files containing spelling errors. File one
contains
The doog is brown.
and file2 contains
The burd is blue.
> 2) Start vim (or gvim) with no arguments. Start typing words which does not
> exist, you'll confirm that the words get highlighted by the spell checker
I started vim without any arguments and started typing this:
The qick brown
The word "qick" is highlighted.
> 3) Use ':e' to edit one of the files in step1.
When I do that, I get the error message
E37: No write since last change (add ! to override)
so instead I executed
:e!file1
> The bug is here. The words with spelling mistakes are NOT
> highlighted.
The bug is not there. The word with the spelling mistake (doog) is
highlighted.
> 4) Use ':e' again to edit the other file of step1. The words with spelling
> mistakes are highlighted as they should.
I executed
:e file2
and I saw the misspelled word (burd) highlighted there as well.
I'm running vim 7.3.189 on a Fedora 11 system. The ":scriptnames"
command shows
1: /home/garyjohn/.vimrc
2: /home/garyjohn/src/vim-hg/share/vim/vim73/plugin/getscriptPlugin.vim
3: /home/garyjohn/src/vim-hg/share/vim/vim73/plugin/gzip.vim
4: /home/garyjohn/src/vim-hg/share/vim/vim73/plugin/matchparen.vim
5: /home/garyjohn/src/vim-hg/share/vim/vim73/plugin/netrwPlugin.vim
6: /home/garyjohn/src/vim-hg/share/vim/vim73/plugin/rrhelper.vim
7: /home/garyjohn/src/vim-hg/share/vim/vim73/plugin/spellfile.vim
8: /home/garyjohn/src/vim-hg/share/vim/vim73/plugin/tarPlugin.vim
9: /home/garyjohn/src/vim-hg/share/vim/vim73/plugin/tohtml.vim
10: /home/garyjohn/src/vim-hg/share/vim/vim73/plugin/vimballPlugin.vim
11: /home/garyjohn/src/vim-hg/share/vim/vim73/plugin/zipPlugin.vim
I repeated the experiment using /usr/bin/vim which is version
7.2.148 and for which ":scriptnames" shows
1: /etc/vimrc
2: /usr/share/vim/vim72/syntax/syntax.vim
3: /usr/share/vim/vim72/syntax/synload.vim
4: /usr/share/vim/vim72/syntax/syncolor.vim
5: /usr/share/vim/vim72/filetype.vim
6: /usr/share/vim/vim72/ftplugin.vim
7: /home/garyjohn/.vimrc
8: /usr/share/vim/vim72/plugin/filetype.vim
9: /usr/share/vim/vim72/plugin/getscriptPlugin.vim
10: /usr/share/vim/vim72/plugin/gzip.vim
11: /usr/share/vim/vim72/plugin/matchparen.vim
12: /usr/share/vim/vim72/plugin/netrwPlugin.vim
13: /usr/share/vim/vim72/plugin/rrhelper.vim
14: /usr/share/vim/vim72/plugin/spellfile.vim
15: /usr/share/vim/vim72/plugin/tarPlugin.vim
16: /usr/share/vim/vim72/plugin/tohtml.vim
17: /usr/share/vim/vim72/plugin/vimballPlugin.vim
18: /usr/share/vim/vim72/plugin/zipPlugin.vim
19: /usr/share/vim/vim72/scripts.vim
The results were the same: no bug.
I repeated the experiment one more time, but starting vim as
vim --noplugin -u ~/.vimrc
to eliminate the effects of any plugins or system initialization
files. The output of scriptnames was
1: /home/garyjohn/.vimrc
The results were still the same: no bug.
If you start your vim with the "--noplugin -u ~/.vimrc" arguments,
and the only script sourced is your ~/.vimrc, and you still see the
problem, then I would conclude that that particular build of vim has
a bug. The solution is to find a later version or build it
yourself.
If you do that and the problem disappears, then the problem is
likely in one of the files sourced at startup. The solution then
may be a process of elimination to find the offending file and then
the offending command.
Regards,
Gary
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
No comments:
Post a Comment