On Fri, May 11, 2012 at 02:47:45AM EDT, Krzysztof wrote: [..]
> Again Thanks. I was wondering if the problem was because my plugin > setup etc. Unfortunately the response is not what I expected :) I was > hopping to easily remove :only mapping. I try the longer timeoutlen > and see if I can work with that. Well, I would imagine that your <C-W>O mappings and the Zoomwin plugin are not going to play well together. ;-) > I am using the Zoomwin plugin, I just disabled the mapping for :only > but that helps a little too. I am still hoping for better solution, > because the behavior is somewhat strange to me. Timeout is reached but > still the vim internal commands gets called. ( not my maped command) > Maybe this is expected behavior, but just doesn't gets to me. This is not easy to test comprehensively, since there are two flags (timeout & ttimeout) and the two corresponding time definitions of timeoutlen & ttimeoutlen. Depending on the values you choose for the latter, this quickly adds up to lots of scenarios. The truth table at :h timeout seems to imply that as long as ttimout is set to off, the setting of ttimeout does not make any difference. IOW, this suggests that timing out on mappings but not on keycodes is as setting that does not make sense (?) One way to make sure your <C-W>O mappings will always be executed no matter how long you wait between keystrokes is to set both timeout and ttimeout to off. Not sure what it will break (if anything) in your setup.. apart from not being able to use the Zoomwin plugin, naturally. Will there be cases where Vim will wait forever for the remainder of a keycode..?? You may be able to find suitable settings by going back to the defaults (first removing Zoomwin and your mappings) and working from there, with timeout on and in(de)creasing the value of timeoutlen - while leaving ttimeout and ttimeoutlen alone (since these do not concern mappings) until you find something that suits you. And when things seem to work for you, re-enable the Zoomwin plugin..? > Anyway I observed similar thing with window movements and splits > creation. After you start by <C-W> you have undefined time (not the > timeoutlen) to perform hjkl or sv what I mean by that is 'hjkl' stands > for movement and 'sv' are splits. I am not sure if that is a bug or > this should work like that. This is indeed what I observed. Vim appears to process builtin keyboard actions and user-defined mappings differently. Maybe something like a ‘history of layouts’ could be implemented in Vim code.. Vim would automatically keep track of a (user-configurable) number of past window splits and their geometry for each tabpage.. you could list them via a ‘layout’ command that would print the buffers comprised in each layout, and naturally the same ‘layout’ command could be used to restore a previous layout manually.. Something like the :buffers command on steroids.. CJ -- Alex Perez is aliveeeeeeee!!! -- 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
