6 ms·
Basic Emacs lisp is well worth learning. It takes Emacs from being an editor to being your editor. With something like Eclipse, even adding a little bit of fun
by tikhonj 13y ago
Basic Emacs lisp is well worth learning. It takes Emacs from being an editor to being your editor.
With something like Eclipse, even adding a little bit of functionality is an undertaking. You have to create a project, write a bunch of boilerplate, load it and so on. With Emacs, it's basically effortless: a line or two of elisp can do wonders. Sometimes I add functionality by just executing elisp directly (with M-:), without even bothering to put it in a file! It's that easy.
This has really changed how I work. Now I don't think twice about having some throw-away elisp for just one project. Or even just one file! Modifying the editor (in small ways) becomes an action almost as natural as copy and paste. Now Emacs is like a jazz performance, with room for improvisation: never the same editor twice.
Emacs is also the perfect development environment for Emacs lisp. (Who would have guessed?) It's the most integrated system I've ever seen; there is an intuitive and remarkably consistent link between the lisp code and the editor itself. I usually know how some bit of elisp corresponds to an action and vice-versa. And if I don't, the incredible interactive help system is, well, helpful: I can easily look up what function a keybinding calls or what keys are bound to a function. These days, I do it instinctively, without thinking. Throw in Emacs's general lisp prowess (paredit is incredible), the ability to randomly evaluate an expression and see the results immediately as well as the ease of inspecting variables and you have a very remarkable environment.
15 minutes as the key to all this? There's no question! Since you're going to be using your editor for years, it's well worth 15 hours or 15 days or even 15 weeks. (And since it's Emacs, you'll end up using it for more than just programming: LaTeX, org-mode, blogging, chatting, email...)
Go for it!
- recuter 13y agoAn excuse to dive into lisp like that just might pull me away from Vim (Vimscript is terrible, sigh).
- terhechte 13y agoHave a Look at Evil, really good vim bindings for emacs
- krisajenkins 13y ago+1. Evil is great. I think it's made Emacs my favourite implementation of Vi yet.
- sillysaurus 13y agoWell, the problem is that these bindings don't usually implement the corner case Vim functionality I've come to rely on over the years. Can it record macros perfectly? Does :%s/foo/bar/ work? How about selecting, then :s/foo/bar/gi? Does the period key reproduce all actions properly? How about :%s/foo\([0-9]+\)/bar\1/ ? Do all of the basic actions do exactly the same thing as they do in a vim editor? Does % take you to the nearest parens or brackets, then cycle between the opening and closing one? If so, I'm sold. These aren't just random desires -- all of these are necessary for anyone who thinks in Vim. A few years ago I tried some emacs vim simulator and it had glaring flaws in multiple categories. Vimpulse or Viper or something, I think. It seems like it's a catch 22 because anyone sufficiently skilled with emacs to design a perfect vim simulator also has no reason to do so, since they're emacs masters. (I'm on a phone else I'd check out evil now.)
- sunesimonsen 13y agoIt actually works similar enough that I switch between Vim and Evil daily without getting annoyed. I usually use Vim from the terminal. The follow things you asked about are all working: Macros Repeat :'<,'>s/foo/bar/gi :%s/foo\(bar\)/bar\1/ It is very actively developed and quite stable. There are of cause Vim features that are not implemented yet, but the core seams to be very well covered.
- deleted 13y ago[deleted]
- lucian1900 13y agoThe Python bindings are reasonable, much better than Vimscript. I've been switching between Vim+python and Emacs+Evil for a bit.
- mahmoudimus 13y agoThis is basically the reason why I switched from Vim to Emacs.
- agumonkey 13y agoOn top of paredit, try redshank http://www.foldr.org/~michaelw/emacs/redshank/ http://www.foldr.org/~michaelw/emacs/redshank/ (process s-exp to refactor etc) This is taken from John Wiegley's talk at emacs conf, here's a little summary of his emacs environment btw : https://gist.github.com/jwiegley/5277578 https://gist.github.com/jwiegley/5277578
- TomDavey 13y agoI was interested to see that Wiegley's config file is notated in org-mode, using the Literate Programming extensions that come built into Org. That's why the file looks more like documentation than code. For Emacs to actually evaluate the file, it must first be tangled to an .el file, but tangling the file is a trivial step. I write my own Elisp the same way, as .org files. Thanks for the link and Redshank too.
- samatman 13y agoThis is why I'm eagerly watching Light Table releases waiting for the "good enough" moment. It's going to have the advantages you mentioned, except in Clojure(script), which is, er, more broadly applicable. The GUI being bog-standard Webkit is another major plus. Emacs has had an astonishing run but is just slightly too opinionated for me to have taken the plunge. The promise of light table has kept me working in sublime for now (with a bit of Catnip IDE on the side).
- davexunit 13y agoLightTable is proprietary software. Please use Emacs instead.
- samatman 13y agoThe facts are more complex. "I'm a firm believer in open source software and open source technologies. I can guarantee you that Light Table will be built on top of the technologies that are freely available to us today. As such, I believe it only fair that the core of Light Table be open sourced once it is launched, while some of the plugins may remained closed source. At some level, this is an experiment in how open source and business can mix - it will be educational for us all." http://www.chris-granger.com/2012/04/15/light-tables-numbers/ http://www.chris-granger.com/2012/04/15/light-tables-numbers... I take this promise in good faith, unless I see reason to believe it will be broken.
- davexunit 13y agoI don't have high hopes. 1) He's not working in the open, he just says "I will free it, honest." Maybe he'll go through with it, but as of now he's distributing proprietary software. 2) He says that some of the plugins will be nonfree. We know that through Emacs that the plugins are essentially everything. Nonfree plugins means a nonfree editor. I'll be sticking with Emacs. Emacs is still improving. There is a project to replace the existing ELisp VM with GNU Guile, which will improve performance and bring many new features, such as an FFI and threading.