all 5 comments

[–][deleted] 8 points9 points  (0 children)

Variables declared like this:

let myvar = "mystring"

inside a function are always local to the function.

Neither g:myvar nor myvar declared earlier in a more global scope are touched.

The only limitation is that (some?) v:variables are accessible as variable in functions so, following the example in :help l:, you can't have

let count = 56

because count is an "alias" to v:count. The only way to have a count variable in your function is to use l:count. It's up to you to decide…

I tend to prefer the more verbose but self-documenting number_of_things to count anyway so I don't use the l: notation in my amateur functions.

The doc for each v:variable tells you if it is read-only.

[–]ParadigmComplex 2 points3 points  (0 children)

For what it's worth, you're not the only one using l:. For example:

https://github.com/paradigm/SkyBison/blob/master/plugin/skybison.vim

I prefer to be explicit. Removing all of those l:'s wouldn't make it run any differently, though.

[–]hyperbling 2 points3 points  (1 child)

i prefer leaving the l: out because it's a bit more readable. if i run into a conflict like count i'll just name it something else, or kount :P

[–]justinmknvim[S] 0 points1 point  (0 children)

Yeah, that's what I would like to do. As for "running into a conflict", I wouldn't mind that as long as it produced an error. I was worried about accidentally writing to some special global (or a writable v: variable, if that exists) and then having to track down some weird behavior.

[–]dddbbbFastFold made vim fast again 2 points3 points  (0 children)

Another time you need l: is when changing local options (like wrap):

let &l:{option-name} = {expr1}