On the subject of Y.

[vectorstorm]

The readme says "I want this to be a plugin nobody objects to installing. Let me know if you have any objections to anything." And so (after being prompted by a few redditors) I'll just mention that the reason why I've never installed this plugin is Y. And, I suppose, to a much lesser extent, I'm uneasy about & on an intellectual level. And I don't really understand the intent of the insert mode C-U mapping (is it really intended to delete to the beginning of the line, going outside the scope of the inserted text? That seems quite odd, so I'm assuming it's unintentional). But chiefly my concern is with Y.

"Yank whole line" is something which I do quite frequently. On the order of a dozen times per day, I would estimate. I can't remember ever having wanted to "yank to end of line". So removing a convenient, default vim command which I use and replacing it with one I don't need doesn't work for me, personally.

Maybe that's just because I'm mostly using vim to edit C-style code, and so an explicit "yank to end of line" usually winds up placing a terminating semicolon into the " register. If I do a naive "yank to end of line", I then have to clean up those extra semicolons everywhere where I use the yanked code. So when I do want to yank to the end of a line of code, I always end up using yt; instead of y$, to exclude the semicolon. Vim-sensible's remapped Y behaviour just isn't useful for me.

Maybe the remapped Y is more useful for folks who program in languages which don't use statement terminators, or to people who write prose? I don't know. Or maybe most folks don't use Y very frequently at all, and so the whole issue reduces to a question of which behaviour is easier for them to remember, for a rarely used operation.

But in my world of C programming, the standard scope of C and D being different from that of Y makes intuitive sense, because each command is using a scope that I frequently want to use for that type of command. I do often want to delete from the cursor to the end of the line. I don't ever want to yank from the cursor to the end of the line, but I do often want to yank a complete line. So the default scopes of D and Y make sense to me, even though they don't match each other, because they do match things which I commonly want to do when deleting and yanking, respectively; they're like "alt-fire" versions of those operations, each of which does something useful, related to their base operation.

Really, I'm doubtful that a plugin which aspires to be "defaults everyone can agree on" should be making key bindings at all. There will always be people who think that the Vi-basic and/or Vim-default way to do things is the right way to do them. You'd have the same complaints from some folks if vim-sensible incorporated the popular nnoremap j gj and nnoremap k gk remappings (I don't use these). Or nop'd the arrow keys (I don't do this, either). Or vnoremap < <gv and vnoremap > >gv so that it's possible to repeatedly shift indenting while maintaining a visual selection (I do use these). Changing any basic commands to work differently is probably never going to be something that everyone will agree on; everybody's got their own commonly encountered situations informing which functions are useful to them (like my "semicolons on the end of lines" issue which makes "yank to end of line" unhelpful for me), and so you're probably not going to find any single remapping that absolutely everyone will agree is better than the default.

Anyhow, sorry for writing a novel in your issue tracker. :) Hope this is of at least a little help, as an alternative point of view.

[drastus]

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...

[justinmk]

@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.

[vectorstorm]

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.

[justinmk]

@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?

[vectorstorm]

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.

[tpope]

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.

[vectorstorm]

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!

[tpope]

No, those are a different category. :)

[daGrevis]

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

noremap Y y$

[gaving]

Arrrrrgh wondering why this was broken now.

/me miserably re-adds the mapping back to vimrc

[ghost]

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

[trusktr]

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.

[tpope]

It's asinine, but this issue is closed.