-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
control-c is a bad map for lazy people #27
Comments
Totally agreed. The plugin should not remap common vim mappings. We could go for ? |
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: 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. The rotation commands are cool, but they're disorienting for me. I didn't use them here. edit: I take care to not override behavior on special buffers.
|
Hi! I agree with your vision on |
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 |
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 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 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, |
@ToPoe as for multiple buffer on the same file, the new handling of windows should have solved that |
@spolu I just tried again and |
@tpope ok. My bad! :) |
Totally +1 for this from @afriggeri . Sure we use |
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?
The text was updated successfully, but these errors were encountered: