It's possible I'm one of the few who thinks the best thing about Vim is the keybindings and other nifty features like macros, while everything else is archaic and frustrating, hence why I always looks for a good vim mode in a more modern IDE. Though often the vim mode is lacking (i.e. Xcode doesn't even support the dot operator to repeat a motion, which is astounding), and so we get back to square one with using vim again.
If there were a GUI editor that had 1st-class Vim keybindings, native LSP support, fuzzy finding, and convenient file management tools a la Ranger, and optionally a built-in terminal, I'd switch in a heartbeat.
OniVim2[0] looked really promising, but the project has unfortunately stalled after the creator had to step back for personal reasons.
Honestly I suspect that’s how the majority “use vim” these days. When I’m on the command line it’s a great lightweight editor, but trying to turn it into an IDE competitor is when the wheels start falling off fairly quickly.
I couldn't believe the lack of support for the dot command in vi emulation in Xcode. Emulation is quite complete, mostly missing regex and ex command support (but even a vi mode that way it's still very usable), but without the key component that is dot command repetition, the whole vi/vim experience is ruined. There must have been some heated conversation at Apple, someone who knows and cares about vi/vim poured a ton of love into getting that right, and they must have felt the pain of not including dot command support.
Just hoping they will address that in a future version of Xcode.
The dot command is always what seems lacking in the various emulation layers. Either it doesn't work at all, or doesn't work the way you expect. As a dot command addict, this makes me sad.
It depends on the language you are using and maybe the size of your project. I did Ruby, Python, and Go development for years using only Vim and really enjoyed it. But the minute I started working on big Java and Scala codebases, I started struggling. I tried different LSP, completion engines, and debugging plugins, but I couldn't find the proper setup. The IDE Vim modes are decent these days but still lack those more advanced features to manage your buffers and windows for example.
Yeah, I also use VIM bindings in VS Code and love it. When I'm at my desk, in the zone, writing code, my hands pretty much don't leave the keyboard. But when I'm leaning back, browsing through files, etc. I just need to press 'i' once and I have a "normal" IDE.
I couldn't imagine not being able to hover my cursor over something to read its type definitions, cmd+click to go into whatever I'm clicking on, etc.
Sometimes I see one of those videos of a fully tricked out NeoVIM and it looks tempting, but I know I wouldn't actually like it.
I just like modal editing, and know vi keybindings for the most part. Those bindings are also mostly consistent whether I'm in Intellij, VS Code, or some random Unix machine.
I'm sure some vim expert would be annoyed at my mouse usage, but like you said, there are tons of useful features exposed.
The beauty of vim is it has a rich feature set and is ubiquitous. The problem with the other vim inspired apps is they aren’t there!
A couple of years ago I helped a friend out with moving some stuff off an ancient Solaris database server somehow still in production.
Iirc it was Solaris 2.6… other than remembering which Unix tools were shipped broken by Sun, I was able to function right away. Shockingly, I even retained muscle memory of some of that database commands after many many years! :)
I went insane setting up key combinations for everything in VSCode specifically so that I never have to use my mouse. It's painful - but it works. Eventually your fingers just remember.
I do a lot of front-end dev and Neovim + lsp-config has gotten me everything I need in terms of auto-complete, go to definition, etc. IMO, its extremely easy to set up but Ive also been using Vim for a few years so I'm definitelt biased.
However "barely adequate yet entrenched is the enemy of good" is what's happening with vim/Emacs improvements.
The core editors are antiquated and creaky technology that won't and can't really be updated correctly because those changes would break too much and also because there's nothing to be gained financially from it (sad, yet ever-present fact of life).
One of the biggest and most successful attempts at such a modernization is Neovim, but it still won't reach Sublime Text or VS Code levels of popularity, because they're still a team of volunteers, not a company backing it.
I don't want to get into this debate, but one thing to keep in mind when arguing from this angle is that vim/Emacs competitors stopped being babies about 20 years ago.
The computing world is big enough that someone that cut their teeth on Visual Studio can still be happily using it in 2022, a quarter century after its original launch. And will likely be able to use it in 2057, half a century after its original launch.
With more or less the same keybindings and core workflow it had back in 1997.
I switched from Visual Studio to Vim ca 2013 mainly because the key bindings and macros made me feel a lot more efficient. I've tried Vim plugins for a number of editors including Visual Studio and Rider throughout the years. So far each one has had some few basic pieces of functionality implemented but not nearly enough to replace Vim. I feel like you need quite a large and well-rounded portion of its functionality to make a worthwhile replacement.
With all the news I've seen about Neovim over the years I keep meaning to try it out at some time. I mainly haven't because there's nothing broken with my current setup and it seems like an investment of time and effort to reach a similar setup: I have quite a few changes in my vimrc and am using a number of plugins which I would need to get working or find replacements for.
I used Spacevim for a few months. But ditched it and Prelude for Emacs for the same reason. These things download huge source trees of config files that are painful to change, import huge amounts of extensions that will have all sorts of broken interactions, and the documentation leaves much to be desired when trying to solve these internal issues.
In the end I settled for vanilla emacs, where I gradually build up a configuration. Once a week I pick something that's been annoying me in the past week and do the configuration for that by hand. This way I avoid bloat and it keeps things pretty sane in terms of configuration complexity. Also I get plenty of time to learn all the shortcuts in my setup as opposed to having a confusing mess of 30 extensions to learn all at once.
What you mentioned is pretty much the way to go. You work on your config on the weekend what you thought was missing throughout your week. I wish everyone tells that the people starting out with vim/Emacs.
> What you mentioned is pretty much the way to go. You work on your config on the weekend what you thought was missing throughout your week. I wish everyone tells that the people starting out with vim/Emacs.
If that's the way to work with vim/Emacs, that would basically kill all mainstream interest in them.
"Work during the week so you can work during your weekends" is not what most people want.
The whole point for me is that I pick something very constrained, so that it's fairly quick to do, maybe taking half an hour at most. This avoids spending hours on my editor at any one time which is infuriating
I love neovim and vim, but personally I've found that configuring the LSP has been very tedious and prone to breaking. For the last few months I've been using LunarVim, but always felt that it did too much and I felt it hard to configure.
It's basially a neovim config that's not minimal, but very reasonable. You can install and all the LSP config just worked. I also found it very easy to configure and set up to my liking (added telescope, etc.)
If anyone out there is looking for a great base to start their own neovim config, try it out!
A lot of gatekeeping in this thread. I have my own grass fed, organic vim config the way God intended, but I think Spacevim is a great way for someone to dip their toes in the water. Just because someone uses a pre-built config doesn’t make them a lesser nerd. Also: I have learned of some handy plugins by following the project.
I have my own configuration for vim/neovim, but there's a lot of faffing about finding plugins and tweaking settings to suit my workflow. The end result is kind of a sort of functional stack but without much consistency since it's evolved over time and I simply don't want to refactor it into something more sensible with less conflicts.
Something like SpaceVim kind of makes it so someone doesn't have to concern themselves with that because someone designed the entire thing from the ground up so you're less likely to run into issues that someone who's gradually built up their vim config over time would. That isn't even mentioning the fact that it all hypothetically just works together and you can be productive actually programming out of the box with something like this.
I think for someone that is interested in using Vim (or Emacs, for that matter), these premade configurations with their own superset of paradigms seems like a much better approach to going about it. They can, after all, switch to building out their own config down the line if they feel the need or desire to.
Someone interested in $THING would be better off learning $THING directly rather than tip-toeing around it.
The argument that they can still decide to do it properly when they want is not grounded in reality. People get used easily to those things so two things happen in those cases:
- they get very frustrated by the real Vim,
- they try to replicate their previous ready-made config anyway.
> Someone interested in $THING would be better off learning $THING directly rather than tip-toeing around it.
This is not really the universal truth that you think it is. I remember when I learned to drive my father started me on his car with a manual transmission. I skipped gears, Started from a stop in 3rd gear, and had a whole lot of frustration trying to deal with both the concepts of driving the car, the rules of the road, and trying not to completely destroy the clutch of the car. I switched to learning on my mother's car, which was an automatic. I gained confidence on the road and then I went back to learning how to drive stick. This resulted in a much easier time for both me and the clutch. So no, I wasn't better off learning it directly. The same can be said for something like walking and then running, or learning how to program. They typically don't start students off learning to write Assembly even if their intent is to be an Assembly programmer. Training wheels on a bike exist for the same reason too. Can people make this approach work? Sure, but that doesn't mean it's better. In fact I think in quite a lot of cases it's way worse.
> they get very frustrated by the real Vim
They are using the "real" Vim. You being weirdly gatekeepy about this doesn't change the fact that they're using the same application that you are, except they loaded a config different from yours. There is a list of different keybinds from vanilla vim in their documentation and you can disable them with one line in your config. Pretty much all the typical vim paradigms are exactly the same.
> they try to replicate their previous ready-made config anyway.
kind of their prerogative and one of the nice things about extensible programs like vim is that people can do exactly that. I could change vim to use CUA commands, be mouse-focused, and default to insert mode and I'd still be using vim.
> This is not really the universal truth that you think it is.
All of those examples are about prerequisites, though. You learned to use manual transmission in a car with a manual transmission, not in a car with an automatic transmission. You learned to drive a car in a car, not on the back of a horse. The person who learned Assembly learned it by doing Assembly. Etc.
> They are using the "real" Vim.
They are shielding themselves from "real" Vim.
> You being weirdly gatekeepy about this doesn't change the fact that they're using the same application that you are, except they loaded a config different from yours.
The config they use not only hides Vim behind dozens of plugins but also adds a few new concepts to the mix that they are forced to learn _on top_ of Vim's ones. What a waste.
Training wheels aren't a prerequisite for learning to ride a bike and they're not typically separate thing from a bike. They're bolted onto a bike and then removed when they're no longer necessary. I learned how to drive a car in an automatic, I learned how to use a stick shift in a manual car. Pretending like a car with a manual transmission or an automatic transmission as completely different concepts is disingenuous. There are skills transferrable between learning the two, otherwise known as learning how to drive a car. Similarly, if I wanted to learn to drive a large semi, knowing how to drive a car has transferrable skills.
> They are shielding themselves from "real" Vim.
Define "real" vim.
> The config they use not only hides Vim behind dozens of plugins but also adds a few new concepts to the mix that they are forced to learn _on top_ of Vim's ones. What a waste.
It doesn't hide Vim behind anything. Extensibility is baked into Vim and a great deal of effort has been put into ensuring that it can be extended to suit people's needs. One of the largest changes in Vim 9 was working on increasing the capabilities and speed of Vim9 script. Whether someone writes their own config, doesn't use one, or uses a premade configuration like SpaceVim, they're still using Vim.
They trade time learning SpaceVim's paradigms in exchange for not having to configure vim themselves which means they can spend more time learning how to use Vim for getting work done rather than faffing about with plugins and designing their own keybinding schemes. If SpaceVim completely eschewed Vim paradigms for its own you might have a point but that's not the case. It very much adheres largely to how Vim itself works while making it easier for someone to get up and programming.
After almost 10 years of tinkering with Vim and fixing it every time a random extension updates and breaks my whole setup, that would be exactly something I want.
Yes, I was doing that at some point. But then the problem is that
- I work (or rather workED until a month ago) on LSP implementation for C++ (clangd) and I frequently need updates in the client
- The client (Neovim LSP client) is being developed quite rapidly
For the reasons above, I did update the LSP plugins and Neovim versions quite a lot. And (in my experience) that is the thing that breaks the most over the past 2-3 years. Everything else is kind of OK, but it doesn't make much sense without the LSP. I could update only some plugins and keep the others at a fixed version, but then overall I'm not getting bug fixes & features which makes me kind of sad (that's why I started building my ultimate (Neo)vim setup in the first place).
I guess I should really stick to just a couple of basic plugins and throw everything else out.
This is for people who happen to like the “space” setup already. Not for people who just want some random configuration.
What’s the difference between someone who uses vanilla, unconfigured Vim and someone who uses unconfigured SpaceVim? Merely that one of them likes vanilla Vim and the other one likes SpaceVim. What’s the problem with not configuring things if you don’t want or have to?
Also the mock quotation thing is way overdone around these parts, jeez.
I’m in the same space but I found the best option was just to not bother with anything past the default plugins. I type one simple vimrc from memory that is about ten lines and job done. Also I only use a fairly common subset of commands.
I found this was a good compromise because I jump around all sorts of systems and broken ass container hosts so any vi variant is home then.
If you keep your dotfiles (vimrc included) in a public repo, checking them out to every new system may become a useful habit. Or you can even do curl ...| bash to setup your work environment every time.
Im not allowed to do that. I work in high security environments usually. We can’t even talk to GitHub from those nodes. And if we could we’d be shot for doing it.
Pulling stuff out of GitHub regardless of the repo into a production machine should be frowned upon anyway.
Vim (and its cousin, Emacs) are quite terrible out of the box, with the excuse that it's "configuration over convention".
It's not efficient for many different developers to each learn how to configure Vim to the point where they can get an effective editor out of it. - For this, a shared configuration / distribution saves a bunch of time.
It does make sense for developers to learn vi keybindings (so that they'll be able to use a vanilla vi in a limited environment), or to learn how to customise their programs for their particular situations.
To my understanding, the non-standard keybindings in distributions like Spacemacs provide are consistent, well thought out, and discoverable. (Which won't be the case with each ad-hoc customisation).
I do get the impression that Spacemacs (which I think inspired this project) adds a layer of abstraction too many, such that users who are stuck with Emacs might not have the capability to get themselves un-stuck without effort.
I look at it differently. If vim is a useful tool in your daily workflow then it's probably worthwhile to invest time into customizing it and enhancing it with plugins.
The open source landscape of plug-in development is under constant evolution and it can be quite a time sink staying on top of the latest and best tooling.
I see SpaceVim as something similar to a Linux distribution. The maintainers offer the work of selecting various packages inversion combinations that harmonize into a consistent system.
And just like any Linux distribution you can agree or disagree with the packages they choose or the default configurations it comes with.
I end up using a somewhat heavily customized SpaceVim that I personally like but it's my opinion the distribution is a very productive foundation.
I've found Helix Editor to be a good successor [0], although it's still in development. Vim-like modal editing with fast performance due to being written in Rust rather than Electron.
I was supporting Oni2 for the same reasons, a work-out-of-the-box fast modal editor but a Gui would have probably meant leaving behind a terminal based workflow.
I have also been seduced into Kakoune's way of doing things although not enough to make the jump from vim, which I hate but can't live without.
Helix really hits that sweet spot of a fast work-out-of-the-box kakoune-style terminal editor. Time to make the jump.
Unfortunately the reason I switched back to Neovim is that Helix doesn't have plugin support yet, so one can't really add new features, even if most of the popular ones are built in, like tree-sitter.
Some anecdata. I've started using Helix too, and found it surprisingly good (relearning some not-so-vim stuff wasn't a problem). But I returned back to NeoVim purely because of... Copilot. Hard to code now without Copilot, and it's only available in VSCode and NeoVim ¯\_(ツ)_/¯
Yes, that is also why I came back to Neovim. Another con is that Helix doesn't have plugin support yet, so one can't really add new features, even if most of the popular ones are built in, like tree-sitter.
Due to speed and vim-like editing, with certain things like tree-sitter support built in, similar to how Oni has things built in. With (Neo)Vim you'd have to configure that yourself. That it's terminal versus GUI doesn't make much difference to me, since as long as it shows text/code on the screen, I don't really care how it displays it.
OniVim's main selling points was it beeing close to VSCode, so saying Helix Editor is its successor but not having the main features does not make a lot of sense to me.
Based on your points it sounds like Helix Editor is pretty much the same as SpaceVim.
I used OniVim due primarily to speed and not having to set up a vimrc. That it was a GUI app versus terminal based is immaterial to me. Now I have my own vimrc so it doesn't matter much anymore, but last year OniVim was nice enough to use.
> Speed or vim-like editing was not a selling point at all.
Speak for yourself, those are why I supported OniVim. The GUI was not what was important to me, it was the ability to install extensions easily, have vim keybindings, and most importantly, be able to handle the very large files I often work with (due to being written in OCaml), where VSCode hangs.
>Speak for yourself, those are why I supported OniVim.
Why are you so obsessed with this subjectiveness? I'm just saying that speed and vim-like editing where not a selling point. Because you can already have those in VSCode with neovim backing it up. Not to mention you could've already have speed and vim-like editing via projects like VimR (tens of them out there).
>The GUI was not what was important to me
>I thought OniVim would bring that^1 but it seems it is not anymore.
You are contradicting yourself here.
[^1]: "(neo)vim plugin installation still isn't as easy to work with as a one click package / language server install like in VSCode."
On the contrary, I think it is you who is obsessed with what I should or shouldn't think of as a selling point. I used to use VSCode, it was slow, I found OniVim and it was fast, why is that so hard for you to accept as the reason I liked and bought the application? As I said, speak for yourself, if speed wasn't a consideration then good for you, for others it is.
Regarding the plugin support, there is no contradiction. Rather than the words "one click" however, which brings to mind a GUI, I should have said Neovim has a more annoying plugin story (through packer which has a lot of configuration) than VSCode or OniVim, yet it is not the GUI that makes it so. If I could write in init.nvim "Plug TypeScript" just as in VSCode I could click "install" on the TypeScript extension, those are both equivalent to me, even as the latter is GUI based while for former is terminal based.
Yes, however (neo)vim plugin installation still isn't as easy to work with as a one click package / language server install like in VSCode. I thought OniVim would bring that but it seems it is not anymore.
I wouldn't go so far as GP as to call it "drama", but the split left Reason without a reason (pun intended) to exist or any activity for that matter. Most of the people who liked Reason for frontend usecases moved to ReScript since that at least had some momentum behind it. Since the split, Reason itself has been largely on life support, with no significant changes and almost no forum activity in the past year. So newcomers to Reason see a dead community for a language which is a syntax extension for another language with a (relatively) alive community. The fact that Reason hasn't seen a surge in enthusiasm corresponding to the enthusiasm in the OCaml community with the advent of 5.0 and multicore is proof enough that Reason is dead, and projects written in Reason should probably consider moving to OCaml entirely considering there are planned changes to the OCaml syntax for effects which I don't think are going to make it to Reason.
Some people in the Reason world blame the ReScript people for this, which I think is entirely misplaced. The only reason (pun not intended this time) Reason has died off is that there is absolutely no clarity on the future of Reason. The creator of Reason, Jordan Walke, has been entirely MIA for about two years now. A version 4.0 was planned in 2020 and as of now hasn't come up. This issue was opened in Nov 2020 asking for future plans and is still unresolved, and the latest comment from a new developer just makes my point: https://github.com/reasonml/reason/issues/2634.
Agree with you, Reason is effectively dead, the "drama" part is that the decision came from nowhere, leaving the native devs with a sour taste and the frontend devs with a "Hey, we just changed the syntax without warning and will not support the old one anymore, good luck", which made me move all my projects out of reason ASAP, if the developers can pull out giant changes like that without warning, sorry, I will not use it, too unpredictable.
Also, rebranding instead of starting a new project sounds just like "it's my baby, I'm gonna kill the old project so no one that disagrees with my decisions can continue it".
> Some people in the Reason world blame the ReScript people for this, which I think is entirely misplaced.
I mean, the way that the creator of ReScript behaved on discord to any criticism to his decisions at the time didn't helped...
> "Hey, we just changed the syntax without warning and will not support the old one anymore, good luck"
I think this is slightly uncharitable. The people working on BuckleScript had been unhappy about syntax for a while, and wanted to make it simpler for people coming from JS. They also kept supporting Reason syntax - it's quite literally in the announcement and forum threads from the time that old code will continue to work.
I can't speak to why the rebrand went down the way it did, as none of us can know for sure, but I think it might have more to do with internal communication between team members than any one person taking their toys and going home, so to speak.
> I mean, the way that the creator of ReScript behaved on discord to any criticism to his decisions at the time didn't helped
I didn't hang around on the Reason discord (for good reason, I now suppose :P) but I don't think that had anything to do with Reason dying out. No matter how the ReScript people behaved, Reason native could've gone its own way, but it didn't, and the responsibility for that is on Reason. As much responsibility as there is, ofc. I don't mean to imply that the team behind Reason should've continued developing if they didn't want to, I just don't think the ReScript people should be held to account for how Reason evolved.
(FWIW, I was interested in Reason only for native, and have zero interest in ReScript, so I say this as someone who is "on your side".)
> The people working on BuckleScript had been unhappy about syntax for a while, and wanted to make it simpler for people coming from JS.
Yeah, but as far as I remember the new syntax and all changes were discussed and developed behind closed doors and dropped like a bomb, I mean, it is their project and they could do whatever they want, but two points left a pretty sour taste in my mouth:
1. You know that there are a lot of native projects and your changes will cause ripples through the entire ecosystem, warning people would be nice, they have no obligation to do so, but they can't really complain that people were pissed about it.
2. The rename and using all the old bucklescript resources instead of passing these resources for the community and saying "ok, now we're working on ReScript, it is a new language that follows our long term vision for the future of webdev, follow us".
They own the project, but they don't "own" the community.
> I didn't hang around on the Reason discord (for good reason, I now suppose :P)
Yeah, it wasn't a nice place.
As for reason dying out, most of the devs that embraced native ReasonML were also OCaml devs and tooling was being developed to facilitate the transition from web to native code with the more approachable syntax of reason (esy.sh and revery were two of these initiatives).
ReScript dropping support for OCaml was like "ok, no point in trying to bring web people to native now, let's stick with OCaml syntax, they aren't the same language anymore".
And as "my side", I did use Reason syntax in native just because I was already using the syntax in web projects, otherwise I would just write OCaml, but after seeing how the changes were announced I gave up on Reason for web and didn't even bother with ReScript, don't get me wrong, it is a really nice language for webdev, but I have no interest in waking up in a Monday just to discover that the language I'm using is being completely changed without any warning in the next week.
This. The reason for Reason to exist was to be a bridge, bring native OCaml devs to web deployment and bring front end devs to native apps. It was a brilliant strategy I think. While the failure of the project certainly stems for the absence of development for more that two years, the ReScript project was the last nail the coffin because it stated that they wanted to blow up the bridge that was Reason's reason to exist. Why they thought the world needed yet another compile-to-javascript dialect when there's already typescript, dart, elm, and probably many others is beyond me.
The creator of bucklescript (ReasonML/OCaml to JS compiler) decided to drop ocaml support and gather the already built community around his new project (Rescript) and it wasn't well received by the part of the community that were interested in ReasonML (and OCaml) for native or hybrid applications, which is kind of obvious since:
1. Rescript is not ReasonML/OCaml, it is a new language.
2. Rescript doesn't compile to native code.
Forks were being discussed, the creator didn't like the criticisms of his decision (which came as a surprise for most of the community), people didn't liked having the rug pulled out of their feet, aggressive comments were made, people were angry and the community got separated between web and native, both weaker than the united one.
TL;DR; The creator decided that his project was for web only, alienated the native developers out of the blue and shattered the community.
Funny thing, ReasonML (the alternative syntax for OCaml) was created by Jordan Walke, who also created React.
The cool thing about Bucklescript is that it generated pretty readable javascript, so dropping the compiler and working with the JS files was pretty easy, which is what I did with a project that I was working when the drama started, just used the generated js files and slowly replaced them with typescript when needed.
I used SpaceVim for a month or two, and it was good, but I switched to LunarVim and it's amazing! Been using it for ~6 months.
As you say, updates are a bit rough. I've given up on updating,and periodically I just reinstall it from scratch (a fairly painless process, they did amazing at making it easy to install). I figure this is comes with the territory of a rapidly evolving package.
The Treesitter and LSP features give me real-time code intelligence that I had been missing, and has made porting python2->python3, especially with type annotations, so much easier!
I’ve been doing the same as far as reinstalling when an update goes awry. Not super convenient, but not too painful either. Overall I’ve found the LunarVim experience worth it. I think you’re right, it’s a quick moving package and bumpy updates are par for the course.
I’ll give SpaceVim a shot. LunarVim is great, but it’s good to see what else is out there. I love vim in general, but I’ve found myself killing too much time fine-tuning/breaking my config. LunarVim more or less works out of the box and gives me what I want. I’m curious to see what SpaceVim has to offer.
I went to LunarVim to try to get out of the business of fine-tuning vim configs and custom configs, so I'm trying to keep my changes from stock as minimal as possible, adapting where possible. One of the things that I can't adapt to is ESC+j/k moving the current line up or down, I was always accidentally moving lines around, sometimes not noticing it until code blew up.
I think these packages need to ship with homebrew or atleast some sort of an installer. Building them seems to be very hard for people who just want to use it, and not go down hacking rabit hole.
It’s a little comical that SpaceVim has reached v2.0 while it’s inspiration, Spacemacs, is perpetually on v0.200. Anyway, congratulations to the SpaceVim team!
As a Spacemacs user, the idea is a distribution that harmonizes a package collection into "layers" for Good Justice.
Using the space bar to drive a text interface is a win over the stock emacs key chords, which wear out my left arm/wrist.
Vi's modal editing, once understood, is a general win, too.
Spacemacs blew my mind by setting up a Language Server Protocol (LSP) environment for python with almost zero effort. Not sure if SpaceVim is quite as broad in its feature set.
I’ve come full circle. I now don’t use any config, instead writing file specific setting with modeline. Although now I’ve started collecting modeline templates I need get bound to some hotkeys. Back to the .vimrc I go.
I was the same way to be honest. I ended up taking the parts I liked from spacemacs/lunarvim and adding them. I also started doing all my configs in lua, because it's great
Rather than being limited by console-based rendering, it could do the heavy lifting... like being able to render a markdown file natively with different font sizes.
It's a search/completion interface built around fuzzy finders and regex, with previews for results. It looks similar to ido, Helm, Ivy, Vertico, etc., in the Emacs world.
Not built on electron. Hard pass. If it doesn’t require at least a workstation with 32GB of RAM to run one tab with a simple Python script, I’m not interested in it.
