> I had tried many times to switch to vim/emacs and the initial barrier to get a workable system always kept me from pushing forward
What’s that initial barrier? Both Vim and emacs has great documentation that includes a tutorial, a guide, and a reference.
What people often defines as workable system is replicating their old editors instead of learning the current one. Like adding a file tree on the side
>What people often defines as workable system is replicating their old editors instead of learning the current one. Like adding a file tree on the side
Well, kinda. I define a workable system as a system I, personally, can work with straight away, with a minimum loss of productivity. It is not at all meant as a judgement on how good plain vim/emacs are.
This workability indeed might require temporally replicating old habits while I learn the new ones, which lazyvim does. Vscode-like file trees, global search, or integrated terminal, for example.
It's also about discoverability, like the helpers shown through which-key. And the guarantee that a set of default plugins play well with each other, so that I can leave toying with the config for whenever I have the time.
Some people might think this is a crutch for properly learning the tool, but this is not my experience. I'm much more likely to get comfortable with vim and learn further if I can be in it 8 hours a day from the start. At first I used the integrated terminal to run git commands, now I invoke lazygit, which I love. At first I used the file tree to navigate, now I have custom commands to bring a file and its test suite side to side on a keypress. This gradual curve is what I was missing earlier.
Yeah, for most of us in the real world, we can't afford to be way underproductive for a week while we learn and set up our new editor from scratch. Learning vim is one of the greatest gifts I think I gave myself, and I'm extremely glad I did it, but it was not easy. A more gradual curve or even a crutch is completely fine in my opinion. I've seen plenty of people get started with vim just by putting them key bindings in their IDE and getting used to the motions, and then gradually moving over. The main key is to iterate, and not stagnate
> This workability indeed might require temporally replicating old habits while I learn the new ones, which lazyvim does
I'm not judging your for it, but to me that sounds like learning the violin by plucking the strings like a guitar. You're increasing the learning period by following old habits which may even be harmful.
I think it's better to just use the new editor sparingly, learning what you need, then switch fully once you're comfortable. A filetree is never necessary unless you're actually exploring and a file manager would be better for that. Vim has global search with `grep` and the terminal is available through `ctrl-z` and the `:terminal` command.
I've seen people touting Neovim setup that are just making things complex and fragile for no reason.
>that sounds like learning the violin by plucking the strings like a guitar.
I'd compare it more to learning photography without going for manual aperture and developing analog film straight away. You'll have a better experience if you learn stuff like framing with an automated camera that frees you to shoot a hundred pictures daily and focus on a certain skill.
I am increasing the learning period, that much is true. But if I can make use of my daily 8 hours of work as practice, that makes up for the delay, because I can get much more practice.
Maybe a student or a hobbyist can afford to spend 3 minutes nailing the regex while they learn to search and replace, I just can't be fighting that kind of friction regularly at work.
IMO, it’s still the wwrong approach. Vim and Emacs are just editors. Very much like Notepad. You don’t have to learn the extra stuff.
Once you are comfortable with basic notepad-like usage, you can then learn more advanced features. But emacs and vim are different from VSCode because those advanced things are supposed to be tweaked to personal preferences, not be handed down from high. When you start with something like Lazyvim, you’re missing on everything that makes vim, vim. You just have a walmart version of VSCode.
Learning an entirely new editor is a barrier. Documentation or not, that's brand new muscle memory you have to develop alongside the actual task of coding.
I get that using vim typically includes obsessive forms of efficiency, but some people just want to focus on coding in a way that's comfortable to them. Sometimes that means having a side panel.
>Sometimes that means having a side panel.
I do not even need that. Modal editing is enough to keep me away from all the VI clones. I hate it with a passion.
I have a fully customized Emacs that I use for anything Lispy and it's great for that purpose but everything else is just "ok".
I try to use Zed but since it is a commercial offering it is just a matter of time until it gets entshitified too.
Vscode is/was really good but it seems to get worse and it's Microsoft.... I run out of editors it seems.
Honest question, what is it that you hate about modal editing?
> Honest question, what is it that you hate about modal editing?
It's annoying. I'm fine with being in one mode. I'm fine with selecting 7 lines and typing "whatever". I hate "7ddiwhatever<esc>".
And yes, it may be the case that you are faster in VI(m) than I am in (choose the editor) but that doesn't matter. For me speed of typing is never critical.
I tried Helix and Kakoune too. They all have the same problems.
First. It adds friction. Every damn time I need to write, I forget to enter insert mode. You have no idea how many times I ended up with a strange buffer. Hopefully there is undo. But it gets boring fast. I need to write as soon I enter the editor. I don't need to move the cursor to read the text that visible on the current page.
Second, how the hell I'm supposed to make small movements when I'm in insert mode, with the arrow keys? Like move cursor to the left by 3 chars. Do I enter normal mode, press l 3 times. Or delete the whole word and rewrite it?
Third. Why some movements are symbols? Like, line ending is $. Beginning of line is 0. so much so for home row movements.
Fourth. Could never remember if f or t includes the char I'm looking for.
Fifth. How cumbersome is to press ESC on the top left corner every damn time. Yes, there exists Ctrl+[. But still. So much so - again - homerow movement.
Not directly related to modal editing.
Sixth. I could not make copy/paste work reliably in remote a linux server from a Windows machine via SSH. Hell, I could not make it work with WSL2.
Sevent. Debuggers sucks. There is no comparison to JetBrains Debugger GUI. Not even VSCode come close to it.
Sorry for the rant.
The rant is fine. I'll just provide some explanation.
First: Vim comes from vi, which is a visual mode for ex, which is a supercharged version of ed, which is (the standard editor) a line editor. With ed, you don't really write, you issue commands that does things to the file. Think of the file as a long roll of paper and the program as an assistant. So a command could be "replace your on line 14 with you're" or "delete line 34 to 45". Ex added more commands, Vi made it interactive, and Vim added even more features (syntax highlighting, scripting, location list,...). But still the same mode of interaction remains. The cursor is what you control. It's not just an indicator where the next character will appear or be deleted. It's the starting point of more powerful interactions.
Second. You're not supposed to move the cursor that much in insert mode. For 3 characters to the left, I just backspace and rewrite. For more, I go to normal mode and use F, f, T, or t which will land me to the character I want. Then I can use something like x (delete character) or r (replace character) without having to enter insert mode. There's a lot of movement beside hjkl, and I rarely uses h or l for things that further away than two characters.
Third. There's not a lot of key on the keyboard. $ is end of line in most regex dialect, ^ is beginning of line which would be actually the first character, but most people would assume it's the first non-whitespace character, so that's how they went. In C, curly braces mark blocks of code, so it's a small leap to use it for blocks of text, aka paragraphs.
Fourth. My mnemonics are f (find) and t (to). The latter does not include the character.
Firth. A lot of people remaps the caps lock to either Ctrl or ESC.
Sixth. They're different computers so there's no shared clipboard. Sharing information between the clipboard can be done using escape sequences, but I've never bother to. I just maximize the current buffer so I can use the terminal selection. And if I wanted more than a screen (dmesg), I'd pipe the command to a file and then download that file with sftp.
Seventh. Jetbrains only have debuggers for a handful of programming languages while `printf` is universal. And there's no law forbidding installing an IDE alongside your editor.
I think if you google ADM-3A terminal keyboard you'll see half your issues explained :)
There's a ton of historical baggage there. Thankfully, a bit of it can be resolved by setting esc and/or ctrl in caps lock.