Thank you OP for that, but… why should we prefer this over uBlue’s work on streamlining this process?

Makes a lot of sense.

Thank you so much for chiming in and sharing your knowledge and experiences! Much appreciated!

Thanks a lot for sharing your insights and experiences on this! Kickstart.nvim has surely caught my interest and I would like to play with it to see how much I can make it resemble LunarVim and the others in functionality and if there’s anything worthwhile that remains to be missing. If not, then perhaps I’ll be relying on Kickstart.nvim instead. Once again; thank you!

Emacs I’m not so sure. If you’ve checked the news anytime for Doom Emacs, you can see the maintainer mentioning how it’s become progressively difficult to maintain the project. I’d imagine it’s a similar story for plugins and other derivatives. People have attempted remaking Emacs from scratch, but there was not enough momentum for it, so that went under.

This is news to me. Thank you so much for mentioning this! I’ll have to look into this.

Have you had a look at the design philosophy behind Kakoune?

I actually hadn’t yet, but I did just now. And I’d have to say that I liked what I read. There’s for sure a lot out there that’s worthy of being explored and I’ve become confident that Kakoune deserves to be further explored as well. Thank you for informing me on that!

I also recommend reading this article here that goes more in-depth on this point and has a comparison of vim, helix and kakoune.

I haven’t read the article yet. But I’m pretty sure it’s going to be another excellent read. Please feel free to share more from where these are coming from 😊! Thank you!

These changes are undocumented and must be discovered and explored organically, while the default behavior is well documented.

This, indeed, is concerning. Thank you for mentioning this!

Kickstart.nvim ads only a few packages that are very popular and provides a base upon which you can customize as needed.

Hmm…, allow me to ask the following: How much effort would it take to get Kickstart.nvim from scratch to where any of the opinionated distros are in terms of functionality?

EWW (short for Emacs Web Wowser) is very basic, only really working with the HTML and not so much the css, and definitely not JavaScript. Don’t expect anything fancier than a blog post to work :P

That’s kinda cool as it decreases the attack vector very significantly. I’ve still got a lot of questions regarding the security implications, but I’m sure I’m not the first one that’s looking for a ‘hardened’ Emacs experience if there’s anything to worry about in the first place.

I’ve indeed been pleasantly surprised by Helix since I’ve started these posts. I’m also more optimistic than initially regarding its future prospects. I’ll look into it and perhaps I’ll have some use for it. Thank you!

I like Spacevim a lot

Have you tried any of the ones mentioned in the OP? If so, would you be so kind to elaborate upon why you prefer SpaceVim over the others?

(inspired by SpacEmacs)

Interesting. Would you be so kind to elaborate on what this entails?

you can use neovim as the underlying vim package as well. Then update init.toml with whatever layers/plugins you want

That seems kinda hella streamlined and straightforward, which is honestly pretty cool. Is this different from how it works on any of the ‘(Neo)Vim distros’ and/or by default?

I honestly believe that Helix will eclipse NeoVim because it’s designed better, the source code is more maintainable, and the philosophy is a bit more balanced and welcoming to users that care more about productivity than customizability. Refactoring Vim’s spaghetti C code is a massive task, and C as a language drags it down. Where the NeoVim ecosystem is currently fractured among many Lua “distributions,” Helix just builds on itself in one source tree. I think starting with a solid core before supporting plugins will be good for the future of Helix.

Perhaps I should have done a better job at formulating the question. Btw, this writing is cool. Thank you for that. I also believe it contains some excellent pointers regarding topics I should read into. However, my question was more related to the following: As you know; it doesn’t matter whichever IDE I’m using, there’s definitely a plugin (or perhaps even built-in functionality) that allows me to utilize my Vi(m)-acquired skills to improve my productivity on any given IDE. Do you think that Helix’ keybindings (I believe they’re at least to some degree inspired by Kakoune) will be similarly found either built-in or as a plugin on whichever random IDE you might come across?

Once Helix has plugins, it might be possible to get something closer to true Vim emulation.

This is the answer I was seeking. Makes sense.

Yea I think Helix is here to stay, and it will continue stealing market share from other terminal editors. It probably won’t convert anyone that’s already invested years in learning and configuring (Neo)Vim, but for newcomers looking for a powerful option with sane defaults, Helix is far easier to get started with.

Perhaps I should have done (yet again) a better job at explaining what I meant. As you know; it doesn’t matter if I’m on some random Linux distro or on macOS, I’m sure that Vi(m) is installed by default and I can rely on it. Same applies to some random remote device I’m accessing; if anything, I can expect that my Vi(m)-acquired skills will be of good use. Do you think that Helix or some of the functionality it offers (from its keybindings to anything (really)) will somehow be beneficial to me in some remote accessed device or any other similar setting?

