this post was submitted on 23 Dec 2023
42 points (90.4% liked)

Linux

48190 readers
904 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

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:
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 1 points 10 months ago (1 children)

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.

[–] [email protected] 2 points 10 months ago (1 children)

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.

[–] [email protected] 2 points 10 months ago (1 children)

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.

[–] [email protected] 2 points 10 months ago (1 children)

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.

[–] [email protected] 2 points 10 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!