When I was in high school I found Sublime Text and learned “multiple cursors”. Since then, I’ve transitioned to vscode, mainly because I need LSP (without too much configuration work) for my work.

I keep hearing about how modal editing is faster and I would like to switch to a more performant editor. I’ve been looking at helix, as the 4th generation of the vi line of editors. Is anyone using it? Is it any good for the main code editor?

The problem that I have is that learning new editing keybindings would probably take me a month of time, before I get to the same amount of productivity (if I ever get here at all). So I’m looking for advice of people who have already done that before.

My code editing does involve a lot of “ctrl-arrow” to move around words, “ctrl-shift-arrow” to select words, “home/end” to move to beginning/end of the line, “ctrl-d” for “new cursor at next occurrence”, “shift-alt-down” for “new cursor in the line below”, “ctrl-shift-f” for “format file” and a few more to move around using LSP-provided “declaration”/“usages”.

I would have to unlearn all of that.

Also, I do use “ctrl-arrow” to edit this post. Have you changed keybindings in firefox too?

  • mrkite@programming.dev
    link
    fedilink
    arrow-up
    1
    ·
    10 hours ago

    I switched to helix last year after over twenty years of vim. I really like helix, but it did take some getting used to. Using multiple cursors instead of repeated commands etc

  • Hawk@lemmynsfw.com
    link
    fedilink
    arrow-up
    6
    ·
    2 days ago

    I left a comment before but I thought I’d address the concerns around modal editing. It’s not as hard as it seems, once you wrap your head around hjkl you’ll be fine.

    Use Lazyvim to get started and install the vim plugin in vscode. Try it qutebrowser too you won’t look back honestly.

    Consider helix too, it works out of the box but the keys are slightly different to Vim which makes it challenging for me.

    • verstra@programming.devOP
      link
      fedilink
      arrow-up
      3
      ·
      1 day ago

      I’ve tried helix and used it for work today. At first, it was super slow, relearning how to jump between buffers, but at the end of the day, i got decent at it.

      But I cannot hjkl. It’s just unnatural. The moment I stop thinking about it, my hand is back at arrow keys.

      • Zykino@programming.dev
        link
        fedilink
        arrow-up
        3
        ·
        1 day ago

        I’m using helix with arrows. On a standard layout its not so great, but on my main keyboard I have a layer with arrow keys near hjkl. So I can use that on all software even on my BÉPO (DVORAC like) layout.

  • zaphodb2002@sh.itjust.works
    link
    fedilink
    arrow-up
    13
    ·
    edit-2
    2 days ago

    I started with neovim because I hate my laptop’s mousepad, and that’s often pushed as a benefit of modal editors, not needing the mouse. After I used it for a while I found that not only could you do stuff easily that would be difficult in, say vs code, but it was also pretty fun. It’s honestly a bit of a power trip sometimes, makes me feel like a 90s tv hacker. Also plugins. So many neat plugins.

  • lonesomeCat@lemmy.ml
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    1
    ·
    1 day ago

    Helix because it’s easy to setup and hassle free, and it runs well on my 2009 ASUS Eee

  • kekmacska@lemmy.zip
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    1
    ·
    1 day ago

    vscodium. Easy to use for beginners (i’m a beginner too), fully open-source, all microsoft tracking binaries removed. Aviable for Windows, Linux, macOS, darwin, propably bsd, or even as a webview, and supports a lot of architectures. Great for intrepeted languages, but supports compiled ones too

  • Hawk@lemmynsfw.com
    link
    fedilink
    arrow-up
    7
    ·
    2 days ago

    Neovim, Emacs, Helix and VSCode.

    Zed has been fun.

    VsCode and Pycharm are just too slow for me. You need a very fast machine with a lot of RAM.

  • Realitaetsverlust@lemmy.zip
    link
    fedilink
    English
    arrow-up
    8
    ·
    2 days ago

    I swapped to neovim 10 months ago. Haven’t looked back. Actually, I’ve looked back a LOT for the first few weeks because I couldn’t figure out how to do certain things. But the more you learn the better it becomes. Not needing your mouse is SO good.

  • ZeroOne@lemmy.world
    link
    fedilink
    arrow-up
    3
    ·
    edit-2
    2 days ago

    I use Lapce, which could be a great native alternative to VS-Code (Also it’s built with Rust, this is for the Rustaceans)

    There was a time where I used Geany as well, I still like it

  • PokerChips@programming.dev
    link
    fedilink
    arrow-up
    10
    ·
    2 days ago

    NeoVim plus tmux.

    Great multi dimensional way of operating. You have access to the terminal and your ide.

    It’s beautiful

  • morrowind@lemmy.ml
    link
    fedilink
    arrow-up
    29
    arrow-down
    1
    ·
    3 days ago

    I keep hearing about how modal editing is faster and I would like to switch to a more performant editor.

    Honestly I’ve yet to hear a good argument for this. It feels like such a major investment to switch to vi-like editors, I need a pretty good argument before considering it

    Also a good argument for “why does it matter”? Speed of editing is rarely a bottleneck when editing code. If it is, you might want to consider why your code is so verbose and repetitive to make it so

    • mrkite@programming.dev
      link
      fedilink
      arrow-up
      1
      ·
      9 hours ago

      Speed of editing is rarely a bottleneck when editing code

      It’s not just that though, its moving around your code. Being able to jump between matching brackets, follow references etc. it’s just quicker and easier with a modal editor.

    • pooberbee (they/she)@lemmy.ml
      link
      fedilink
      arrow-up
      13
      ·
      3 days ago

      Modal editing for just raw text input would actually be slower, because you also enter and leave Insert Mode. I find it’s very fast and powerful for navigating around the text, which you probably do a lot more than actually editing it. And when it does come to editing, there are a lot of higher-level tools (at least in Vim) for accomplishing things more quickly, like the ‘s’ command and ‘q’ macros.

      I think getting into a mental “flow” state is really valuable, and muscle memory is important for being able to stay there. If your muscle memory is to navigate around using the mouse, that’s great, but Vim feels faster to me.

    • jeffhykin@lemm.ee
      link
      fedilink
      arrow-up
      4
      ·
      edit-2
      2 days ago

      Input speed is not “just” input speed.

      Note: I’m not about to argue for or against modal editors, I just want to answer: why is input speed really really really important, when (we agree) its not a big percent of total time.

      5min at 80mph over a bumpy dirt path is very very different than 5min of flat smooth straight driving. And not just because of effort.

      A senior and junior dev could spend the same amount of time to rename a var across 15 files, move a function to a new file, comment out two blocks, comment one back in, etc. But. When I try to have a conversation while they do that, or when I change my mind and tell the junior to undo all that, its a massive emotional drain on the junior.

      But effort isn’t the whole picture either: speed is a big deal because pausing a conversation/mental thought for 5 seconds while you wait to finish some typing, is incredibly disruptive/jarring to the thought-process itself. That’s how edge cases get forgotten, and business logic gets missed.

      Slower input is not merely input time loss, it also creates time loss in the debugging/conceptualizing stages, and increases overall energy consumption.

      If the input is already fast enough that there’s no “pauses in the conversation” then I’d agree, there’s not much benefit in increasing input speed further. BUT there’s almost always some task, like converting all local vars (but not imported methods) in a project to camel case, that are big enough to choke the conversation, even for a senior dev. So there’s not necessarily a “good enough” point because it’s more like decreasing how often the conversation gets interrupted.

    • verstra@programming.devOP
      link
      fedilink
      arrow-up
      2
      arrow-down
      1
      ·
      3 days ago

      That’s a good argument. The editing speed is not the limiting factor in my workflow.

      Honestly, I think my interest for modal editing is a bit irrational. Maybe I don’t want to be a normie, using the default keybindings :D