I’m a shell user too, but as programming languages I would rate Bash utter garbage. Fine for little piping but for longer scripts I will be reaching for Haskell.
I do a bit of programming. Git help is about terminal commands. There are graphical front ends but I have to learn how to use them. I use terminal also for package management for the same reasons.
I’d say is similar with any source control software. It’s the same with me and Fossil. (And, granted, there are less plugins to support Fossil in IDEs; the one in Visual Studio Code/Codium does OK.)
In what way? Like a home partition?
Home should just be a folder you can copy over in most cases.
If it’s a separate partition, most distros can just install to the other partitions without overwriting the home partition.
One of the other commenter made the analogy of being in a restaurant. With a mouse you can only point and grunt at things to communicate when you want. A terminal let’s you speak out your order and any other requests you might have.
I’m actually using nvim for rust development and it’s really fucking great but I’ve been using vi for like 25 years so for me the only issue was configuration, the editor is just natural for me. If you also have to learn the editor I don’t know what your experience will be.
As for configuring it for development I started with spacevim and managed with half the functionality normal IDE provides for quite some time. The experience was still good. About 6 months ago I set up nvim and now I have everything I need. I think setting up nvim for rust was as complicated as setting up spacevim. Spacevim provides way more out of the box but changing configuration is not easy at all.
I don’t worry about vim/nvim “schism”. The support is still great.
I would say just go with nvim, spend a week to set it up and don’t get too obsessive if small things don’t work. Enjoy the amazing responsiveness and great editor and you will figure out everything eventually. And if you have any questions just ask. I can share my config.
As for configuring it for development I started with spacevim and managed with half the functionality normal IDE provides for quite some time. The experience was still good. About 6 months ago I set up nvim and now I have everything I need. I think setting up nvim for rust was as complicated as setting up spacevim. Spacevim provides way more out of the box but changing configuration is not easy at all.
Would it be fair to assume that the switch from SpaceVim to Neovim was due to how difficult changing its configuration was to better suit your needs? Would you say this is SpaceVim’s fault? Or rather Vimscript is to be blamed?
I don’t worry about vim/nvim “schism”. The support is still great.
I also meant it in the sense that perhaps later down the line something else will come out to ‘replace’/‘improve’ upon Neovim. Until -in turn- that one is one day replaced as well and so on and so forth… Like, we’ve already gone from Vi -> Vim -> Neovim. While, on the other hand, Emacs still is Emacs. Thankfully, the modal editing part of Vim should persevere regardless; even if the name of the editor changes every so often.
I would say just go with nvim, spend a week to set it up and don’t get too obsessive if small things don’t work. Enjoy the amazing responsiveness and great editor and you will figure out everything eventually. And if you have any questions just ask. I can share my config.
Thank you for the encouragement! At this point, I intend to start with Vi(m) to get used to the core experience.
The problem with SpaceVim is that it offers a lot of toggles that are easy to switch but there are no examples for more ‘custom’ config and I struggled to figure it out. There’s a lot of examples and guides for nvim so it was easier. I don’t know, maybe it was just me but with SpaceVim I also didn’t really see what’s possible. With nvim I just found long lists of useful plugins that you can add one by one.
As for the future I don’t really worry that there will be next thing after neovim. I didn’t write any custom scripts for it, all I have is just plugins with mostly default settings. It would take me a day to switch to another tool witch is not a big issue.
I think starting with Vim is a good idea. You can easily add plugins one by one when you will see the need for them.
The problem with SpaceVim is that it offers a lot of toggles that are easy to switch but there are no examples for more ‘custom’ config and I struggled to figure it out. There’s a lot of examples and guides for nvim so it was easier. I don’t know, maybe it was just me but with SpaceVim I also didn’t really see what’s possible. With nvim I just found long lists of useful plugins that you can add one by one.
Makes a lot of sense. Documentation is indeed very important. Thank you so much for sharing your insights and experiences!
For years I used vanilla vim before finally switching to spacemacs like 4 years ago. I’ve never used neovim, because it just didn’t seem stable and mature enough before I switched to spacemacs and at this point I’m happy with spacemacs and will probably stick with it for the foreseeable future.
My issue with vim, and the reason I switched, is that vimscript was an absolute nightmare. I was doing easy stuff, writing LaTeX, but getting vim to compile LaTeX and talk to my pdf reader (as you need if you’re going to be working with LaTeX in any kind of serious way) took way too much configuration and my setup would break fairly often as well. Spacemacs is significantly easier. I was shocked when I went from “I’ve never used spacemacs before” to “I’m comfortably writing LaTeX here” in about half an hour. My setup still breaks occasionally and sometimes it’s a bit difficult to figure out why and how to fix it, but it’s much easier than vim was, that’s for sure.
I also just like the emacs workflow. I like helm, I like being able to change how the editor works on the fly just by writing some elisp anywhere, I like how easy it is to access the documentation on functions, variables, keybindings, whatever else you might need. I like org-mode. I like that emacs has been around for decades and will be around for decades more.
I’d never heard of doomemacs. I’m pretty happy with spacemacs so I probably won’t switch, but I’ll at least read about it some more.
Ironic that your main complaint about vim would have been solved by switching to Neovim – the weaknesses of vimscript are one of the main reasons Neovim was created, I believe, and it supports Lua as an alternate config language.
I was shocked when I went from “I’ve never used spacemacs before” to “I’m comfortably writing LaTeX here” in about half an hour.
This line really piqued my interest, especially considering that I’ve had another conversation with someone else in which the general sentiment seemed to be that “Spacemacs expects you to know Emacs, while being a completely different beast of itself.”. May I ask how your Spacemacs is configured? Would you say it’s close to the default config? Or rather a significant departure? Furthermore, I believe I’ve read the existence of some kind of version control. Which, at least by the name of it, should somehow contribute to a more stable experience. Or am I perhaps confusing things?
My setup still breaks occasionally and sometimes it’s a bit difficult to figure out why and how to fix it
Does this happen randomly? Or rather as a ‘response’?
I like being able to change how the editor works on the fly just by writing some elisp anywhere
This sounds very interesting and promising. Would you mind providing an example of sorts such that I can perhaps better grasp both the sheer amount of new possibilities it provides as well as its (possible) limitations (if at all)?
I like that emacs has been around for decades and will be around for decades more.
I wholeheartedly agree! But, I am at least somewhat concerned when it comes to its ‘gravitational pull from afar’. To me at least, it seems as if, currently, Neovim does a better job at attracting new people. Perhaps these are just mostly refugees from Vim. Nonetheless, it can’t be ignored (I think). Would you mind sharing your thoughts on this?
A bit of history. The first universal packaging format was snap by Canonical and used to be called Click apps and it was made for the Ubuntu mobile OS and later to the Ubuntu desktop. Red Hat in response to that created the FlatPak format. The AppImages are community effort. As you can see since both snap and FlatPak are developed and supported by a company they are more widely available and easier to search, install and update them. There are multiple tools for AppImages as well, which can search, install an update, however they are not pre installed or can be installed from the repo on most distro. There are dielstros which ship AppImage support by default with App Store for example Nitrux. You can use AppMan or bauh for managing AppImages. The AppMan has command line interface and bauh is a graphical application. Bauh can also manage snap and FlatPak.
Do people actually use LXD in production? All hosting services I’ve seen use LXC and not LXD for containers, as do UIs like Proxmox and Unraid, and you don’t have to use Snap for LXC.
It’s clearly a move to gain control of what people’s computers will be allowed to run and what information they’ll be allowed to see.
There were already attempts to implement this at the start of the consumer internet days by Microsoft and others, which failed then because many early internet users were paying attention and knew what was being attempted. This time I’m not sure that we’ll be able to stop it without structural changes to society.
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. It’s genuinely an excellent way to edit text beyond “just typing words” - it’s a huge productivity boost once you’re competent with even some of the basic commands. There are just soo many combineable short-cuts at your fingertips that once you get a few of them under your belt you’ll go nuts without them. And the simple macros you can write can allow you to do mass manipulation of multiple lines in ways that are just so simple (e.g. “add quotes around every line and a comma at the end”).
Dive in beyond the basic “hjkl:q” though.
Which version of vi you use won’t largely matter. As a bonus most IDEs support a good subset of vi commands so your skills become transferable. I use PyCharm and other Jet Brains IDEs all the time and ideavim is “good enough” for what I do.
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.
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.
It’s a long tutor go through with some bonus advanced tweak, and the explanations clearly helps remembering everything easily. If I knew it when I’ve started that would have saved me so much time and helped me from getting into bad habits I then had to fight against.
linux
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.