Of course, all of these questions stem from the fact that -if possible- I want usage of my IDE to be beneficial to how I engage with my text editor and vice versa. Otherwise, these questions don’t make any sense at all. Perhaps, I should instead reconsider if this is important in the first place. Currently, I’m at least naive enough to believe that it’s worth pursuing. But feel free to convince me otherwise 😉!

For completeness’ sake, Helix has definitely peaked my interest. I will look into it and see how I might benefit from it (if at all). Thank you.

I’ve tried so many (Sublime, Atom, PyCharm, Jetbrains stuff, Eclipse ((ew)), Visual Studio code, and neovim)

Hehe, that’s for sure a long list 😜. I’m very curious to learn how your experiences with Neovim went in particular and what ultimately led you to prefer Doom Emacs over it.

I feel like with Doom i’ve concluded my search for the “best” text editor and settled for a highly extensible but also highly intuitive text editor that works right out of the box and can work flawlessly for projects in a lot of the popular languages (I’ve personally used Rust, Haskell, Python and markdown and HTML editing with it). Something I can use forever without succumbing to the enshittification that inevitably lies for most proprietary solutions (end of open source dogma rant)

Honestly, I think you’ve done a great job at vocalizing my ambitions related to Emacs. From, what I’ve seen so far, I can’t envision any other editor that has as much potential to become my ‘endgame’. Though, I’d have to admit that Neovim’s advancements seem very promising. And I can definitely envision some use for it alongside Emacs.

Also, pro tip is, when you’re in a project and want to search for a keyword in one of the files in your project, type then slash (/). Super useful and it’s really fast. Welcome to Doom 😊

Hehe, thanks for the tip! And thank you for welcoming me to Doom 😊!

I’ll add that there’s some preconfigured plugins for most popular languages in Doom (complete with LSP) that makes it a breeze to go from install to feeling like home. You just have to uncomment them in the config file and reload emacs.

That’s actually really cool! Thank you for that tip!

i’d like to try gnome or kde plasma

I’m surprised to see that no one has mentioned the following yet:

"KDE Edition

In continuation with what’s been done in the past, Linux Mint 18.3 will feature a KDE edition, but it will be the last release to do so.

I would like to thank Kubuntu for the amazing work they have done. The quality of Plasma 5 in Xenial made backports a necessity. The rapid pace of development upstream from the KDE project made this very challenging, yet they managed to provide a stable flow of updates for us and we were able to ship good KDE editions thanks to that. I don’t think this would have been possible without them.

KDE is a fantastic environment but it’s also a different world, one which evolves away from us and away from everything we focus on. Their apps, their ecosystem and the QT toolkit which is central there have very little in common with what we’re working on.

We’re not just shipping releases and distributing upstream software. We’re a product distribution and we see ourselves as a complete desktop operating system. We like to integrate solutions, develop what’s missing, adapt what’s not fitting perfectly, and we do a great deal of that not only around our own Cinnamon desktop environment but also thanks to cross-DE frameworks we put in place to support similar environments, such as MATE and Xfce.

When we work on tools like Xed, Blueberry, Mintlocale, the Slick Greeter, we’re developing features which benefit these 3 desktops, but unfortunately not KDE.

Users of the KDE edition represent a portion of our user base. I know from their feedback that they really enjoy it. They will be able to install KDE on top of Linux Mint 19 of course and I’m sure the Kubuntu PPA will continue to be available. They will be able to port Mint software to Kubuntu itself also, or they might want to trade a bit of stability away and move to to a bleeding edge distribution such as Arch to follow upstream KDE more closely.

Our own mission isn’t to diversify as much as possible in an effort to attract a bigger chunk of the Linux market, and it’s with a bit of sadness that we’re letting this edition go. We focus on things we do well and we love doing to get better and better at doing them. KDE is amazing but it’s not what we want to focus on.

With Linux Mint 18.3, we’ll release one more KDE edition. I wanted this announcement to come before the release. It will hurt its popularity of course, but I wanted to give users time, either to react right now or to take their time, upgrade and adapt to this later on. I’m sure this edition will be missed and I hope its users understand our decision."

From this Linux Mint blog post*.

Note that this doesn’t mean that you can’t use KDE Plasma (or GNOME for that matter). Though you have to be aware that you’ll be on your own whenever something breaks. And if you have to ask how to change Desktop Environment in the first place, then I think that you might not be ready yet for such a ride. Instead, consider using a distro that actually does offer GNOME and/or KDE Plasma editions of its distro; the likes of Fedora, openSUSE and Pop!_OS come to mind.

