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:
  • Corngood@lemmy.ml
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    Or is the usage of Spacemacs primarily attributable to it coming earlier to the scene?

    Yeah, pretty much just that. If was to start again now I’d consider other options, but I have no serious complaints about spacemacs. I probably would have never got into Emacs at all if I had to start with vanilla.

    Furthermore, as you’re using it in “VI mode”, would it be fair to assume that you’ve got some experience/history with Neo(Vim) as well? If so, what led you to making the switch from (Neo)Vim to Emacs?

    Yeah, I used VIM (and I still do when I’m in an unfamiliar environment), but only before neovim existed. IMO Lisp is what makes Emacs great, and vimscript is (was?) an absolute nightmare for anything complex. I don’t think lua is a bad language, but I’ll still take Lisp any day for this purpose.

    I’ve also got my concerns related to what degree the containers can be sandboxed. Do you happen to have some insights on this?

    What I described isn’t using containers. Nix just provides an environment for processes to run in, and direnv-mode ensures it’s using the right environment for a given buffer in Emacs. So for example I don’t have OmniSharp or dotnet in my user $PATH, but they are provided by the nix expression in a particular project directory. That allows lsp-mode to start OmniSharp as a language server, or I can run dotnet build using the Emacs compile command.

    You can define containers with nix and manage them with nixos-container. I do that for testing server deployments, or running sandboxed services, but I’ve never needed something that complex for a dev shell.

    • throwawayish@lemmy.mlOP
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      I probably would have never got into Emacs at all if I had to start with vanilla.

      Very interesting. I assume this is due to the amount of effort that would have been required for it to acquire some of the functionality you were expecting out of it. Am I right?

      IMO Lisp is what makes Emacs great, and vimscript is (was?) an absolute nightmare for anything complex. I don’t think lua is a bad language, but I’ll still take Lisp any day for this purpose.

      This is actually a great point that I somehow completely ignored so far. I intend to put my teeth in GNU Guix at some point in the future. As Guile Scheme and Lisp are -to my knowledge- at least in some way related, using Emacs should at least provide an excellent platform for me to get accustomed to what it is yet to come. Thanks for mentioning that!

      What I described isn’t using containers. Nix just provides an environment for processes to run in, and direnv-mode ensures it’s using the right environment for a given buffer in Emacs. So for example I don’t have OmniSharp or dotnet in my user $PATH, but they are provided by the nix expression in a particular project directory. That allows lsp-mode to start OmniSharp as a language server, or I can run dotnet build using the Emacs compile command.

      That sounds very compelling! Thanks for that insight! Perhaps I should stop procrastinating and get on with learning Nix 😅.

      You can define containers with nix and manage them with nixos-container. I do that for testing server deployments, or running sandboxed services, but I’ve never needed something that complex for a dev shell.

      Yet another reason in support of learning Nix.

      • Corngood@lemmy.ml
        link
        fedilink
        arrow-up
        2
        ·
        11 months ago

        I assume this is due to the amount of effort that would have been required for it to acquire some of the functionality you were expecting out of it. Am I right?

        I didn’t really understand what Emacs was at the time, I just got fed up with trying to make vim into an IDE. Out of the box, spacemacs had good language support, modal editing, and looked ‘modern’.

        What I love about Emacs now is Lisp and the package ecosystem. I have 396 packages installed, and many of them interact in quite complex ways. When I do a package upgrade it pretty much pulls the latest from the development branch of each package. Some packages haven’t been changed in 10 years, some are changed daily. It’s bleeding edge everything, and things don’t actually break that much. Lisp makes for (obviously IMO) beautiful, simple code, so most packages are a pleasure to fix, extend, or automate.

        I intend to put my teeth in GNU Guix at some point in the future.

        Me too, but I nix has served me well, so I haven’t been motivated.

        • throwawayish@lemmy.mlOP
          link
          fedilink
          arrow-up
          2
          ·
          11 months ago

          Thank you so much for your insights! Much appreciated!

          Some packages haven’t been changed in 10 years, some are changed daily. It’s bleeding edge everything, and things don’t actually break that much. Lisp makes for (obviously IMO) beautiful, simple code, so most packages are a pleasure to fix, extend, or automate.

          I want to have a better idea for much time is spend on ‘management’; fix, extend and/or automate etc.

          • Corngood@lemmy.ml
            link
            fedilink
            arrow-up
            2
            ·
            11 months ago

            I want to have a better idea for much time is spend on ‘management’; fix, extend and/or automate etc.

            Not that much really. I usually upgrade everything once a month or so. The last couple of times were smooth. I think the last problem I hit was:

            https://github.com/emacs-lsp/lsp-mode/issues/4153

            This was actually triggered by upgrading omnisharp, which started sending a new notification that lsp-mode didn’t explicitly ignore.

            By the time I hit it, that issue had already been reported, so I was able to quickly work around it with a snippet in my main config. I could have also just rolled back omnisharp.

            Most problems I’ve had have been solved by upgrading spacemacs to latest.

            • throwawayish@lemmy.mlOP
              link
              fedilink
              arrow-up
              2
              ·
              11 months ago

              Honestly, that’s very encouraging! Thank you so much for providing me with very valuable insights and information! Have a good one! Cheers!