3 ms·

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 Li

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. [1]: The exception is the few C builtins.

treerex 13y ago
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?
- DennisP 13y ago
  Yep, Ben Franklin worked on one, iirc.
- omaranto 13y ago
  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.
- jasonm23 13y ago
  30 Decades!!! wow.
  - James_Duval 13y ago
    Emacs didn't work very well on the Bouchon loom (http://en.wikipedia.org/wiki/Basile_Bouchon http://en.wikipedia.org/wiki/Basile_Bouchon) but dammit, they tried.
- artagnon 13y ago
  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.
omaranto 13y ago
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.)
- sprash 13y ago
  Could some Debian dev please step up and package Textadept. Thx!
- artagnon 13y ago
  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. [1]: https://gist.github.com/artagnon/6102996 https://gist.github.com/artagnon/6102996 [2]: https://gist.github.com/artagnon/6103013 https://gist.github.com/artagnon/6103013
  - omaranto 13y ago
    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.

treerex 13y ago

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?

DennisP 13y ago
Yep, Ben Franklin worked on one, iirc.
omaranto 13y ago
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.
jasonm23 13y ago
30 Decades!!! wow.
- James_Duval 13y ago
  Emacs didn't work very well on the Bouchon loom (http://en.wikipedia.org/wiki/Basile_Bouchon http://en.wikipedia.org/wiki/Basile_Bouchon) but dammit, they tried.
artagnon 13y ago
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.

omaranto 13y ago

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.)

sprash 13y ago
Could some Debian dev please step up and package Textadept. Thx!
artagnon 13y ago
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. [1]: https://gist.github.com/artagnon/6102996 https://gist.github.com/artagnon/6102996 [2]: https://gist.github.com/artagnon/6103013 https://gist.github.com/artagnon/6103013
- omaranto 13y ago
  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.