4

Very often, my preferred way of navigating a file in vim is by "scrolling" line by line. By scrolling, I mean shifting the lines up/down while keeping the cursor on the same line and position. <c-d> and <c-u> implement this already, but they do so for half a page, not one line.

So I made bindings that implement what I need:

noremap K k<c-y> (technically I have noremap K @='k<C-Y>'<CR> to accept a count)

noremap J j<c-e> (technically I have noremap J @="j\<lt>C-E>"<CR> to accept a count)

So hitting j and k move the cursor up/down one line, and J and K scroll up/down one line.

But I've learned that vim bindings are made very intelligently. For example, I was always annoyed that searching using /<term> and ?<term> highlight the term and automatically make the cursor jump to the next/previous occurrence of it. I initially wanted them to just highlight the terms and then optionally choose to jump to them by hitting n, so as not to reset my view if the term doesn't exist in the current view. But I soon found myself using these search methods not necessarily to search for these terms, but to actually jump to them, as a way of fast navigation. I.e. it is sometimes much faster to search and jump to a pattern to navigate to a line position than by manually moving the cursor (using default movements) to the desired position at a line and position, even if that position is currently in view. And if the term doesn't exist in the current view, I can just call <c-o> to reset the view back to where I was.

So is there a reason why line by line scroll isn't implemented by default? I suspect that by making a macro for scrolling, I might be using vim not the way it is intended to be used/not in the most efficient way.

Edit: in terms of the scrolling functionality itself, I think the mappings above implements it fairly well and are convenient to use for my purposes.

  • 1
    It's an interesting question though I don't know if it passes the "answers would be primarily opinion based" test barring an appearance by Bram (or Bill Joy?). :) But if Vim's "prime directive" is efficient editing then line-by-line scroll would be a "low priority" movement since that's not how an editing session typically flows. Also, j/k movement which happens without moving the whole set of visible lines is far less jarring to the eye for most people, I would think, than line-by-line with cursor remaining fixed on one line number. Just two darts thrown at the board. ;) – B Layer May 16 at 3:28
  • 1
    But that's an application whose primary function is reading. Vim's primary function is editing. Apples and oranges, no? (Regardless, I read the whole thing then scroll in a new page! The less I move things around the easier...for me.) – B Layer May 16 at 3:39
  • 3
    Preferences are cousins of opinions, at least, no? – B Layer May 16 at 3:45
  • 3
    Dont Ctrl-y and Ctrl-e have helpful behavior here? – D. Ben Knoble May 16 at 14:37
  • 2
    Personally, I’m of the opinion that the question as stands is too opinion based (“why isnt this feature implemented?”). I’ll refrain from closing until there’s some consensus on that, but in the meantime some edits to change the question to “how do I implement this feature?” would make the question far more suitable for the Q&A model. – D. Ben Knoble May 16 at 18:45
6
                            *CTRL-D*
CTRL-D          Scroll window Downwards in the buffer.  The number of
            lines comes from the 'scroll' option (default: half a
            screen).  <b>If [count] given, first set 'scroll' option
            to [count].</b>  ...

Execute 1<ctrl-d> for one time, it will set 'scroll' to 1, you can then use <c-d> and <c-u> to do line by line scroll without moving cursor.

| improve this answer | |
  • The question was about it being "implemented by default". Does this qualify given that the normal function of ctrl-u/ctrl-d is to move half a page? I don't know. :) – B Layer May 16 at 3:38
  • 1
    @BLayer I think he just want a builtin way to do it, default or not is not important, everyone has a vimrc, if he set 'scroll' to 1 in it, it will be default. – dedowsdi May 16 at 3:41
  • 1
    @ZaidGharaybeh Run set scroll&, you get default hehavior. – dedowsdi May 16 at 3:45
  • 1
    @ZaidGharaybeh By the way default J and K are quite useful, see :h J, :h K. – dedowsdi May 16 at 3:48
  • 1
    @ZaidGharaybeh Then you will need to add a pair of new map to vim and maintain it, too many trivial map is just a burden. – dedowsdi May 16 at 3:53
4

Most likely the developer didn't feel that this feature is important enough to deserve a simple key. On the other hand it is possible to create mappings using 1<C-d> and 1<C-u> when you need it.

Remember that vi was initially implemented by Billy Joy in 1976. At that time scrolling the screen might have been an expensive operation.

| improve this answer | |
  • Oh, come on... A 300 baud modem can handle almost four lines of text per second... (Unavoidable for scrolling up on any terminal I actually saw. Some terminals would help with scrolling down. Some of this ended up in curses via termcap sourced from vi.) – Eric Towers May 17 at 4:06

Not the answer you're looking for? Browse other questions tagged or ask your own question.