Vim
Vim copied to clipboard
VSCodeVim
Mouse scrolling does not bring cursor
If you scroll down or up past the cursor, the cursor is still left where it was, so if you press <Esc> it will jump.
The cursor should stay at the top or bottom of the window when you scroll paste the current viewable area.
I actually disagree here; I always found this to be a big limitation of Vim. One common workflow I use is to click somewhere, then scroll to look somewhere else, then press something like h to return me back to where I clicked. (Yes, I should be using marks, but hey).
I don't actually see any text-editing advantage of doing this.
Huh, I never would have thought. I've never seen any other Vim emulation simulate this behavior. (Maybe under a flag?)
In any case, I'm sure we could implement it under a flag as well. :)
I mean vim is a console application, so this scenario would never happen, let me check how VsVim handles this
For your case, isn't that exactly what marks are for?
VsVim does not bring the cursor with it, but pressing esc or i does not jump back to it either, if you start to type in insert it then jumps to it
my $0.02 here: if users are using Code with Vim to handle large files, they will not like that we move cursor automatically for them while scrolling.
Vim running on my Mac brings the cursor with it. It treats scroll up/down as j/k with the cursor keeping the same column and everything. This is behaviour that I would expect.
Let's say I'm looking for something in a big file: a word "polymorph" in a dictionary (just as example). It looks like this:
I use (everything is common):
- cmd + d to scroll down
- set relativenumber (recently has been added to VSCode)
- set scrolloff=5
Without cursor jumping I can't jump with a relative number.
If you're somewhere in a file and you want to go to another place of a file but think about returning back then put a mark. There is nothing about the cursor.
Consider issue #946, where users expected some behavior that wouldn't work if we had this on by default. I'm ok to add this, but it will need to be under a flag.
Why is that true? We still remember where we last were when we switch tabs, that behavior is not the same as what is described here
The bug described in #946 is that the user would prefer not to scroll to the cursor on a tab switch. If we implemented a sticky cursor by default then on a tab switch we would scroll to the cursor and #946 would be a problem again.
@johnfn says:
I actually disagree here; I always found this to be a big limitation of Vim. One common workflow I use is to click somewhere, then scroll to look somewhere else, then press something like
hto return me back to where I clicked. (Yes, I should be using marks, but hey).I don't actually see any text-editing advantage of doing this. This is called self referential design.
The fact that one likes the things one way doesn't mean that everybody else likes the same.
In fact, there is great diversity. For example, there are people that even like EMACS! :-)
Millions of vi users are used to have the cursor always visible.
Likewise, millions of users are used to the vi UI no matter how strange it looks to others.
As of the flag, it should default to the traditional behavior.
Check the other's use case, for example mine: 1- Search for something 2- Scroll down looking for something else, for a while, in a lengthy file 3- See what I was looking for, in the second line of the screen 4- Press j to descend to the second line 5- Boom! I'm back where i started 6- Return to step 1.
I'm of the opinion that this is not desirable, especially as a default, but I understand those who use vim can be a bit old fashioned 😉 so I've implemented a rough version in #3945. @juanlanus and others interested in this feature, I'd appreciate some manual testing if you've got the time.
@J-Fields Thanks Jason. And FYI I'm not "old fashioned" but plain "old" :-) <= notice my old-school emoji
