lyokha/vim-fswitch — comment on commit 13bd3a9d027122b396fe2b5548ed7824de38b4c3
File:  line 0
By lyokha:

Hi Derek.

1. It appears to be an apparent error to do 'wincmd k' in FSSplitAbove as
soon as splitting will move to the above window itself. There is no evident
harm if only one window is open, but if you have another window above the
one to be splitted, then you will see that using 'wincmd k' will move to
the topmost window and open the new buffer there: thus you will have 2
windows with original buffer (2nd and 3rd from top), and one window with
alternative file (the topmost one), the original buffer in the topmost
window will be superseded by the alternative file. (This is not just a
theory, I experienced it myself).
In case of FSSplitBelow we will have to return to original (bottom window),
so we leave 'wincmd j' here.
Same idea goes for FSplitLeft and FSSplitRight.
I had enough time to test it in complex windows layouts and it works fine.

2a. a:precmd is just a string like

'let curspr=&spr | set nospr | vsplit | wincmd l | if curspr | set spr | endif'

This is not a real code. This string is executed within function FSwitch().
Only during execution of FSWitch() real variables are created (if i
unerstand correctly how 'execute' works). As far as variables 'curspr' and
'cursb' are created using 'let' inside a function, they automatically
become local to this function and their scope won't reach outside of body
of FSWitch(). So i do not understand the reason why make them buffer-local.

2b. I experienced errors like 'variable b:cursb is not defined' sometimes
(i have set bufhidden=delete in my .vimrc). When i removed those 'b:' it
became to work fine.

Cheers, Alexey.

2012/1/24 Derek Wyatt <
reply@reply.github.com
>

> 1. Ok, but it doesn't cause any harm and it would be resilient to a future
> change, no?
> 2a. I don't understand this... "get in fact local variables in function
> FSwitch()". Where? That argument goes into a:precmd and merely gets
> 'executed'. The b: seems quite necessary.
> 2b. I also don't understand this... "may lead to error messages about
> non-existent variables in some specific cases when option bufhidden is set
> to delete". Example? The lifecycle of these variables is for the single
> 'execute' so the buffer can't go away during the time of the execute and,
> thus, bufhidden isn't even involved.
>
> ---
> Reply to this email directly or view it on GitHub:
>
> https://github.com/lyokha/vim-fswitch/commit/13bd3a9d027122b396fe2b5548ed7824de38b4c3#commitcomment-897013
>