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.
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?
Pretty much, yeah, from what I've seen. Against the shockingly low ambient baseline of "editors that aren't Vim
or Emacs", VS Code's highly usable OOTB experience and broad extension ecosystem are enough of an improvement to constitute a real win despite being so poor by comparison with a thoroughly evolved configuration of either of the Two True Editors.
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.
Ahh, that's not what I was going for. I'm actually just curious. I'm willing to give emacs a try, but it just seems like it has kind of a steep learning curve, so want some strong reasons to know if it's worthwhile. This was the best I could find googling: https://www.reddit.com/r/emacs/comments/8h1cxa/any_long_time...
I mean, a lot of it is just the kind of complex one-off text transformations that would normally require a throwaway script or program to express. (They do in Emacs too, but you can write it as inline Lisp forms in the replacement side of a PCRE find-and-replace, and not deal with any boilerplate.) Refactors and stuff like that all happen through LSP providers, just like in VS Code.
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.
This. After having fiddled around with Emacs over the weekend, having tried out Spacemacs and Doom and working through some tutorials, I concluded that I definitely won't replace VSCode with Emacs for coding any time soon.
As a Git & PIM-Tool, it seems to be useful though.
> 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.
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.
As a counterexample to that somewhat... I initially tried learning emacs with spacemacs, and the amount of customization in spacemacs’s config made it difficult for me to compare it to much of the emacs documentation out there. Whatever documentation spacemacs had at the time was confusing enough to me that it wasn’t quite enough.
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.
If you install Spacemacs from develop branch, don't change the defaults and enable just the git plugin, it's pretty much always going to work just fine unless elpa is down or something.
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... :/
I cannot recommend Spacemacs enough. I was a pretty dedicated Vim user for years but grew tired of the brittle tooling and subpar extensibility and decided to give Emacs a try. My first experience with Emacs was dreadful - the default keybinds were counter-intuitive and hard to use (no, I should not have to remap my control key to caps lock just to avoid carpal tunnel), basic features were absent yet included was a web browser, mail client, etc.
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.
+1 I was really attached to my vim config but decided to try out SpaceVim [1] (the vim version of SpaceMacs) after a stint using VSCode and after reinstalling my OS (before pulling in my usual vim .git) and I was surprised it was almost the same as what I spent years perfecting but with a far better and logical key mapping scheme that fit neatly across plugins + a nice programming language extension/layer scheme.
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.
Well, sort of. Something like spacevim requires some dependencies I imaging. Docker is sort of a package manager, so it makes sense to run the 1.1G docker image to see what you're getting into.
Anyway, this way I saw an issue early on that stopped me from going any further, and saved me much time and heart ache.
Sorry, but that's not true anymore. The spacemacs project has kind of gone off the rails and it doesn't seem like they have any idea about what they really want to do.
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.
New employees 4 and 5 are completely fictitious and only exist in your imagination/reality bubble. In the real world no mortal has ever learned how to use Emacs in 2 hours to be able to work effectively. And like the OC said the documentation for extra packages are horrible, full of bugs and may take additional week to understand how to use effectively.
It's a text editor. You can work when you know enough do common textual operations to add remove and modify text, search through existing text, jump around to different files in the project, and run whatever constitutes a build.
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.
> You can work when you know enough do common textual operations to add remove and modify text, search through existing text, jump around to different files in the project, and run whatever constitutes a build.
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.
Did you mean to ask if I'd ever met an Emacs user? I'm pretty sure we both pass people who haven't heard of any text editor or IDE all the time.
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.
Disclaimer: mostly vim guy. I agree that Emacs is super powerful for power users, don't agree that it's intuitive or easy for new users. Also I found spacemacs to be pretty brittle when I last tried it a year ago.
Agreed on Spacemacs. Seems like a lot of stuff I had to switch to the Develop branch for it to work right. Supposedly the next release is coming out soon which will fix a lot. I’ve since switched to Doom which I like better anyways though.
Think they key here is you read a book whilst the prev op just assumed reading random guides on the Internet would be an appropriate way to learn a piece of software for professional use.
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.