dwm.vim
dwm.vim copied to clipboard
control-c is a bad map for lazy people
control-c is the alternate default keymap for "ESC". Some folks like me can't be bothered to reach their pinky finger all the way to that escape key. A couple times now I've closed my buffer just trying to escape insert mode with control-c. I can do a remapping in my vimrc, but I figured I'd see what the rationale is here.
I'm not familiar with dwm, are these control mappings taken from there? Why is control-c even needed? Would it be possible to hijack/alter vim's existing buffer close event?
Totally agreed. The plugin should not remap common vim mappings. We could go for <C-x> ?
Maybe you don't need a special buffer close command? My thought is that you mark dwm buffers with a special buffer variable (e.g. b:dwm_enabled), and check for it whenever a buffer is closed. If it exists, then you can close the dwm buffer gracefully. I'm guessing you can set the buffer variable somewhere appropriate, and avoid setting it on "panel" type buffers (quickfix, etc.).
You probably already know these things, but here's the list of vim events: http://www.ibm.com/developerworks/linux/library/l-vim-script-5/index.html
A couple more random thoughts:
You might consider adding in a function that splits the existing buffer (rather than creating a new one via CTRL-N).
Your plugin makes sense with tim popes "unimpaired" plugin... I would remap ]b/[b to cycle through the buffers since I'm already used to it. You could even override vim's :bn/:bp commands. I wouldn't do it as a default, but might add suggested code in the readme.
Here's how a relevant portion of my vimrc looks now. I'm still playing around with these mappings, but the helper functions might be of use. Everyone has their favorite way to config vim, so take this with a grain of salt.
The rationale for the mapping is that I like to preserve control sequences for commands I want to repeat rapidly. There's a lot of default vim control mappings, so there's not as much command "bandwidth" there either. Your window resizing commands are perfect for control mappings, so I kept them.
The rotation commands are cool, but they're disorienting for me. I didn't use them here. Rather, I use tab to cycle through the windows (in normal mode) and select via the carriage return (focus on window). I didn't mind overriding vim's default normal-mode <CR> behavior here, it's not that useful imho.
edit: I take care to not override <CR> behavior on special buffers. edit: I update the dwm_fix command so that it works regardless of how messy the windows are, and make tab a little more useful
" Window/buffer management courtesy of dwm.
" Override basic behavior
let g:dwm_map_keys = 0
" Cleans up the window layout if dwm buffer is closed arbitrarily
function! DWM_Fix()
let w = 1
" stack all windows
while (w <= winnr("$"))
exe w . "wincmd w"
wincmd K
let w+=1
endwhile
" make the last current window the main window
wincmd H
" resize according to user preference
call DWM_ResizeMasterPaneWidth()
endfunction
" Split the current buffer
function! DWM_Split()
" Move current master pane to the stack
call DWM_Stack(1)
" Create a vertical split
vert topleft split
call DWM_ResizeMasterPaneWidth()
endfunction
"imap <expr><CR> pumvisible() ? "\<C-k>" : "\<CR>"
map <silent> <Leader>wf :call DWM_Fix()<CR>
map <silent> <Leader>ws :call DWM_Split()<CR>
map <silent> <Leader>wo :call DWM_New()<CR>
map <silent> <Leader>wq :call DWM_Close()<CR>
nnoremap <expr><CR> &bt == '' && winnr() != 1 ? ":call DWM_Focus()\<CR>" : "\<CR>"
map <silent> <C-H> :call DWM_GrowMaster()<CR>
map <silent> <C-L> :call DWM_ShrinkMaster()<CR>
map <expr><TAB> winnr("$") == 1 ? ":call DWM_Split()\<CR>" : "\<C-W>w"
map <silent> <S-TAB> <C-W>W
Hi! I agree with your vision on <C-C>. It can be replaced with a hook on :bd with buffer types.
Can you make a pull request ou of the code you made?
Other people interested I'd love to hear what you think about this (cc @lmarburger @fjolnir @tpope @afriggeri @mitnk @matze)
The way I see it, we should basically get rid of the <C-N> and <C-C> shortcuts and try to find a way to automatically open a new master window on :e file and automatically close on :q, :bd etc. Seems to fit better with the philosophy, but no idea how to achieve it in a non hackish way. I'm pretty sure @tpope might have valuable input on how to do this kind of stuff though.
Okay, so for starters, I completely agree with @jdonaldson, and I was trying to make it a full week before I complained. That said, there's a bit of merit to using mappings rather than hijacking events, as it means I'm not forced into the dwm workflow 100% of the time. It's pretty painful, for example, to be forced to use a vertical split in an 80 column terminal. (Maybe a horizontal mode could kick in for narrow terminals. But that's a whole different issue.)
I was toying with remapping <C-W><C-C>. Sure, it's a Vim built in, but it's one with plenty of alternatives (<C-W>c, :q, :bd, etc.).
Alternatively, perhaps one could stick to the whole event interception plan, but only add dwm magic if there's a vertical split. This probably doesn't cover every conceivable case, but it would spare me my most common use case.
@afriggeri, intercepting close events is probably doable, but you'd probably have better luck intercepting :sp than :e. I have some thoughts about new windows as well, but I don't want to muddle this issue by bringing them up here.
One last thing: We should be mindful of the difference between buffers and windows. I very, very occasionally open the same buffer in two splits so I can view one part of the file while editing another. The one time I tried this with dwm.vim, <C-c> burned me.
@topoe as for multiple buffer on the same file, the new handling of windows should have solved that
@spolu I just tried again and <C-C> still closes all windows with that buffer in it. I'll open a pull request
@tpope ok. My bad! :)
The way I see it, we should basically get rid of the
<C-N>and<C-C>shortcuts and try to find a way to automatically open a new master window on:efile and automatically close on:q,:bdetc.
Totally +1 for this from @afriggeri .
Sure we use :e file to open new, since a blank buffer does not make much sense. For closing buffer, we should add instruction (e.g. :bd, :q, ZZ) in Readme and dwm.txt It is up to the user to map it or not.