Re: question for charles (or anyone): netrw whacking t
On Wed, Jul 12, 2006 at 01:24:51PM -0400, Charles E Campbell Jr wrote:
> Benji Fisher wrote:
>
> >I think I see the problem. In $VIMRUNTIME/autoload/netrw.vim , in
> >the function netrw#DirBrowse() , there are the lines
> >
> > if &fo =~ '[ta]'
> > set fo-=t
> > set fo-=a
> > echohl Warning
> > echo '***warning*** directory browsing and formatoptions "ta" are
> > incompatible'
> > echohl None
> > endif
> >
> >(I am not sure that I ever get to see that warning message.) I think
> >that replacing :set with :setlocal will fix the problem. Remember, when
> >dealing with a local option, :set changes both the local value and the
> >global default; :setlocal changes only the value...
> >
> >I think it should be
> >
> > :let &l:spell = ...
> >
> >
> Actually, I don't want to use local settings; just obstinate, I guess!
> What netrw v102h does
> (and its available at my website,
> http://mysite.verizon.net/astronaut/vim/index.html#VimFuncs
> as "Network Oriented Reading, Writing, and Browsing) is save global
> settings, make them
> netrw-friendly, do the browsing thing, restore the settings.
In that case, use the &g: prefix. For example, try the following
experiment:
:set spell
:new
:setl spell!
:echo &spell &l:spell &g:spell
I think you should get
0 0 1
(as I do). So &spell references the local value of the option, not the
global value. Now, consider the lines
let w:spellkeep = &spell
...
if exists("w:spellkeep")|let &spell = w:spellkeep |unlet w:spellkeep|endif
in $VIMRUNTIME/autoload/netrw.vim . The first sets w:spellkeep to the
local value, and the second sets the global value.
Bottom line: while testing the OP's problem before my original
post on this thread, I did find that options ended up being set in ways
I did not want nor expext, and
:verbose set spell?
told me that netrw was the culprit.
HTH --Benji Fisher
Re: Gvim for KDE
Dnia środa, 12 lipca 2006 22:23, Stefan Karlsson napisał: > By the way, is there anyone out there that is working on a KDE version? No. m.
Re: Gvim for KDE
i don't get it vim compiles for me just fine -- suse linux 10.0, using KDE, vim 7.0.35 -- am i missing something here? I think he meant a Vim GUI that is based on KDE/Qt rather than GNOME/GTK. Diwaker -- Web/Blog/Gallery: http://floatingsun.net/blog
Re: minor feature request: let!
On 7/9/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote: Justin Constantino wrote: > Currently, if you try to assign a value to a variable with a different > type, you get: > > E706: Variable type mismatch > > To make it work, you have to first unlet the variable, which is kind > of annoying if the expression you are assigning references that > variable. For example, to split a string in-place, you have to do: > > let foo = "one,two,three" > let temp = split(foo, ',') > unlet foo > let foo = temp > unlet temp > > As a minor improvement, I think it would be nice if you could do: > > let foo = "one,two,three" > let! foo = split(foo, ',') Suppose someone asks you what the "foo" variable is for, what are you going answer? The point is: let the variable name reflect what it contains, don't re-use the same variable for something else. That way your code will be a lot more readable. let fooline = "one,two,three" let foowords = split(fooline, ',') Fair enough, but in most of the cases where this came up, I never really cared about the 'fooline' variable. It only existed as an intermediate to 'foowords'. My choices were either: 1) put everything in one assignment, which can get long and messy and harder to read, or 2) split it into two assignments by declaring an extra 'foowords' that I never really care about. Reusing the variable makes sense to me in this case, and this seemed like a harmless and logical addition, but I guess you're the Bram.
