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

"co" option toggle as a configurable option #150

Open
pedrosans opened this Issue May 6, 2018 · 16 comments

Comments

Projects
None yet
5 participants
@pedrosans

pedrosans commented May 6, 2018

Hi, to toggle vim's configurations with the "co" keys is more comfortable to type than the '=o', can it be broth back as a configurable option?

@tpope

This comment has been minimized.

Owner

tpope commented May 7, 2018

The big problem with co is that Netrw breaks it with a dumb <nowait> map. I agree that =o is a bit too uncomfortable. What do you think about using yo?

@pedrosans

This comment has been minimized.

pedrosans commented May 7, 2018

yo would be more comfortable to type, but I can't think of a mnemonic for the y

@tpope

This comment has been minimized.

Owner

tpope commented May 7, 2018

Long past caring about that.

tpope added a commit that referenced this issue May 7, 2018

@ri-aje

This comment has been minimized.

ri-aje commented May 7, 2018

hi, can we make this =/y letter configurable? I actually prefer the = key much better than y which conflicts with my paste hotkey. this is because I don't use the default qwerty keyboard layout and that in itself is already a challenge due to vim's design based on the standard layout, and picking y here just made things worse.

@tpope

This comment has been minimized.

Owner

tpope commented May 7, 2018

The new map customization system is tailor made for this. What key do you use for yank?

@ri-aje

This comment has been minimized.

ri-aje commented May 7, 2018

I try to stick to the default. from a hardware perspective, I still use the physical y key for copy and p key for paste to serve my muscle memory. these keys don't generate the actual keycode for y and p though, instead they generate j and y under my layout mapping (in case you are interested, it's colemak layout with some slight adaption), which apparently messes up vim's key design. to revert this effect, I inject custom vim mapping so my fingers may continue function with vim's key design. my y key (which is the physical p key) ends up functioning as paste, but that is only after vim's mapping translation. with this change, however, there are multiple y* hotkeys so vim starts to wait a bit for every y press to determine whether I am pressing y or y* something, and that makes all paste operations pause a little, which is annoying.

what is the "new map customization system" you are talking? is it a new thing in vim-unimpaired or vim8? thanks.

@tpope

This comment has been minimized.

Owner

tpope commented May 8, 2018

It's new to unimpaired and some of my other plugins. Try

let g:nremap = {"y": "j"}
let g:xremap = {"y": "j"}
let g:oremap = {"y": "j"}

The idea here is that all plugins (or at least the ones I have any say in) with y maps will change to j maps.

The more I think about it, the more I think having multiple dictionaries is redundant.

@ri-aje

This comment has been minimized.

ri-aje commented May 9, 2018

it works. thanks. given these configs, curious to know why then #150 requires code change at all? seems like one could just inject {"=": "y"} to reach the same effect.

@tpope

This comment has been minimized.

Owner

tpope commented May 9, 2018

Because then you wouldn't be able to do let g:nremap = {"y": "j"} since the original map would still be =.

@ri-aje

This comment has been minimized.

ri-aje commented May 9, 2018

I am saying with the original code before your change in c4f32e, I could just put let g:nremap = {"=": "y"} in vimrc to have yo functions as =o which seems to be what was asked in this issue. since the problem can be solved with a config change, why do it with code change. make sense?

@tpope

This comment has been minimized.

Owner

tpope commented May 9, 2018

I've gotten enough pushback to know that some nontrivial percentage of users will be remapping (even I'm tempted), and I don't want fragmentation. Anyone can shove nmap <Leader>abc :set invlist!<CR> in their vimrc. A significant design goal of unimpaired is standardizing what the mappings should be.

@sodapopcan

This comment has been minimized.

sodapopcan commented May 9, 2018

Sorry for the issue reference above in my friggin' dotfiles repo... slipped my mind that that would happen.

@tpope

This comment has been minimized.

Owner

tpope commented May 9, 2018

@sodapopcan if it makes you feel any better you did it wrong and it won't actually work.

If you really want co maps, do this:

nmap co yo

The variables are for weird Dvorak/Colemak shit and most of you do not want to use them.

tpope added a commit that referenced this issue May 9, 2018

Bring back co
References #150
@tpope

This comment has been minimized.

Owner

tpope commented May 9, 2018

I have brought back co with a soft deprecation warning. It's clearly too contentious to take away before 2.0.

@sodapopcan

This comment has been minimized.

sodapopcan commented May 9, 2018

Oh heh 🤪 Thank you much for letting me know. I hadn't actually updated in several days so I didn't have the yo commit but noticed co wasn't working then found this issue and updated in haste.

Side note: big a fan of ]op and [op over the old way in spite of the extra keystroke.

@kiryph

This comment has been minimized.

kiryph commented Sep 24, 2018

Update for Netrw v162 or newer

Netrw v162 has changed netrw-c to netrw-cd and has introduced the new mappings netrw-cb and netrw-cB.

IMPORTANT If you want to check this for yourself, please download the new netrw version from http://www.drchip.org/astronaut/vim/index.html#NETRW. Upstream vim contains currently (24.09.2018) a version inconsistency between documentation and the actual file autoload/netrw.vim which defines the mappings: the documentation currently claims v162 but the autoload/netrw.vim is still v156.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment