This is how Emacs is different from other editors. Like the blog posts show - you start with a need and try to find how the existing Emacs LISP code is written. Next, you try to customize it to your need. Finally, you assign it to a keyboard shortcut.
You adapt Emacs to your workflow, just like you adapt Lisp to your problem domain.
Except for the part where you're stuck trying to decipher existing Emacs Lisp. With Python I find I can express what I'm trying to do without too much thought.
Editor? I do not think that word means what you think it means!
Emacs is an abstraction layer for a non-preemptively threaded virtual machine, one application of which involves editing text, sound, video, images, etc.
I've played with it a few times, and just did again. The little "minimap" preview thing on the right side is cute (and disableable) -- it actually helps to provide an aesthetic indication as to when your file is Just Way Too Long. The visual display of tab characters is subtle and attractive, and probably useful to many people trapped in editors that do that stuff invisibly or wrong (it's not as good as dtrt-mode in emacs though, which will auto-guess whitepace conventions, but I'd certainly be pleased if emacs were to implement a similar thing).
But at the same time, I can't actually use the thing. No cursor motion keys available from the home row, seriously? Opening a file brings me up a GUI dialog with minimal (and, relative to the editor, inconsistent) keyboard navigability? The waste of space is awful: six columns wasted on the right side of the screen just to tell me line numbers that emacs just puts in the modeline.
It seems like the kind of editor someone from an IDE would want to use, and which would expose them to "serious programmer's editor" features. It's not going to pull away any emacs or vim users any time soon.
> It seems like the kind of editor someone from an IDE would want to use, and which would expose them to "serious programmer's editor" features
This is indeed what happens and I think it's a good thing : it brings the notion of efficient text editing to the masses.
Recently in my town one of my coworker did a friendly Sublime vs. Vim battle : a Sublime user and him were sitting side by side with their laptop display on the wall and taking turn to show off their favourite editor's features. The audience was mostly web developers (no old Unix neckbeard around) and I could hear at the beginning of the session some condescending remarks toward the "archaic" Vim, which was obviously going to get smashed by the "modern" Sublime. Of course it didn't quite turn out like that and at the end everyone seem to think that while Sublime was more sexy and approachable, Vim was a valid choice as well.
One of my coworker who was using exclusively Eclipse recently started to use Vim after trying Sublime. Sublime had opened his mind to efficient text editing and he started using Vim more often because it's free, ubiquitous and easy to use remotely.
I know several long-time Eclipse users who got seduced by Sublime. They had no idea it was possible to edit text so efficiently. Of course Vim or Emacs can achieve the same level of efficiency and beyond, but Sublime makes it more discoverable. Sublime is good for the reputation of text editors as opposed to IDEs, therefore it's good for Vim and Emacs.
Regarding sublime's API, can you split windows? Invoke subprocesses, and create REPLs?
Genuinely curious, but I think you can do a lot more with Emacs' APIs, and modify core parts of the editor since most of it is written in ELisp and you can easily swap out functions.
Yes, you can do all of those things with sublime's API (https://github.com/wuub/SublimeREPL, https://github.com/SublimeText/Origami). Yes, emacs is more extensible, but not where it matters, really. I.e., I don't think you're going to see any cool feature made with elisp that can't be ported to sublime.
Ok, that's pretty cool. Still doesn't seem as supported by the core APIs though. In Emacs I can run a REPL and attach it to any process with a few lines of code.
I love Sublime Text, but I would argue that Emacs is more extensible in all sorts of places where it really matters.
You can probably add every single feature in emacs to sublime. The 30 earth-years and many, many man-years of features, additions and smoothing of interactions that has gone into emacs, will however take quite some time to come to par with.
See e.g. tramp, org-mode, the vc-modes, gnus, magit, smart indenting etc.
martinced: you have been hell-banned for some, to me, completely opaque reason.
Not really. Emacs Lisp is really powerful but not a beautiful language. The APIs are unnatural and sometimes inconsistent to those who come from non-Lisp background. I got to write tons of "immediate" APIs to make things prettier. No namespace-like feature and undocumented APIs (like the notorius CEDET or how to create a new mode...) are real pain.
One of the things about emacs is its on almost every machine you can find accessible by terminal.
Except when its not, which is why I know enough vi commands to do really simple things. (vi seems to be on every *nix machine without fail).
I'll fully admit that the configuration and lisp scripts are
confusing in emacs. Its almost too configurable. But they are amazingly powerful. Plus emacs has the indispensable (M-x tetris)...
I've looked at Sublime, its a beautiful editor though. It seems to have some good tricks up its sleave as well
TRAMP & eshell would help you achieve 100% your local Emacs productivity on remote machines, and 100% smaller (you actually don't need to install anything on remote machine) :-)
For small plugins yes, it's on par with Emacs, but I've yet to see something like org-mode or tramp in Sublime Text, and it's not open, closed-souce text editor don't last long.
I never stop discovering features in emacs, for example I found out about embedded calc mode yesterday. I was so impressed by it that I made a screencast demoing its features:
http://www.youtube.com/watch?v=OPMgj3XWi8Q
I love emacs, I really do. It is really hard to share customizations with git for emacs in my experience. Right now I'm using prelude + some customizations. I can keep my fork of the prelude repo on my account, and add stuff to /personal . But other than cherry-picks, which would probably get difficult, I really don't know how to contribute back to prelude. pulling the latest version of prelude (or any other preset emacs customization set) requires me to restart emacs, which I normally only do once every other week or so. How do others handle this?
I have two macs that both run emacs. I have a private git repository for my .emacs.d folder (an old mirror can be found here: https://github.com/elarkin/.emacs.d ). I have taken special care to make sure that the init.el file is readable, and can be used with a fresh copy of emacs (without any packages installed) and everything works just fine.
If you want to try it, just brew install emacs --cocoa and clone the repo to ~/.emacs.d
A coworker and I trade snippets of elisp for our configurations over email, and whenever I update the repo on one machine, the other needs to pull it down and evaluate the file (eval-buffer)
I have not found sharing customizations of emacs to be very difficult, but I also don't use any god packages like emacs starter-kit, or prelude (which I haven't heard of). I have let my configuration grow organically.
My emacs automatically downloads and installs all my used packages on first startup on a fresh install. Literally all I have to do on a new box is clone my dotfiles and start emacs.
It's an interesting idea, but I'm not sure how useful it'd be.
The reason Emacs users have their own unique setups is because they tailor the environment to their specific uses and preferences. That's going to be different for everybody.
Posting the entire configuration would add a lot of code that most people just wouldn't be interested in. It's easier to call out the interesting parts.
You adapt Emacs to your workflow, just like you adapt Lisp to your problem domain.