4 ms·

If anyone is considering moving editors, I was recently in the same boat and I can’t recommend enough lazyvim + the ebook “lazyvim for ambitious developers”. T

If anyone is considering moving editors, I was recently in the same boat and I can’t recommend enough lazyvim + the ebook “lazyvim for ambitious developers”. This gets you a fully featured vscode-like baseline (navigation, language integration, integrated terminal, the whole thing). 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. With this I was able to make neovim my daily driver at work after just a couple weekends playing with it.

railka 10mo ago
I think many people don't know or underestimate Zed. Native, fast, with extensions, with Vim mode support.
- inferiorhuman 10mo ago
  Or don't want. I don't want an AI infected editor.
  - pkstn 10mo ago
    Zed is much less AI-infected than VSCode. In fact, in Zed there’s a single button to disable all AI features.
    - mohas 10mo ago
      but doing that would you not end up with less than vscode?
- ClawsOnPaws 10mo ago
  And sadly it is also not accessible to screen readers. VS Code for all its flaws is really, really good for screen reader accessibility. In fact, I'd go as far as to say that it's not only one of the most accessible code editors we have, but one of the most accessible electron apps overall. So losing it to this Microsoft stuff would be a huge deal to anyone who relies on screen reader or accessibility tools. :(
- torben-friis 10mo ago
  The reason I didn't explore Zed is their for profit model. There might be awesome people and work behind it now, but I've already been burned enough times by rug pulls and shittyfication. I don't want to be planning another move 5 years from now.
- pjmlp 10mo ago
  Despite all its flaws, I am on Windows for work, and many projects have SDKs that have no clue Zed exists.
nmcost 10mo ago
I felt the same way about vim. I never had the patience to get started and configure everything to get the full benefits. I just switched over to Omarchy for my personal OS and I know that it comes with a pre-configured neovim (using lazyvim) setup that looks like a fully-fledged IDE. I personally have been using Helix as my editor at home and work. The fact that everything generally works on download is what got me using it.
inferiorhuman 10mo ago
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. For me Helix gets enough right out of the box I find myself reaching for it far more than I ever did with vi or Emacs. They're working on plugin support but I've not felt the need to investigate it at all.
- g947o 10mo ago
  Is there a good solution to managing "workspace", especially handling multi-folder workspace? I have a project where code lives in giant monorepo, and the files I edit don't have the same root (more precisely, the root is too large to open in the editor). I haven't found a good solution outside VSCode yet.
  - inferiorhuman 10mo ago
    Well the file picker can be limited to the current directory and its descendants, and the global search picker is by default. Beyond that, dunno.
skydhash 10mo ago
> 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
- kcoddington 10mo ago
  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.
  - Lapel2742 10mo ago
    >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.
    - torben-friis 10mo ago
      Honest question, what is it that you hate about modal editing?
      - rrgok 10mo ago
        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.
somenameforme 10mo ago
I think some of the big features of VSCode are the extensions and, equivalently, the nice debug support. I just started using VSCode about a week ago thanks to moving to a project that uses scons as its primary supported build tool, and I've learned to hate scons and love VSCode over that time. The completely manual tasks/launch/etc stuff is kind of weird at first, but then becomes amazing and far more convenient, after you get used to it. And the 'debugger' (kind of weird to frame it that way as its extension based, like everything) is amazing - extremely fast, great visualizations, and so on. How would vim compare?
- torben-friis 10mo ago
  I can't help you much, as currently I happen to use ruby at work and native debugging is enough - you can drop into an interactive console at a breaking point adding a single line, with no tooling. Here's the chapter on debugging in the book I mentioned if you want to take a look: https://lazyvim-ambitious-devs.phillips.codes/course/chapter-17/ https://lazyvim-ambitious-devs.phillips.codes/course/chapter...
  - tsimionescu 10mo ago
    > I happen to use ruby at work and native debugging is enough - you can drop into an interactive console at a breaking point adding a single line, with no tooling. If you've only ever used this type of debugging, you should really try out a real IDE debugger once. The difference in productivity when you can use your IDE to navigate to, say, the usages of a function and then just press a keyboard shortcut to put a breakpoint on the line with that usage is immense. Compare this to the native debug support: you have to leave the interactive debugger, move to your editor, find usages, note down the file name and line number, then go back to your interactive debugger and type a manual break command (break my_file.rb:2517 or something). All of that context switching and remembering is replaced by a single keyboard shortcut in Emacs, VS Code, or any other integrated debugger. And no, adding manual breakpoints in your source code is not simpler - what I'm describing works interactively while your code is already running, whereas a breakpoint statement requires you to restart the whole process.
giamma 10mo ago
How about switching from VS Code to VS Codium? Same experience without the microsoft telemetry. I suppose Copilot won't be included due to licensing constraints.
- torben-friis 10mo ago
  How does the extension model work with MS? I did a similar move to chromium and eventually had to move to firefox when they pulled the plug on ad blockers.
  - duskdozer 10mo ago
    There's https://open-vsx.org/ https://open-vsx.org/. I've seen in the repo people talk about tweaking workarounds to use the proprietary MS stuff.
worksonmine 10mo ago
I suggest the opposite and not starting with all the plugins and instead try to learn the vim way of doing things. Being too locked in to the old ways could prevent discovering all the great things vim can do. The examples you mention already exist. - navigation: plenty of native navigation in neovim, does lazy add anything specific? - language integration: lsp, requires config sure but git clone isn't much work. - integrated terminal: just run `:term` Learning to think in vim means unlearning a lot of old habits. Today I only use fzf.vim, nvim-lspconfig and a theme, not even a plugin manager (I will migrate to the native one that's in nightly when it reaches stable though). Pretty much vanilla Neovim. I'm considering trying nvim-dap to get better debugger support but so far I'm fine with :termdebug for the languages it supports (c/go/rust just works). When I find something I want vim to do I start with a keybinding, then a function, and maybe if it's complex add a plugin. Adding half of the available plugins just because creates an unnecessary attack vector you now have to keep an eye on.
- torben-friis 10mo ago
  I do get the benefit of not depending on plugins, really. Long term my current config could rot (abandoned projects, moving dependencies, etc), while a simple config is stable. But I'm happy removing dependencies one at a time. For example, <leader> ft toggles a terminal in a bottom split. This is familiar enough that I knew I could rely on it whenever needed. Could I have used :term and manually set splits each time? or learn tmux? or use ctrl+z and fg to move back and forth ? Sure, but that's extra cognitive load. Maybe I want to focus first on becoming fluid with regex for search and replace, or improving the flow for running unit tests, or get used to using macros as a replacement for multicursor. There's a lot of gaps to cover, each small enough that it's "just do X" for a veteran, but enough when added up that I would much rather pay the cost gradually.
  - worksonmine 10mo ago
    > Could I have used :term and manually set splits each time? That's when you know you want to create a keybinding, here's a suggestion that opens a split below the current window with 10% height and starts a terminal: `nnoremap <leader>ft :belowright 10 split | terminal<CR>` But is a terminal really what you want or do you just want to run a command? Maybe just `:!command` is enough 9/10 times that you reach for <leader>ft? In that case a common binding is `nnoremap ! :!` which puts you in that mode with a single key. > get used to using macros as a replacement for multicursor This exact example was how I realized the vim way is better than my assumptions. I used to install a multicursor plugin and bind to Ctrl+d because that's what I knew. When I learned macros and s/old/new it became irrelevant. You seem to already know a lot of the possibilities that you can learn, I didn't and discoverability in vim isn't great. So I just forced myself to search for whatever I didn't know how to achieve and many times ended up learning something extremely powerful. Today I have all sorts of useful little functions, <leader>m is make, or gcc if no Makefile exists. And now I've extended it to generate mermaid charts in markdown files and open them in my imageviewer and so on. That's the true power of vim to me, adding standard tools from the system in keybindings and just getting it to do things MY WAY, not how I was taught it should work. It follows the unix philosophy and batteries included is by definition not part of that mentality.

railka 10mo ago

I think many people don't know or underestimate Zed. Native, fast, with extensions, with Vim mode support.

inferiorhuman 10mo ago
Or don't want. I don't want an AI infected editor.
- pkstn 10mo ago
  Zed is much less AI-infected than VSCode. In fact, in Zed there’s a single button to disable all AI features.
  - mohas 10mo ago
    but doing that would you not end up with less than vscode?
ClawsOnPaws 10mo ago
And sadly it is also not accessible to screen readers. VS Code for all its flaws is really, really good for screen reader accessibility. In fact, I'd go as far as to say that it's not only one of the most accessible code editors we have, but one of the most accessible electron apps overall. So losing it to this Microsoft stuff would be a huge deal to anyone who relies on screen reader or accessibility tools. :(
torben-friis 10mo ago
The reason I didn't explore Zed is their for profit model. There might be awesome people and work behind it now, but I've already been burned enough times by rug pulls and shittyfication. I don't want to be planning another move 5 years from now.
pjmlp 10mo ago
Despite all its flaws, I am on Windows for work, and many projects have SDKs that have no clue Zed exists.

nmcost 10mo ago

I felt the same way about vim. I never had the patience to get started and configure everything to get the full benefits. I just switched over to Omarchy for my personal OS and I know that it comes with a pre-configured neovim (using lazyvim) setup that looks like a fully-fledged IDE. I personally have been using Helix as my editor at home and work. The fact that everything generally works on download is what got me using it.

inferiorhuman 10mo ago

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. For me Helix gets enough right out of the box I find myself reaching for it far more than I ever did with vi or Emacs. They're working on plugin support but I've not felt the need to investigate it at all.

g947o 10mo ago
Is there a good solution to managing "workspace", especially handling multi-folder workspace? I have a project where code lives in giant monorepo, and the files I edit don't have the same root (more precisely, the root is too large to open in the editor). I haven't found a good solution outside VSCode yet.
- inferiorhuman 10mo ago
  Well the file picker can be limited to the current directory and its descendants, and the global search picker is by default. Beyond that, dunno.

skydhash 10mo ago

> 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

kcoddington 10mo ago
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.
- Lapel2742 10mo ago
  >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.
  - torben-friis 10mo ago
    Honest question, what is it that you hate about modal editing?
    - rrgok 10mo ago
      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.

somenameforme 10mo ago

I think some of the big features of VSCode are the extensions and, equivalently, the nice debug support. I just started using VSCode about a week ago thanks to moving to a project that uses scons as its primary supported build tool, and I've learned to hate scons and love VSCode over that time. The completely manual tasks/launch/etc stuff is kind of weird at first, but then becomes amazing and far more convenient, after you get used to it. And the 'debugger' (kind of weird to frame it that way as its extension based, like everything) is amazing - extremely fast, great visualizations, and so on. How would vim compare?

torben-friis 10mo ago
I can't help you much, as currently I happen to use ruby at work and native debugging is enough - you can drop into an interactive console at a breaking point adding a single line, with no tooling. Here's the chapter on debugging in the book I mentioned if you want to take a look: https://lazyvim-ambitious-devs.phillips.codes/course/chapter-17/ https://lazyvim-ambitious-devs.phillips.codes/course/chapter...
- tsimionescu 10mo ago
  > I happen to use ruby at work and native debugging is enough - you can drop into an interactive console at a breaking point adding a single line, with no tooling. If you've only ever used this type of debugging, you should really try out a real IDE debugger once. The difference in productivity when you can use your IDE to navigate to, say, the usages of a function and then just press a keyboard shortcut to put a breakpoint on the line with that usage is immense. Compare this to the native debug support: you have to leave the interactive debugger, move to your editor, find usages, note down the file name and line number, then go back to your interactive debugger and type a manual break command (break my_file.rb:2517 or something). All of that context switching and remembering is replaced by a single keyboard shortcut in Emacs, VS Code, or any other integrated debugger. And no, adding manual breakpoints in your source code is not simpler - what I'm describing works interactively while your code is already running, whereas a breakpoint statement requires you to restart the whole process.

giamma 10mo ago

How about switching from VS Code to VS Codium? Same experience without the microsoft telemetry. I suppose Copilot won't be included due to licensing constraints.

torben-friis 10mo ago
How does the extension model work with MS? I did a similar move to chromium and eventually had to move to firefox when they pulled the plug on ad blockers.
- duskdozer 10mo ago
  There's https://open-vsx.org/ https://open-vsx.org/. I've seen in the repo people talk about tweaking workarounds to use the proprietary MS stuff.

worksonmine 10mo ago

I suggest the opposite and not starting with all the plugins and instead try to learn the vim way of doing things. Being too locked in to the old ways could prevent discovering all the great things vim can do. The examples you mention already exist. - navigation: plenty of native navigation in neovim, does lazy add anything specific? - language integration: lsp, requires config sure but git clone isn't much work. - integrated terminal: just run `:term` Learning to think in vim means unlearning a lot of old habits. Today I only use fzf.vim, nvim-lspconfig and a theme, not even a plugin manager (I will migrate to the native one that's in nightly when it reaches stable though). Pretty much vanilla Neovim. I'm considering trying nvim-dap to get better debugger support but so far I'm fine with :termdebug for the languages it supports (c/go/rust just works). When I find something I want vim to do I start with a keybinding, then a function, and maybe if it's complex add a plugin. Adding half of the available plugins just because creates an unnecessary attack vector you now have to keep an eye on.

