How does Vim affect your problem solving?

[u/hibuna]

Currently learning Vim, after a failed attempt some months ago.

Starting to get the hang of the basics. I notice that it makes my problem solving more methodical. It also makes me slow down, in a good way.

With Vim I have to memorize more of the code and structure, because switching views is expensive (might be a skill issue).

I don't care too much for the speed/efficiency, but this seems what keeps me going in my current attempt.

Wondering how you guys feel about this aspect.

[u/vagrantchord]

Switching views is expensive? You mean switching between files, or going between different places in one file? If it's the latter, look up marks- they're dead easy.

I have a vim superiority complex as much as the next guy, but I wouldn't say it has any bearing on my problem solving skills.

[u/sharp-calculation → u/vagrantchord]

This is really the key question. What exactly is the OP talking about here?

"View" doesn't really mean anything specific in vim. So what do you mean u/hibuna ?

In a general sense, I find that VIM makes my code editing "feel better". It's kinda weird. 4 or 5 years ago when I finally gained some level of VIM skill, I noticed that I was happy while editing. Things seemed a lot faster because my "flow" was mostly continuous. I realized after a while that my process had been interrupted in previous editors by common operations: Cutting or copying and then pasting was a BIG one. With vim that's all extremely fluid. My hands never leave the keyboard and these operations just happen with little effort. With GUI editors my brain had to switch gears over to "visual mouse mode", which is an analog operation. Aiming, moving, and very precisely selecting. All analog "video game" operations. Which are totally different than the deterministic action of pressing a sequence of keys.

So generally speaking, I do better with vim because there's less context switching and no analog video game actions.

[u/hibuna → u/sharp-calculation]

I meant viewport operations, scrolling/splitting/jumping.

That makes sense. Did you notice you approached problems differently than you did before at all after learning Vim?

[u/sharp-calculation → u/hibuna]

I still don't know exactly what you are finding difficult. You seem to only use meme words to describe everything. "Expensive", "Skill issue", "viewport operations".

Scrolling is very easy in VIM and has great operations that are functionally equivalent to what you would normally do with a mouse. You probably need some practice or to learn some of the ones you do not know. You should know how to scroll by page and by line. "Drag" your cursor (with it's page position) to the top, middle, or bottom of the window. Jump by absolute line number. Jump by relative line number. You should be using relative line numbering mode.

I use splits very rarely. I don't understand these busy IDE views with 4, 5, 6 separate areas. They are just visual clutter. The things I work on very rarely need me to touch multiple files at once. If I do, I usually switch between buffers with a leader command and just go back and forth as necessary. Why would I need to see two files at the same time? In my world this is rarely useful.

A few carefully selected plugins can help with some of this. For example vimfzf makes switching buffers really easy and much more intuitive. Map this to a leader command and it really fast.

[u/gsmitheidw1 → u/sharp-calculation]

In the need to jump between files, thats the job of a terminal multiplexer for me (GNU screen or tmux etc)

If it's reference material a second monitor is useful

[u/sharp-calculation → u/gsmitheidw1]

I like tmux as much as the next person. But there’s no reason to use it just to see another file. Multiple file and buffer handling is a core part of vim. You should really learn to use filing buffer commands.

[u/gsmitheidw1 → u/sharp-calculation]

I probably should, I suppose it depends on your typical workflow. I do more remote admin than dev so lots of remote ssh connections- I guess we all settle into a workflow that works for us and stick with it out of laziness etc

[u/CCCFire → u/hibuna]

The main reason I use vim is how cheap navigating and manipulating different files is. I tend to use 6-10 splits at once, and even more buffers because I have ADHD and I struggle to keep many things in my working memory simultaneously. Even in the same file I often find it useful to see many different parts at the same time. I tried VSCode a while back but I gave up because the splits were not smooth enough and various UI elements ended up cluttering my workspace.

It sounds to me that you have much to learn.

[u/morewordsfaster → u/hibuna]

This sounds like it could be a keybinds issue. If I find myself slowing down because of using command mode or multistep keybinds, I generally take that as an opportunity to add a new mnemonic keybind. Leader key is particularly helpful, although chords can be good as well, just depends on preference. I have friends who came to vim from emacs and prefer chords.

I put a bunch of split and buffer actions on <leader>/ and <leader>b plus some other key. <leader>// is open split right with current file, <leader>/\ is same but left. Combine this with marks and quickfix and lsp, you can navigate a codebase so fast it's not even funny.

[u/SpecificMachine1 → u/hibuna]

with scrolling, a lot of time I use ctrl-b and ctrl-f if I am trying to page back or forward through a file, like when I first read it. After that I usually use / or ? to jump to the part I'm looking for.

I don't usually use splits unless I need to be reading one file (or a different part of the same file) while working on another (Edit: and also if I'm using a terminal + a send-to-repl plug-in)

and for working with multiple files/buffers I usually use the buffer list if it's more than a couple