On the subject of Y. about vim-sensible HOT 13 CLOSED

OK, but yanking whole line already has default key binding, yy, which is even faster to type than Y (Shift+y). So is it really a problem? I use Y remapped as y$ quite often and it was always frustrating for me that naked Vim has this illogical vi-compatible binding for Y even if nocompatible is set. Y remapping is maybe the most sensible setting from vim-sensible – it makes an obvious correction while not breaking anything (yy is still there). If it is dropped then I'm afraid most other v-s settings will be gradually removed too, as there always will be someone that doesn't like some particular setting...

from vim-sensible.

If others are missing the big Y as well, put this you know where...

noremap Y y$

from vim-sensible.

@vectorstorm , I use vim-sensible even though I override a couple of its settings. I think it is valuable for the vim community to migrate towards "sane defaults" for most users, especially new users, even if veteran users prefer some historical quirks. It also takes some cruft out of my vimrc.

Why not override the 2-3 settings you object to?

from vim-sensible.

I object to installing a vim-sensible that doesn't noremap Y y$.

from vim-sensible.

@drastus , agreed. Probably the change that needs to be made to vim-sensible is to remove the goal of being a "plugin nobody objects to installing". 100% agreement is impossible. 99% is much more feasible.

from vim-sensible.

yy requires two keypresses by the same finger, executed in sequence. Y requires a single keypress each by two fingers on different hands, executed simultaneously. Any experienced touch-typist will press Y far faster than yy. This is, after all, why vi bothered to map yy to Y in the first place -- because it's faster and easier to type.

Anyhow, my intention wasn't to get vim-sensible to change anything; I was just reporting here that I don't use the plugin because I disagree with the Y remapping (and possibly &, and I still can't figure out the purpose of the insert mode <C-U> mapping, despite tracking down and reading its commit message. Which I guess means that I object to it.) I'm reporting this as an issue here only because the readme asks people to post an issue here if they disagree with anything in the plugin.

from vim-sensible.

To override settings in vim-sensible, I would have to break my vimrc into two different files in different directories in order to have them load at the correct times. That makes inspection, editing, and deployment of my vimrc on multiple machines rather more complicated, so I would prefer not to have to do it.

I've added a pull request in Issue #48 which contains one method to improve this overriding process.

from vim-sensible.

I'm dropping the Y mapping. I think the argument against it is pretty weak, but it's clearly a contentious override, and it's not really worth dividing people over.

Dropping && too, as I was never particularly enthused about that contribution. Leaving <C-U> for now, as it regularly saves my ass by making it undoable.

I'm sticking with the "nobody objects to installing" tagline. I'm quite happy to classify silo-building assholes as nobodies.

from vim-sensible.

I hope I didn't come across as a "silo-building asshole"; that was not my intent, and I'm very sorry if I did!

from vim-sensible.

No, those are a different category. :)

from vim-sensible.

Arrrrrgh wondering why this was broken now.

/me miserably re-adds the mapping back to vimrc

from vim-sensible.

Is the speed difference between yy and Y really that significant? I'd rather have two different functionalities. An extra command (copy to end of line) is more useful to me than the mostly insignificant amount of time I'd save with default Y.

from vim-sensible.

It's asinine, but this issue is closed.

from vim-sensible.