I would encourage would-be Elisp hackers to read the info manual "An Introduction to Programming in Emacs Lisp" that is bundled with your Emacs (`C-h i` then select "Emacs Lisp Intro" from the Table of Contents) as it enables you to evaluate the example lisp forms in-line in addition to being a really great and pedagogical introduction to elisp.
That was actually quite helpful. I've had the toughest time "thinking in Lisp" as I'm told I have to do to get my head around it (also because I work with the C++/C#/PHP family and switching between them and Lisp doesn't help).
I really appreciate the simple instructions in that regard.
I'm not a professional programmer, but I spend all day in Emacs primarily because of org-mode. Two years ago I read about org-mode here on HN and was inspired to give Emacs a shot. Today Emacs is my main technical hobby. Extending Emacs with Elisp is a pleasure and a joy. My various init files total over 3,000 lines of code that I wrote my own little self.
That said, while I remain incredibly impressed with the integrated documentation system, especially the Info manuals for their sheer literacy and clarity, I discovered over time that it doesn't adequately teach you "the Lisp way." Explanations of the basic concepts -- like a symbol for crying out loud -- are scattered and not really complete, leading to frustration as I got deeper into extending Emacs.
For me, the light bulb went off after I worked through Seibel's Practical Common Lisp. I've also read chunks of PG's On Lisp. Together these two outstanding books resulted in an epiphany regarding Lisp and the functional approach in general.
The result is that, where before I couldn't figure out Emacs's own Elisp sources (i.e., "Why is this function written this way, and not that way? Why do I see this idiom so often, what's it doing?"), now I can. The payoff for writing my own Elisp has been incalculable. Now I'm fired up to read SICP, and Felleisen et al, hoping to learn more about functional programming.
Allow me to suggest Coursera. They have nice courses about FP. Somehow in simple -> difficult order.
Systematic Program Design by Gregor Kicsalez (I believe influenced by HtDP).
Programming Languages by Dan Grossman. (50 50 HtDP SICP and Brown University material)*
Functional Programming using Scala by Martin Odersky (influenced by SICP).
In case you can already do the SICP exercises without issues then you won't need these, but otherwise, the deadlines and automatic grader were great ways to keep a regular pace in learning.
*) this course focuses on semantics, and language design, the problems are not hard applied problem solving, that's why I put it in 2nd, but they can twist your mind quite a bit when dealing with different meta-levels.
- Basically anything you can do in a terminal, and more (it'll display/process images, PDF, SVG)
For most of these hardcore users, it's simply more convenient to stay in a highly programmable environment than it is to go and use an "end user" tool.
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...)
Well, 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.
It 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:
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.
No, Emacs should be configured to your liking. The default Emacs keybindings (especially the more complex ones for common things) suck.
That said, you're still using Vim keybindings within Emacs and for some operations that Vim has no equivalent for you will need some Emacs knowledge. Also, some thing that Vim does have an equivalent for are easier to do in Emacs.
You cannot step into Emacs + evil-mode thinking you will never need to know anything else. You would be well advised to learn some Emacs basics and then help functionality.
For day-to-day operations like buffer editing you'll be able to use you Vim muscle memory.
It's pretty damn close. I eventually gave up on emacs + evil and just went back to vim + fireplace for clojure, mostly because I didn't like having to set up my own bindings for all the plugins, even if basic editing worked well. Also, I can't find anything remotely as good as nerdtree, if someone knows of something, please let me know.
I've never encountered a situation where . didn't do what I expected.
The man commented about evil. I don't see how your experience with viper is relevant. Evil is damn good (as a long time vim user of 5+ years). I'd recommend you try it again. Plus, vim indentation behavior sucks compared to emacs. Give it a try, you might be surprised.
As others have said, Evil's emulation is really good. I've ran into the same problems you have mentioned in other Vim emulation layers so I had the same suspicious with Evil. Evil didn't disappoint. Very good so far.
I 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.
This 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).
"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."
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.
Ha, this is perfectly timed. After years of being a vi/vim user (not for any particular reason, it's just what I learned a few years back and just stuck with), I decided to start running through the Emacs tutorial for the hell of it yesterday.
I really miss Lisp from my college days, and being able to work it back into my regular workflow just sounded like a fun idea.
I read through this tutorial and its really a great introduction, really well written and very clear. Nice job!
After a decade of Emacs, I never had wrist problems, but I did end up developing pinky problems, due to remapping Ctrl to Caps Lock.
I tried foot pedals (and still have them under my desk). They were better than nothing, but after I switched to the Kinesis Advantage keyboard I ended up not using them anymore. Hitting Ctrl+Alt with your thumbs is more convenient than hitting them with your feet, especially since I tend to fidget a lot. Another advantage (no pun intended) is that the arrow keys are convenient to hit, which lets you remap several standard Emacs keybindings. For example, I use C-b to switch buffers.
Neither switching keyboards nor using foot pedals solved my hand pain, however. I ended up having to take more drastic measures: I switched to the carpalx QGMLWB keyboard layout[1]. One of the advantages of the carpalx approach is the clear and powerful mathematical model which quantifies the effectiveness of keyboard layouts. I was able to select a layout that minimizes pinky strain--if I had switched to Dvorak or Colemak, I would have increased my pinky strain.
If you are emacs user, that's not a problem. You just change them to whatever you want. Besides, food pedals is not so crazy ideal. Any time you must do something meta- or control with any software, you end up doing movements that are not so natural.
> [B]ut the keybindings are horrendous. Even if they don't cause hand pain they're long-winded and distracting.
Ha, after 26 years using Emacs I find Vim's keybindings long-winded and distracting. To each their own. However, unlike many people I don't dismiss vi because of unfamiliarity, or use them as an excuse not to learn the editor. I try to use it all the time, but I can never seem to train myself to do non-trivial things with it.
I have the similar problem with other editors: I've seen people rave about Sublime Text, yet none of its killer features (modulo multiple selections) really strike me as worth switching. And any of its features I think I want I could (conceivably) implement in Emacs, so...
I use my thumbs for control and alt on a regular (scissor type) keyboard. I remap alt to control and super to alt and have had no problem since I switched, about 4 or 5 years ago.
Emacs is a miracle, no doubts. It is self-descriptive and self-contained system, like Smalltalk (you could lookup any function, variable or even key-binding, without a fancy browser, but in a way that is good enough). There is nothing much to say, actually. Emacs is just a wonderful thing.
Indeed. The most value I got from from learning to customize Emacs wasn't the functionality I implemented but seeing how powerful a domain specific language can be. The ways that Emacs Lisp supports working with text, whether data or code or documents, showed me what I should be aspiring to when I create a DSL.
Peter Van der Linden included a recipe for Oobleck¹ on the last few pages of "Expert C Programming: Deep C Secrets". It's right after the Phony C++ Job Interview Answer Key and right before the paragraph-long rant about Dr Seuss's influence on the software engineering profession.
If you don't know Emacs Lisp, there's no point of using Emacs. You'd probably be more productive in Vim or [insert favorite proprietary editor here].
Emacs Lisp is probably the most featureless language you can think of; it doesn't even do basic threading and the async stuff is a joke. All the major programming language modes are implemented as ad-hoc Elisp regexp parsers making bugs impossible to fix. Virtually _everything_ is implemented in Elisp, because the C code is a gigantic unmaintainable mess. This means that all the pretty high-level stuff like Magit is shit slow. Good features take ages to propagate to upstream, whose reasons are often more political than technical.
However, it is the only programmable editor in the world, and people continue to churn out more and more Elisp. Recent developments like MELPA and Marmalade have made packaging and distributing easier than ever, and users just need to `M-x package-install` to get their favorite packages set up.
The reason Emacs has been so successful is very simple: there is one global environment where all symbols are bound; any package can overshadow any existing symbol (variable/function) from anywhere. There are no "core" functions versus "library" functions; any package can modify very "core" behavior (for instance, find-file) very easily [1]. Ofcourse, this has severe downsides: you can eval bad code and screw up your Emacs environment pretty badly (it might even refuse to quit); often the only way to recover is to restart Emacs, flushing the environment.
I'd say: learn as much as you can about editors from this monster; enjoy tinkering with it. Hopefully, a fresh community will come together to build another programmable editor soon.
I always get a chuckle out of people complaining that Emacs is too slow. Maybe I've just "gotten used to it", but when I first started using it I was sharing a Sun 3 with ten or fifteen other people.
I'd also argue that modes in other editors are ad hoc regexp parsers in some other form... regexps, in the hands of someone who knows what they're doing, work well.
And yes, virtually everything is implemented in Emacs Lisp. That's the whole point.
People have been trying to build "another programmable editor" for 30 decades. It hasn't happened yet. Why do you think it will happen soon?
There are definitely other programmable text editors available. I use Textadept, which is like Emacs with Lua and minimalism instead of Elisp and evrything-but-the-kitchen-sinkness. Of course it doesn't do nearly all that Emacs does but it feels as programmable to me.
You're not going to notice any lags if you use Emacs to work on toy projects. Try a non-trivial operation on a repository of respectable size, like linux.git: if you don't classify those operations as being "completely unusable", you're living in the dark ages.
Incorrect. Several proprietary IDEs use real parsers. Which is precisely why they're able to provide all sorts of magic functionality like "refactor". And no, regular expressions don't "work well" by a stretch: even the common modes like shell-script-mode, perl-mode (cperl-mode is slightly better), python-mode are riddled with bugs. If you look at the relatively new js2-mode, you'll notice that the parser is an Elisp port of the Rhino parser. Also, Semantic Bovinator from the CEDET project was recently merged into emacs, although it doesn't have major users yet. Precisely because regular expressions aren't "good enough".
The reason everything is implemented in Emacs Lisp is because there is no alternative: Elisp doesn't have an FFI to speak of. Otherwise, I don't see the problem with using existing parsers; unless your "point" is to take everyone back to the dark ages.
No matter how you look at it, there are more alternatives to Vim/Emacs than there were 30 years ago. A lot of people are happy with TextMate, Coda, Visual Studio, Eclipse. It's not like there's something special about the year 2013, but what I meant is: Emacs will become extinct, and that is inevitable. And yes, I'm hoping for some kind of programmable editor to take its place soon.
Try textadept! It is structured in a way similar to Emacs: small core in C, most functionality written in Lua. In my opnion the only thing better about Elisp than Lua is that it has macros, everything else, from scoping to speed and coroutines is probably better in Lua. And the icing on the cake? The parsers use LPEG grammars and not regex!
Of course there is a downside: it has a tiny fraction of Emacs's functionality (even without considering non-default Emacs packages!), but it mostly has the fraction I use and is simpler enough than Emacs that I am more likely to extend it than Emacs.
(If you already knew about textadept but don't consider it a "programmable text editor", please let me know why.)
Let's put aside the fact that it's a one-man project for one second. I tried building it from sources for an hour before giving up: it depends on lots of custom packages which it fetches and custom patches [1]. Okay, so it has a really tiny C core [2], upon which lua modules build up the rest of the editor. I'm impressed: yes, this certainly qualifies as a programmable editor. It has some interesting ideas worth exploring; thanks.
As an open source project, it is a total failure. If a potential contributor can't clone and build the sources in under 10 minutes (or an hour!), it's no better than a research paper. It hasn't been packaged for any major distributions, and it has no users.
p.s- I did manage to grab a fairly recent build from AUR. As far as out-of-the box functionality is concerned, it's absolute rubbish; opening files and navigating buffer is a chore, and I couldn't even get it to indent properly.
I didn't try building it from source, so I didn't know about any difficulties in doing so. I agree that that is a serious issue. In particular I wonder if patching Scintilla and Lua is really necessary...
About opening files and navigating buffers: I must have been a very naive Emacs user because I didn't really miss anything basic. I open files by typing the file name, with tab completion. I switch to buffers in two ways: if I have only 2 or 3 buffers, I advance between them; if I have more, I jump between them by typing portions of their their names. To navigate inside a buffer all I use are motions by character, word, line, paragraph, page; jumping to matching parenthesis, bracket or brace; incremental search; jumping to line numbers. All of this is present in Textadept, so I felt the basics were covered. (I am sure that more expert Emacs users will definitely find lots to miss in Textadept.)
Indenting of course is much more primitive in Textadept, that's definitely true. I'm used to indenting manually (well, not totally manually: having each newline start with the indentation of the previous one and then adding or removing indentation using tab and S-tab), from using other non-Emacs editors and esoteric languages for which no Emacs mode had been written at the time, so I didn't mind that much.
The first thing I really missed was eval-last-sexp, so I quickly wrote a basic substitute (since Lua doesn't have those easy to match parenthesis around everything, I evaluate either the selection or, if empty, the whole line; that works for me). I have the Lua code evaluated in an environment where the usual print function inserts text in the buffer instead of writing to stdout.
70 comments
[ 2.9 ms ] story [ 133 ms ] threadHey, just M-x doctor
I really appreciate the simple instructions in that regard.
That said, while I remain incredibly impressed with the integrated documentation system, especially the Info manuals for their sheer literacy and clarity, I discovered over time that it doesn't adequately teach you "the Lisp way." Explanations of the basic concepts -- like a symbol for crying out loud -- are scattered and not really complete, leading to frustration as I got deeper into extending Emacs.
For me, the light bulb went off after I worked through Seibel's Practical Common Lisp. I've also read chunks of PG's On Lisp. Together these two outstanding books resulted in an epiphany regarding Lisp and the functional approach in general.
The result is that, where before I couldn't figure out Emacs's own Elisp sources (i.e., "Why is this function written this way, and not that way? Why do I see this idiom so often, what's it doing?"), now I can. The payoff for writing my own Elisp has been incalculable. Now I'm fired up to read SICP, and Felleisen et al, hoping to learn more about functional programming.
Systematic Program Design by Gregor Kicsalez (I believe influenced by HtDP). Programming Languages by Dan Grossman. (50 50 HtDP SICP and Brown University material)* Functional Programming using Scala by Martin Odersky (influenced by SICP).
In case you can already do the SICP exercises without issues then you won't need these, but otherwise, the deadlines and automatic grader were great ways to keep a regular pace in learning.
*) this course focuses on semantics, and language design, the problems are not hard applied problem solving, that's why I put it in 2nd, but they can twist your mind quite a bit when dealing with different meta-levels.
- Email
- File Management
- Text processing
- IRC
- Newsreading
- Server Admin
- Web browsing (esp. documentation)
- Basically anything you can do in a terminal, and more (it'll display/process images, PDF, SVG)
For most of these hardcore users, it's simply more convenient to stay in a highly programmable environment than it is to go and use an "end user" tool.
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!
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.)
That said, you're still using Vim keybindings within Emacs and for some operations that Vim has no equivalent for you will need some Emacs knowledge. Also, some thing that Vim does have an equivalent for are easier to do in Emacs.
You cannot step into Emacs + evil-mode thinking you will never need to know anything else. You would be well advised to learn some Emacs basics and then help functionality.
For day-to-day operations like buffer editing you'll be able to use you Vim muscle memory.
the :%s/foo/bar/ works
selecting then substituting works.
I've never encountered a situation where . didn't do what I expected.
The man commented about evil. I don't see how your experience with viper is relevant. Evil is damn good (as a long time vim user of 5+ years). I'd recommend you try it again. Plus, vim indentation behavior sucks compared to emacs. Give it a try, you might be surprised.
I've been switching between Vim+python and Emacs+Evil for a bit.
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
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.
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).
"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...
I take this promise in good faith, unless I see reason to believe it will be broken.
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.
If Emacs was what I wanted, I'd have started using it ten years ago. Remember, editors are religion; please be polite.
I really miss Lisp from my college days, and being able to work it back into my regular workflow just sounded like a fun idea.
I read through this tutorial and its really a great introduction, really well written and very clear. Nice job!
emacs is the editor of gods.
A: Foot pedals.
http://bc.tech.coop/blog/041024.html
http://www.cb1.com/~john/computing/emacs/handsfree/pedals.ht...
I tried foot pedals (and still have them under my desk). They were better than nothing, but after I switched to the Kinesis Advantage keyboard I ended up not using them anymore. Hitting Ctrl+Alt with your thumbs is more convenient than hitting them with your feet, especially since I tend to fidget a lot. Another advantage (no pun intended) is that the arrow keys are convenient to hit, which lets you remap several standard Emacs keybindings. For example, I use C-b to switch buffers.
Neither switching keyboards nor using foot pedals solved my hand pain, however. I ended up having to take more drastic measures: I switched to the carpalx QGMLWB keyboard layout[1]. One of the advantages of the carpalx approach is the clear and powerful mathematical model which quantifies the effectiveness of keyboard layouts. I was able to select a layout that minimizes pinky strain--if I had switched to Dvorak or Colemak, I would have increased my pinky strain.
[1]: http://mkweb.bcgsc.ca/carpalx/?full_optimization
That's hilarious.
I get that emacs has technical merit but the keybindings are horrendous. Even if they don't cause hand pain they're long-winded and distracting.
Ha, after 26 years using Emacs I find Vim's keybindings long-winded and distracting. To each their own. However, unlike many people I don't dismiss vi because of unfamiliarity, or use them as an excuse not to learn the editor. I try to use it all the time, but I can never seem to train myself to do non-trivial things with it.
I have the similar problem with other editors: I've seen people rave about Sublime Text, yet none of its killer features (modulo multiple selections) really strike me as worth switching. And any of its features I think I want I could (conceivably) implement in Emacs, so...
2. My biggest gripe about 99.9% of COmputer programming books are: They are long. They are poorly written. They read like a telephone books.
3. I once heard one famous programmer state, I won't read a programming book with more than 500 pages. I think he was off by 400 pages?
4. I truly believe if you take 80% of words out of most books; it would make learning a subject easier.
[1] http://en.wikipedia.org/wiki/Non-newtonian_fluid#Oobleck
Emacs Lisp is probably the most featureless language you can think of; it doesn't even do basic threading and the async stuff is a joke. All the major programming language modes are implemented as ad-hoc Elisp regexp parsers making bugs impossible to fix. Virtually _everything_ is implemented in Elisp, because the C code is a gigantic unmaintainable mess. This means that all the pretty high-level stuff like Magit is shit slow. Good features take ages to propagate to upstream, whose reasons are often more political than technical.
However, it is the only programmable editor in the world, and people continue to churn out more and more Elisp. Recent developments like MELPA and Marmalade have made packaging and distributing easier than ever, and users just need to `M-x package-install` to get their favorite packages set up.
The reason Emacs has been so successful is very simple: there is one global environment where all symbols are bound; any package can overshadow any existing symbol (variable/function) from anywhere. There are no "core" functions versus "library" functions; any package can modify very "core" behavior (for instance, find-file) very easily [1]. Ofcourse, this has severe downsides: you can eval bad code and screw up your Emacs environment pretty badly (it might even refuse to quit); often the only way to recover is to restart Emacs, flushing the environment.
I'd say: learn as much as you can about editors from this monster; enjoy tinkering with it. Hopefully, a fresh community will come together to build another programmable editor soon.
[1]: The exception is the few C builtins.
I'd also argue that modes in other editors are ad hoc regexp parsers in some other form... regexps, in the hands of someone who knows what they're doing, work well.
And yes, virtually everything is implemented in Emacs Lisp. That's the whole point.
People have been trying to build "another programmable editor" for 30 decades. It hasn't happened yet. Why do you think it will happen soon?
Incorrect. Several proprietary IDEs use real parsers. Which is precisely why they're able to provide all sorts of magic functionality like "refactor". And no, regular expressions don't "work well" by a stretch: even the common modes like shell-script-mode, perl-mode (cperl-mode is slightly better), python-mode are riddled with bugs. If you look at the relatively new js2-mode, you'll notice that the parser is an Elisp port of the Rhino parser. Also, Semantic Bovinator from the CEDET project was recently merged into emacs, although it doesn't have major users yet. Precisely because regular expressions aren't "good enough".
The reason everything is implemented in Emacs Lisp is because there is no alternative: Elisp doesn't have an FFI to speak of. Otherwise, I don't see the problem with using existing parsers; unless your "point" is to take everyone back to the dark ages.
No matter how you look at it, there are more alternatives to Vim/Emacs than there were 30 years ago. A lot of people are happy with TextMate, Coda, Visual Studio, Eclipse. It's not like there's something special about the year 2013, but what I meant is: Emacs will become extinct, and that is inevitable. And yes, I'm hoping for some kind of programmable editor to take its place soon.
Of course there is a downside: it has a tiny fraction of Emacs's functionality (even without considering non-default Emacs packages!), but it mostly has the fraction I use and is simpler enough than Emacs that I am more likely to extend it than Emacs.
(If you already knew about textadept but don't consider it a "programmable text editor", please let me know why.)
As an open source project, it is a total failure. If a potential contributor can't clone and build the sources in under 10 minutes (or an hour!), it's no better than a research paper. It hasn't been packaged for any major distributions, and it has no users.
p.s- I did manage to grab a fairly recent build from AUR. As far as out-of-the box functionality is concerned, it's absolute rubbish; opening files and navigating buffer is a chore, and I couldn't even get it to indent properly.
[1]: https://gist.github.com/artagnon/6102996
[2]: https://gist.github.com/artagnon/6103013
About opening files and navigating buffers: I must have been a very naive Emacs user because I didn't really miss anything basic. I open files by typing the file name, with tab completion. I switch to buffers in two ways: if I have only 2 or 3 buffers, I advance between them; if I have more, I jump between them by typing portions of their their names. To navigate inside a buffer all I use are motions by character, word, line, paragraph, page; jumping to matching parenthesis, bracket or brace; incremental search; jumping to line numbers. All of this is present in Textadept, so I felt the basics were covered. (I am sure that more expert Emacs users will definitely find lots to miss in Textadept.)
Indenting of course is much more primitive in Textadept, that's definitely true. I'm used to indenting manually (well, not totally manually: having each newline start with the indentation of the previous one and then adding or removing indentation using tab and S-tab), from using other non-Emacs editors and esoteric languages for which no Emacs mode had been written at the time, so I didn't mind that much.
The first thing I really missed was eval-last-sexp, so I quickly wrote a basic substitute (since Lua doesn't have those easy to match parenthesis around everything, I evaluate either the selection or, if empty, the whole line; that works for me). I have the Lua code evaluated in an environment where the usual print function inserts text in the buffer instead of writing to stdout.