cross-posted from: https://lemmy.ml/post/9648279

I would like to premise this with the following:

  • The best approach is probably just testing out each and every editor that interests me until I’ve found what works best for me.
    • However, I wonder to what degree a test as such would be representative when the likes of Emacs and (Neo)Vim are considered; both of which are known for being a life time learning process.
  • I don’t literally expect Emacs or (Neo)Vim to be drop-in replacements for any IDE. Some of the most basic IDE-functions are absent by default and some (perhaps more advanced) functionality might simply not be attainable at all.
  • I am not interested in anything that remotely resembles a flame war. The community at Lemmy has so far been very kind to me; let’s keep it that way 😜.

Motivation

I’ve had experiences with Atom, VS Code and some of Jetbrains’ IDEs like Pycharm and Rider. While I’ve been generally content with all of them, it leaves a bad taste in my mouth whenever I’m forced to switch IDEs because their lifetimes and/or lack of extensibility doesn’t allow me to responsibly continue using them. As such, I’m interested in a long time investment that will grow as I will. Both Emacs and (Neo)Vim have passed the test of time and I honestly don’t think they’ll cease to exist in the upcoming decades, that’s why I would love to start using either one of them.

Furthermore, Vi(m) keybindings seem to be somewhat ubiquitous and almost any IDE offers some support. As such, improving my Vi(m)-game should only net-positive my productivity (at least eventually). Also, fluency will benefit me whenever I’m remote accessing any random server as they will always have Vi(m) installed. Thankfully, this doesn’t force me to use Vi(m) (or Neovim) just yet, because Emacs offers with Evil perhaps the single best Vi(m) implementation; outside of native Vi(m)*.

My setup:

  • I’m on a custom image of uBlue using their startingpoint as template. For those unaware; an oversimplification would be that it is Fedora Silverblue with some extras.
  • As such, I would like to have my developer environments local and have used Distrobox to that extent using steps similar to the ones outlined over here. But I’m not married to that specific way of utilizing local containers. So please feel free to recommend me something that’s at least as good.
  • If I go for Emacs, then I will definitely rely on Evil.
  • If possible, I would like to use it for C#, Python and Rust. Furthermore, I engage in editing Bash scripts, Dockerfiles, Linux config files, texts written in Latex and/or Markdown and other files written in Nix or JSON. As both are very extensible, I don’t expect any issues, but I might be wrong.

Questions:

  • First of all, does it make sense for me to only consider these two?
  • Can the split between Vim and Neovim be interpreted as the first schism and as such be a forebode for what’s yet to come?
  • Google Trends suggests that Neo(Vim) is ever-popular. On the other hand; not only is Emacs relatively less popular, but its popularity seems to be slightly declining. Should this worry me regarding their long-time future? Especially considering that a thriving community is literally the lifeline for both of them.
  • For those that have used both extensively, which one do you prefer (if any) and why?
  • While I understand that the power of both of them lies primarily in how one can literally make them behave however suits their workflow best. Therefore, the use of premade configs and/or starter kits/distributions should (ideally) only be used either temporary or as a starting point. However, at this point, they provide a decent showcase of what each ‘platform’ has to offer. So:
  • throwawayishOP
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    As a long-time Vi user I would highly recommend giving it a shot for a solid month to see if it clicks for you.

    Makes sense. Thanks for the tip!

    Emacs is dead near as I can tell.

    Am I correct to assume that you think that Emacs is dying? If so, would you be so kind to elaborate on why you think that’s the case?

    • atzanteol@sh.itjust.works
      link
      fedilink
      arrow-up
      4
      ·
      1 year ago

      My comment on Emacs is a bit flip - but it’s based on what I’ve seen and from my biased vi-using POV. Almost every IDE or developer-focused app I use has some sort of Vi keybinding either available as a plugin or built-in. And they’re often pretty good. Even joplin which is a note-taking app has Vi keybindings built in (though to be fair it also supports emacs keybinds).

      If anything Vi keybindings have become more popular over time not less. “back in the day” getting any sort of Vi keybindings working with IDEs was either impossible or painful and limited. These days it’s a checkbox. The nice thing is I can take a good sub-set of the Vi bindings between many editors and IDEs. Ideavim’s implementation is quite good and even supports vim macros which are amazing once you get the hang of them.

      • Euphoma
        link
        fedilink
        English
        arrow-up
        2
        ·
        1 year ago

        Emacs keybindings are in the terminal and are in MacOS (from what I’ve heard online).

        • atzanteol@sh.itjust.works
          link
          fedilink
          arrow-up
          3
          ·
          1 year ago

          This is true. The ctrl+a, ctrl+e and ctrl+l stuff is very emacs-like.

          You can actually set bash to use a vi mode as well (set -o vi). Though I’ve found it to be annoying for use on the CLI for some reason.

      • throwawayishOP
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        Ah okay. It has become a lot more clear what you meant. And I agree; implementation for Vi(m) keybindings is ubiquitous while the same can’t be said for Emacs’. But, while Vi(m)‘s keybindings define a lot of what it is and why people love to use it, the same simply can’t be said for Emacs’ keybindings. I’m sure there’s someone out there that absolutely loves it, but it doesn’t come close to how Emacs’ modeless nature allows almost limitless extensibility or how ‘smart’, ‘useful’ and just plain excellent its org-mode is.