torben-friis 10mo ago
I do get the benefit of not depending on plugins, really. Long term my current config could rot (abandoned projects, moving dependencies, etc), while a simple config is stable. But I'm happy removing dependencies one at a time. For example, <leader> ft toggles a terminal in a bottom split. This is familiar enough that I knew I could rely on it whenever needed. Could I have used :term and manually set splits each time? or learn tmux? or use ctrl+z and fg to move back and forth ? Sure, but that's extra cognitive load. Maybe I want to focus first on becoming fluid with regex for search and replace, or improving the flow for running unit tests, or get used to using macros as a replacement for multicursor. There's a lot of gaps to cover, each small enough that it's "just do X" for a veteran, but enough when added up that I would much rather pay the cost gradually.
- worksonmine 10mo ago
  > Could I have used :term and manually set splits each time? That's when you know you want to create a keybinding, here's a suggestion that opens a split below the current window with 10% height and starts a terminal: `nnoremap <leader>ft :belowright 10 split | terminal<CR>` But is a terminal really what you want or do you just want to run a command? Maybe just `:!command` is enough 9/10 times that you reach for <leader>ft? In that case a common binding is `nnoremap ! :!` which puts you in that mode with a single key. > get used to using macros as a replacement for multicursor This exact example was how I realized the vim way is better than my assumptions. I used to install a multicursor plugin and bind to Ctrl+d because that's what I knew. When I learned macros and s/old/new it became irrelevant. You seem to already know a lot of the possibilities that you can learn, I didn't and discoverability in vim isn't great. So I just forced myself to search for whatever I didn't know how to achieve and many times ended up learning something extremely powerful. Today I have all sorts of useful little functions, <leader>m is make, or gcc if no Makefile exists. And now I've extended it to generate mermaid charts in markdown files and open them in my imageviewer and so on. That's the true power of vim to me, adding standard tools from the system in keybindings and just getting it to do things MY WAY, not how I was taught it should work. It follows the unix philosophy and batteries included is by definition not part of that mentality.