It's basically the same as the distribution from http://emacsformacosx.com, but it supports various enhancements made for mac, eg. resize text size with trackpad, smooth buffer scrolling and SVG support, which is quite convenient when used with the jupyter notebook interface and producing plots. See for instance : http://imgur.com/gallery/vEI2z.
As an aside, I'm looking forward to better support for text scaling in future [2,3] as it's a feature that (if it was compatible with autocomplete and company-mode) fits my workflow better than zoom-frm.
I've been trying Spacemacs with Evil mode on (I'm a regular Vim user), and I can kind of manage to use it for day-to-day editing and running Make, but it feels like I'm about to be eaten by snakes because I now have to deal with three additional meta key-combos (alt-x, C-c and space-m) in addition to the one I had for i3 (now banished from alt to Win) and I also have to learn escape codes to use my terminal and use them a lot to Vim on remote hosts over SSH.
The built-in tutorial is good. It gets you through the basics of navigating.
Even after having used it for a few years, I enjoyed Mastering Emacs . There are several "getting started" articles on the website and if you find them helpful, the book is also good, in my opinion.
Print out one of the many reference cards available (the official one is available on the Gnu website ).
Try org-mode , which is built in. It's extremely useful and a gateway to emacs.
EDIT: Oh, and for remote hosts, I find it easiest to connect with Emacs, rather than connect and try to run Emacs from the remote host.
(side note, this is one of the best parts of org-mode, it supports remote links to files. When you open the link, it will open it in a buffer and depending on your config, even switch to the correct mode).
On the same page there's a tip to set up dired (an emacs file browser) to browse the remote machine and open files within emacs.
You can also run eshell or ansi-term from within emacs, if that's what you need to do.
So I guess I don't find much need to run a client system, but I'm not 100% sure what your needs are.
I tend to forget there's a more reasons I develop on Debian Stable than "it's convenient to standardize on something you can run on prod".
I am using evil mode, Helm, Projectile and Jedi for completion, and even though everything is more or less configured and took me around 300 lines of elisp I still find all the time defaults that are completely different to vim and I'll have to fix at some point and I am not sure how much time and code it will take to make it feel comfortable. Just a few problems from the top of my head:
- evil-mode "u" to undo changes sometimes works and sometimes does crazy stuff. I think it has something to do with incompatible modes, specially org-mode.
- Tab doesn't work, I'll have to investigate how to make it work properly.
- The defaults for Projectile for opening files inside a project look and feel horrible, it's configurable but I'll have to investigate and probably spend a few hours writing elisp until I have it working to my taste.
- Things like ":set nowrap" don't seem to work in evil-mode, I'll have to investigate how to do the same in emacs.
- The completion is kind of weird and it appears automatically instead of using a key to activate it. Again it's configurable, but I'll have to spend a bunch of time getting it to work as I want.
- If you do ":e path/to/file" and then you try to open another file from inside emacs using ":e [TAB]" it will work as if you changed to "path/to" instead of the original directory.
And this is just from the top of my head without having used it for a few weeks now as I don't have the time to configure all that stuff. I'd say that evil-mode is not transparent enough to make the change simple.
Tab doesn't work, I'll have to investigate how to make it work properly.
You mean for auto-complete? I think I had to do this under dotspacemacs/user-config:
(define-key evil-insert-state-map (kbd "<C-tab>") 'hippie-expand)
This worked for me, also under dotspacemacs/user-config:
(add-hook 'text-mode-hook 'spacemacs/toggle-visual-line-navigation-on)
After 15 years of vim, it took me a few weeks before I was using Spacemacs more often, but now I only use vim for quick changes when I'm sshed into a server. Took a lot of googling and yak shaving, but so far I'm happy and getting more productive with time. Good luck with the other issues.
My impression is, we might both benefit from starting from a bare-bones Emacs setup and expanding that by hand.
I guess vanilla Emacs would be the most bare-bones experience, or at least the most bare-bones experience you can find help for on Google (which kinda hurts me to say, but DDG has worthless search results and only sticks in my browsers because of the !bang functionality).
What really helped me get started was using a specific tool/ language. After playing around in Clojure for a while, I learned how to use emacs for a better REPL experience, but I did everything else in Sublime. Most of my school work at the time was in python so I worked on switching that workflow over to emacs. Eventually got pretty comfortable with python too. A few years later and it's now my main editor. It took a few days to figure things out, and a few months to get really comfortable, but I'm now really happy.
I run emacs in window mode and rarely use emacs in the terminal for the same reasons you mentioned. At some point I started using projectile for project management and now I can fuzzy fine files and fuzzy find projects on my system without needing to switch to the terminal. And now if I'm in a terminal, it's probably because I'm using vim on some remote host.
shell and multi-term have been very uncomfortabe to me, while I really liked Evil mode, the Rust linter + formatter + Cargo integration and Projectile, and Helm was pretty nice as well.
I don't need 200+ key combinations off my leader. I have about 10 for the things I use often, and if I find myself pulling up commands from Alt+X (mapped to space x) regularly, I add that to a new leader mapping.
Use-package is really convenient to learn for setting up your config.
Other than that, the things I find I can't live without:
If you take a look at spacemacs's GitHub, dive into their "layers" and pop open the packages file for any given layer for inspiration of other things to add for your desired languages/features. But integrate then yourself given the packages' instructions. You'll be far better off knowing your setup intimately than learning to skim the very large surface area of spacemacs.
I disagree. spacemacs is not all that scary or hard. it's a thin configuration over emacs packages that all work well together. Take for instance the java layer: it has some configs to make completion work well, syntax highlighting, add things to the "mode leader menu that changes per file type" and a few other things. ootb spacemacs works very well and is a pretty good experience.
Did you start with Spacemacs or did you have prior experience and understanding of Emacs?
I jumped into spacemacs and figured out how to do the vimrc bindings that I had in emacs lisp. I watched a few videos from the creator of spacemacs to see how he configured his and to see what was the way to navigate files in spacemacs correctly.
watch a magit video too... that program(I say program because it's basically full git well done) is phenomenal.
hit me up on the gitter.im channel for spacemacs if you have questions on it or emacs.
1. https://www.youtube.com/watch?v=HKF41ivkBb0 (basics of spacemacs... also check out his channel for a complete dive into each of the prefixes and how to use them)
2. https://www.youtube.com/watch?v=vQO7F2Q9DwA (basics of magit)
3. https://www.youtube.com/watch?v=mtliRYQd0j4 (more advanced features of magit like rebasing interactively and easily.)
It has sane defaults and contextual tips that help when you're getting started (and can turn off later).
Some of it has been subsumed into newer emacs releases.
In general, find out which modes are considered best for whatever you are doing, install them, and then learn how to modify the configuration file to customize how the rest of the UI works.
The text editor, the extensions, and elisp. Pick a use case you really want to get into (Editing code in language X) and dig into that one use case first. Or taking notes (Learn Org mode). But pick just /one/ use case to start your practice.
Learn the editor:
Work through it up to chapter 9. Practice each command. There is (mostly) a rhythm. Memorize and emblazon the "describe key" shortcut into thy mind. Clear your mental desk and just do it for 30 minutes. It really isn't that bad, you just have to give it a little time and practice.
Packages / Modes:
There are a few packages in Emacs that are life savers. Get melpa working. Install and learn helm. Helm provides a completion buffer system for things like file selection and and commands. Helm is that /one/ thing I can't live without for extended Emacs usage.
If this is going to be more than just a toe in endeavor, you need to learn lisp. When you learn the rudiments of elisp and build a couple of small modes or extensions for yourself or customize existing modes a little so many things about emacs just "click". Want to bang out some quick math or do a quick base 64 decode? An example document:
This is a document where I am thinking.
Oh, I needed to do some quick math:
(- 2017 1980)[C-x e] -- result appears in Message area.
Things and concepts not to miss:
CUA mode / block selection, macros (very easy and nice), regions, buffers, point, mark, registers. Things you might not think much about: The kill ring. Learn and read about the kill ring.
M-x = never remember all the shortcuts again. With helm doing fuzzy matching you only have to remember much easier to remember english names for things. Naming is consistent for modes too, so to start searching for "what was that Org mode shortcut?" Start typing 'org pro' oh yeah, org promote! [Whack enter] indents a sub tree in my notes. Then I usually remember the shortcut from there out because it is shown on the commands. M-x along with describe key are life savers as you can go from shortcut to function name and function name to shortcut and you can lazily search through commands and buffers. Helm makes buffers easy.
1.) Learn the editor Emacs and focus on editing on specific type of document (Markdown, Org, programming language). Follow whatever popular setup guide you find for document type X.
2.) Learn the extensions Emacs. Helm is a must-try.
3.) Learn elisp and get used to the idea you are in a giant lisp machine. Running lisp code /anywhere, anytime/ in your documents is awesome.
4.) Learn the little tips and tricks.
5.) Use evil mode if you must, but I have found being fluent in Emacs is great (iPython, for example, is very Emacs biased in its readline / shortcuts). Tons of other tools (mutt) will go with vim like bindings, so taking the time to be fluent in both means you are almost guaranteed to have the right shortcuts in your brain.
6.) I feel your pain about the shortcuts. I have it mostly down to 3: Emacs, Tmux, i3. I try to ram everything through that set of shortcuts, and then a small set of my tools I use a lot use vim bindings, and I am ok with that (mutt, mitmproxy).
Would you happen to have ideas about pinky-saving layouts/modifications to Emacs? I'm not quite ready to ascend to Dvorak layouts but anything short of that I'll try, I'll need to with the state of my fingers.
It's my first week, so I guess I should read the manual instead of deep-diving without scuba gear and trying to manage with Evil-tutor and wishful thinking :')
I'll start with Org mode, I've been meaning to move away from Google Calendar and into Org mode for months anyway.
Thanks again :)
Work through that before any other lisp resource. I found it he most authoritative.
Caps to control is a life saver. I mostly roll with default key bindings. It just makes life easier. I don't have any hand issues. If you do you might rethink shortcuts .... Some folks are convinced key chording is not good for their hands, but I don't have an issue with it. I don't even notice it. Good luck if that is a concern, but Emacs is extremely customizable so that helps, but get at least some level of muscle memory for the default key bindings .
Once you know what you use a lot and have the basics down you can figure out how to start customizing.
Anyway, if you absolutely want to learn something else, I'd suggest going the other way 'round, really: start with something minimal and work your way up from there.
For the first 1-2 years, I think, I've used Emacs as little more than a glorified Notepad clone (in fact, I even used it with cua-mode). I think my .emacs file was barely ten lines long. I was transitioning to Emacs from nedit, an old-ish Unix editor with a Motif UI that was getting increasingly difficult to digest and kept crashing and had trouble with Unicode and man I'm old... anyway, all I really needed it to do was let me write text and paint it in pretty colors sometimes.
I then sort of picked up its features one by one, as I needed them. The keybindings came first, because it was weird the arrow keys for motion and the other keys for everything else. Then I got a larger monitor and I could fit more than two windows on it and I installed window-mode so that I could switch between windows with M-1, M-2 and so on.
(Please remember this was 2005 or 2006 or something, a 21" CRT was a big deal for me...)
That's pretty much how I picked up everything else: first big C project was how I picked up xrefactory, then xcscope. First time I had to do big merges was how I picked up ediff, and so on.
The best thing about having something as scriptable and customizable as emacs is being able to make it work exactly the way you want it. Making it work exactly the way someone else wants it sort of defeats the purpose, I mean, any editor already works the way someone else wants it.
Edit: ah, yes, to address some of your pain points:
- Remote editing: look into something called tramp-mode. It's not perfect, and I, for one, use it sparingly, but it may fit your use case.
- Weird key combinations: I'm not sure what to say other than "you get used to them". It may be worth looking into how i3 deals with this stuff, too. I no longer use a tiling WM, but when I used ratpoison, it fit near Emacs pretty well -- I bound C-t to Ratpoison's prefix key, and just didn't use C-t for anything in Emacs. But then again, Ratpoison (and its successort, scrotwm) were both written by Emacs enthusiasts, and used similar key sequences.
If you're curious about anything else, ask away :-)
Last thing I heard was that Guile-Elisp (and by consequence Guile-Emacs) is working, but very slow. That can be fixed but requires work. Also, Emacs internally uses a different string representation from Guile. This makes the transition between languages tough and some more glue is required.
IMHO Guile-Emacs is "nearly there". I.e. with just a little more work it could have enough momentum and attract developers to be on the trajectory of becoming the default elisp implementation in the long term.
Having the new Guile 2.2 VM drive Emacs would definitely improve things. And the C-codebase could become considerably smaller and cleaner.
Until Guile will work natively on all major operating systems, I see no future for GuileEmacs.
I really can't understand the objections from some people in Emacs land, except for those that would prefer a Common Lisp-based Emacs, but that's not what we've got. We've got Guile, and while that might not be as great as Common Lisp (in their eyes, not mine, for me Scheme is preferable), it's still a lot better than elisp. Rejecting Guile and sticking with elisp just makes no sense to me at all.
Keep in mind that having emacs be based on Guile does not mean that all the elisp emacs packages have to be jettisoned. They will still run as elisp under Guile, and you can continue writing scripts in elisp and have them continue to run under a Guile-based emacs.
Isn't that so 1990's?
Please I mean no disrespect...I was first exposed to EMACS in the late 80's if I remember correctly and have followed it's growth over the many years since, but I can't help but feel that introducing non-blocking threading is something that should have happened long ago.
There's hacks for some of these, but having threads natively will be really nice.
Mu4e is pretty good in this respect: it offloads most of the mailbox processing work to the `mu` command, which it runs asynchronously. I fetch my email with a system service, external to Emacs.
Planning to write a blog post about this configuration, but in the meantime I am happy to share privately - email@example.com
Nonetheless, very happy with it once I put in my relatively small config.
For new users and people who run emacs by mistake or to just check it out maybe?
But I agree with you, these days disabling toolbar and menu bar is my first action when configuring a new emacs environment.
It still has few rough edges, so may not be for everybody.
1. If Emacs hangs/pauses, the window manager hangs/pauses. Can't really do anything in X so have to switch to a virtual console.
2. GIMP stopped bringing up working file dialogs. I think it is some EXWM configuration change I made.
You might also have issues with tooltips/popups depending on your EXWM configuration.
I get that you meant it in comparison to 230k, but in the modern world I find it hilarious that a 930k website is being called (essentially) heavy. If only...