New employee 6 workflow at company X:
1. Install Spacemacs, don't bother fiddling with the config
2. Spend a few hours working through the tutorial or reviewing the excellent docs [1]
3. Work. Become a better developer [2].
2. Observe a flurry of errors every time you start emacs. Ignore and hope it works because no idea how to fix any of it.
3. Find, among a million others, the command that seems to do what exactly what you want. Command gives an error. Dunno how to debug.
4. Watch emacs features that should work ootb not work because spacemacs or evil or one of the three bazillion packages did something that broke it. Dunno how to debug.
5. Complain on HN, get told you need to be using the master/develop version of packages because upstream devs don't care about maintaining stable releases.
6. Use unstable packages. Observe new errors whenever you update or do anything. Hope it doesn't break more than it's already broken.
While Spacemacs is an admirable effort, I think it misses the point: Emacs is an editor for power users from another era, so it requires huge effort by the user to become truly productive by todays standards. Trying to create layers upon layers of "friendlines" and eye candy is not going to solve the complexity.
I've always said that it's better to grasp Emacs with a vanilla config or a small starter kit and see if you can make it grow step by step in a journey that takes years.
vim is a similar rabbit hole, maybe less deep.
The real question is: can VS Code make you productive enough in less time?
I stick with Emacs because, now having invested more than a decade in learning to get the most out of it, I can do a lot of things in seconds that take VS Code users minutes or hours. But the converse is also true, and I think will only become more so. Especially in the realm of remote collaboration and mentorship, which has never been more important than it is today, VS Code does things that Emacs simply can't, and almost certainly never will.
That's fine, of course. That different tools should specialize in different things is perfectly reasonable, and I don't have the kind of emotional attachment to Emacs that would give me cause to be upset with its dwindling user share or its lack of broad appeal. It serves me very well, but it's not something I advocate, although of course I mentor those who take an interest.
I am looking at picking up VS Code, with suitably Emacs-esque keybindings, for the mentoring-in-programming aspect of my role. That's where pretty much everyone else is, or is going. And in that context, its less fluent and less extensible user interface is probably a boon, once I get over being frustrated by it. In the context of teaching someone less experienced, acting with the speed of thought is really best avoided; if you don't explain why you're doing what you're doing, or offer the chance for questions and discussion, essentially the entire point is lost.
Out of curiosity could you provide some examples of some of these?
If you're looking for a strong reason to think Emacs is worthwhile as a totally new user, I'd point instead to Magit, an extremely powerful and comfortable git porcelain, and Org-mode, which is simply the most powerful and flexible single-user notetaking/outlining/live code notebook tool yet created. Those are the two Emacs features I see most often mentioned as the subject of sentences like "I don't use Emacs for anything else, but I do use it for X because nothing else comes close".
That said, as I mentioned above, I'm not really here to evangelize Emacs. It definitely does have a steep learning curve, enough so that unless you see a clear killer feature (in my case, TRAMP's transparent remote file editing, since I edited remote files a lot in those days), it's not likely to be worth the trouble.
I moved to Spacemacs becaues I wanted to write clojure without maintaining my own Clojure IDE in vim+tmux (this was around 2014, maybe 2015). I was productive in Spacemacs in around 10 minutes. I went from never using Emacs to fixing bugs and writing extensions in Emacs in less than two weeks because Spacemacs pervasively uses which-key to provide discoverability and had vim-style shortcuts I could use for real work (rather than learning a new set of keybindings). The groupings of things into layers makes studying what ecosystem packages provide what functionality much easier than blindly googling "how to do X in emacs" and getting 3000 "unique" (read: half-baked if you're lucky) solutions.
This idea that you should suffer for hours/days/weeks building your init.el from scratch while adapting to terminology, keybindings, and a lack of familiarity with the ecosystem is absolutely insane. If you can use vi, you're better off with Spacemacs.
I later ended up starting with a stock config, and I probably could pick up spacemacs now if I wanted to, but at this point I don’t feel the need.
Vim was for a long time and still pretty much is mostly a text editor. It is light, work well with large files and is installed on most Unix machines. I don't think trying to turn it into an IDE makes much sense but if you want to develop with it, installing a language server client takes two minutes and you don't need much more.
As a text editor, Vim is really nice. Modal editing can be very pleasant if it clicks with you.
I install Spacemacs in every machine for the sole reason of using Magit with vim bindings. It's so far beyond all other git clients it's even hard to explain to others sometimes. If Magit existed as a native standalone app, I would be happy to pay €50-100 for it, right away. But, but... :/
A month or two later I gave Spacemacs a try, and I've been using it ever since. Not only does it have sane defaults like evil-mode for Vim emulation, but a lot of terrific packages like Magit and Org-mode are builtin. I also use the Spacemacs docs as my first resort when I want to install something new or fiddle with settings, rather than the subpar GNU Emacs documentation which never quite tells me the exact information I'm looking for.
It's the oh-my-zsh of vim/emacs.
After a year of SpaceVim, when I finally found time, I ended up switching back to my more lightweight and stripped down version of NeoVim but copied the keymapping approach and some of the individual configs. It was a great starting point.
If you're a) new to vim/emacs or b) tired of maintaining your own config for w/e reason, Space[x] is entirely usable in it's default state with good documentation. It also updates often and stays on the cutting edge of various plugins and progression in the community, but with the stability of a larger community.
It defeats a lot of the learning/config curve arguments again vim/emacs.
int main(
Anyway, this way I saw an issue early on that stopped me from going any further, and saved me much time and heart ache.
Sticking to my plain old .vimrc for now.
The next release has been coming for several years and it's not yet there. This means that you can either choose between the master branch and get hopelessly outdated stuff or the development branch which is so chaotic that you better be ready for things to break constantly.
I used spacemacs for years, then I tried doom emacs and it took me all of 15 seconds to realize that I should switch.
1. Install Prelude 2. Work
It didn't work. So I gave up.
PS: I am on windows.
More sophisticated ide like features normally constitute reading the documentation for a particular project like cider for clojure.
I have no idea why you consider 4 and 5 fictitious. One can read the entirely of mastering emacs and the cider docs in a reasonable period of time for example.
It is one thing to know enough and quite other to be proficient in using them effectively. With the horrible and unintuitive default keybindings it takes even longer to develop muscle memory.
> One can read the entirely of mastering emacs and the cider docs in a reasonable period of time for example.
Yes one can in theory. But again if everybody could become proficient in something just by reading manuals then we could shut down our expensive schools and colleges and any sort of practical training. Also, everyone could then program in `ed` or TECO.
Curious, have you actually met any other person who's not an emacs user in real life, like ever? Here's an experiment, go to any decent software company and ask 5 new hires who've never used Emacs, give them the manual and see how long it takes them to actually do something significant? Then give them VSCode and compare notes.
I'm not likely to meet many Emacs users regularly as I don't work in tech I'm just interested in it. I've met Emacs and vim users at a clojure meet up but that isn't exactly shocking.
1. Install Emacs
2. Finds magit
3. Questions reality before swimming in new found joy
Alas the process of integrating any outside code into Emacs is tangled behind three layers of bulletproof glass.
I'm not against the glass, as it's a good defence against hostile thieves, but it sure kills any desire to merge outside code
And why would I be doing that? Configuring and learning your work tools is part of work, it should be done in work time.
I don't see an advantage of using it outside of the terminal in the first place to be honest.
That's the good part about vim. Or if it's complicated for you, use nano. Done. Editing of files while you're in the terminal.
And yes vimscript is annoying, but it seems to be simple enough for most of the basic stuff.
Otherwise there are plenty of GUI editors that work fine.
Accepting the terminal version is accepting an inferior environment with no upside.
TRAMP sounds nice but a lot of times I can't have emacs on the other side. And vim with screen/tmux works fine
1. Install Emacs
2. Sync existing config via git
3. Work
New employee 4 workflow at company X:
1. Install Emacs
2. Spend 2 hours learning default Emacs
3. Work
New employee 5 workflow at company X:
1. Install Emacs
2. Spend 1 - 2 hours learning default Emacs
3. Spend 2 - 4 hours googling interesting Emacs packages, in each case going to their GitHub repo to read the directions, adding a use package form to your config with the settings that seem best from reading the directions and testing it to see if you like it until you have a useful set of functionality
4. Work
You can probably spend plenty of additional time tweaking emacs to be everything from your mail client, your music player, your IRC client, insert task here but if you do this in the time you would be watching Netflix instead of the time you are supposed to be working you probably wont have trouble getting your work done.
I literally have no idea what you are talking about insofar as TTY settings, themes, indexing bugs highlighting bugs, or constant workarounds. I installed Emacs the graphical application, opted to spend 2 hours reading a book wherein I learned how to use emacs and picked a theme by searching for the string emacs theme and picking one that looked cool. I ran package-install typed the name of the theme, hit enter and evaluated (load-theme 'theme) in my config.
I have no idea why you would be running Emacs in a terminal in the first place.