It seems to offer a leaner approach. If you’ve used any of the ones mentioned in the OP, would you consider offering a more elaborate comparison between them?

Have you used Spacemacs as well? If so, would you mind offering some more insight regarding either one of them and specifically whatever made you like Doom Emacs?

And it’s written in Rust so I feel pretty comfortable working in the codebase.

Rust, indeed, is a big plus.

It has shortcomings from being young, but they are rapidly disappearing. The philosophy of being mostly “batteries included” is so refreshing compared to the configuration hell of NeoVim.

While its shortcomings might eventually be ironed out. Do you expect it to be as ubiquitous as Vi(m) has become? If not, do you expect Helix to improve its Vim implementation or rather become so popular that it can rival Vi(m) in being ‘ever-present’?

• the default editor is kinda shit
• but it is really good at editing it’s configuration language: elisp

So people have a need to change their editor, and a good configuration language to do it in. Moreover, emacs secretly comes with a bunch of built-in features, not enabled by default. It also helps that emacs is not terminal-based, allowing users to do stuff in emacs that you aren’t able to do in a normal terminal (like viewing images, or searching for images on the web. Did I already say that emacs has a built-in (primitive) web browser?) and generally means that emacs users “live” in emacs, as they already have access to so many features.

That makes so much sense. Would it be fair to say that Neovim attempted with Lua to bridge that gap and also make it a lot more accessible?

Did I already say that emacs has a built-in (primitive) web browser?

I don’t think you did, but I’m already aware. I even have some concerns regarding its sandbox 😅. Would you happen to know more regarding this?

I wouldn’t quite say that. It is more that you are probably going to need some prerequisite emacs knowledge to make the best use out of spacemacs’ layer system. To figure out how spacemacs works, you first need to have a basic idea of how emacs works. Doom is a bit closer to the metal, so you need to know less in order to properly customize it

That’s some excellent insight! Thank you very much, good human!

Thanks for mentioning Helix! I’ve definitely considered Helix. But as ‘its Vim implementation’ messes the structure of its ‘sentences’, it seemed somewhat detrimental with respects to improving my Vi(m)-game. Furthermore, I am not confident that it will continue to thrive 20 years down the line; while both Emacs and Vi(m) have already proven with their respective track records how robust their ecosystems are.

It is missing a few features still (e.g.plugins) but I have been using helix for a while and it is really fun.

Which is another concern 😅. For whatever it’s worth, I believe Lapce to be more promising.

I think that one of emacs’ surprising great points is that there is a plugin for a lot of smaller languages. If you’re working with a language that has no special text editor love at all you’re likely better off using vim but if the language authors made a plugin for their language, it’s likely either going to be for emacs or vscode.

Very interesting. I didn’t know that Emacs was better at providing plugins. Would you happen to know to what that is attributable?

Spacemacs has a bespoke customization system involving layers that is not all that friendly towards copy & pasting code from the internet. Doom emacs customization leans more to the vanilla side which can help if you need to solve a problem in your workflow.

Did I understand you correct in that customizing Spacemacs is a completely different beast. So knowledge acquired related to it doesn’t translate well to Vanilla/Doom Emacs and vice versa?

Since childhood, they wanted to become the head of a bank; this wish -however- was more rooted in the (childish/immature) association that being at that position should mean that they’ve made it (monetary-wise). So, they started Finance with the belief that it would be the best step to attain that goal. Furthermore, I believe they had misinformed ideas on what studying Finance was at the time 😅,

Btw, you make excellent points! Thank you for that. Much appreciated!

I’ve found that it is FOSS vs proprietary that causes beloved tech to die

There’s definitely truth in that.

VSCode is, by a wide margin, now the most popular IDE. If MS abandons it, there’s a fleet of us ready to continue using VSCodium.

I can definitely see that happen.

Edit: The usual issue with plugins on VSCodium, out of the box, is that it defaults to a completely different plugin set, due to MS license rules about their plugin repository. It’s trivial to switch it back with a config file edit, which is, admittedly, a little buried, in the project FAQ. The VSCodium plugin repository is growing better over time, but there’s not good awareness of it yet by most plugin developers.

Wow! Thank you so much! At the time I just needed something that works, so the path of least resistance (read: go back to VS Code) was preferred. So, I probably didn’t even bother finding a way to resolve the issue at the time. But this paragraph has provided a great amount of pointers that will surely help solving it.

Perhaps I should include VSCodium as another viable alternative 😜. So that it becomes -at the very least- the path of least resistance to Emacs and/or (Neo)Vim.