Emacs 24.4 RC 1(lists.gnu.org) |
Emacs 24.4 RC 1(lists.gnu.org) |
"Emacs now supports menus on text-mode terminals. If the terminal supports a mouse, clicking on the menu bar, or on sensitive portions of the mode line or header line, will drop down the menu defined at that position."
More at: http://www.masteringemacs.org/article/whats-new-in-emacs-24-...
For example "M-x tree undo" show me "undo-tree-visualize (C-x u)".
Now I use Helm all over the place: (recent) file opening (within the current project), buffer switching, grepping, etc. It really changed how I interface Emacs.
I think this is more a meme than necessarily a reality - you'll tend to see a lot more comments online from people who think the old joke is funny or who want to validate their own choice than from people who don't care or have tried both without such strong feelings.
In reality, there's really no barrier to 'manage' to use both emacs and vim. If anything, since they're both powerful and configurable programs whose best configuration is personal and some way from the default, it probably is harder to construct your own perfect config in both than for simpler alternatives like web browsers - I guess this may lead to a practical aversion.
Personally, I think vim's modal editing is superb but generally prefer the behaviour of emacs' modes and client model, so I use emacs with evil-mode but have no problem using vim if necessary.
See also casual sports fans who don't understand the game they watch, but understand and enjoy pretending to love one team unconditionally for no particular reason, and hating another team for no reason other than it's fun for them to hate somebody. Ditto for operating system fanboys of all stripes.
But for Haskell and Clojure development, it's hard to beat the tight integration features that Emacs provides (e.g. quickly piping your code or a single function to the REPL for testing). Vim is not designed for this; there are plugins available to approximate it, but it’s a bit hacky and nowhere close to Emacs).
Honestly, it's not hard to learn the basics of both. If you're accustomed to Vim commands, Emacs has `evil-mode`. There's also the slick `god-mode`, which is like Vim's Normal mode for Emacs.
Both tools are great in their own ways. Personally, I regularly use and love them both.
However, I still use Emacs for LaTeX documents via AUCTeX, because I find it far more powerful for basic editing, with commands to insert directives, environments, \item, etc.
ESC:q!
It worked out pretty well as long as I used Emacs in an X window and vi on the command line. But if I ran emacs in a terminal, I automatically started typing vi commands into it.
Inspector[0]: You can click on objects to "inspect" their values. This includes hash-tables, arrays, and closures. In addition you can execute arbitrary code on these objects at any time, even while a program is running.
Trace Dialog[1]: Most Lisp implementations already provide a way to trace procedures. Tracing normally consists of printing the input and the output as each traced procedure is called. Slime provides something much more powerful. Slime's Trace Dialog is similar to trace in that it creates a buffer of the input and output, but instead it is provided in a tree menu format. In addition it is possible to inspect all of the values in the Trace Dialog with the inspector.
Debugger[2]: When an error is thrown in a program, a window pops up which provides several things. You can click on a stack frame to see all of the variables in that frame and then inspect those variables with the inspector. You are also provided with a list of restarts[3]. In addition, you can return a value from a given stack frame, or retry a procedure call on the stack frame (you may have modified the definitions of some procedures before you did this), and have the program continue as if nothing had ever happened.
There are also many other features, such as the ability to macroexpand code by clicking on it, to look up every procedure which calls a given procedure, to look up every place in which a given variable is set, and many other awesome features.
[0] http://common-lisp.net/project/slime/doc/html/Inspector.html
[1] http://common-lisp.net/project/slime/doc/html/SLIME-Trace-Di...
[2] http://common-lisp.net/project/slime/doc/html/Debugger.html#...
[3] http://en.wikibooks.org/wiki/Common_Lisp/Advanced_topics/Con...
I like the cider+nrepl workflow myself. You can edit your code, reevaluate it, and test it without having to restart your JVM. As you can imagine, this really speeds up development.
Also, though I haven't quite grokked all the barfing and slurping yet, paredit has really become a huge part of my code writing and editing in Emacs for Clojure code. I am on the cusp of getting barfing and slurping working for me now ;)
- Swank/Slime (Lisp inferior modes) that allow you to write lisp, evaluate within the editor, see your results in a buffer. Offer auto complete, refactoring, debugging et al.
The more recent nrepl and cider modes for Clojure build on top of slime/swank and offer extremely great tools to write code as well. If you ever wanted to have the REPL running on the side and have great interop between code in a file and the REPL - these modes are great. Imagine their power when you can connect into a running webserver and debug on the fly from within your editor.
- A lot of original emacs plugins like paredit have now been ported to other platforms like Sublime. Also, emacs itself is written in lisp, which makes it a first class language it supports at its very core.
I really like the enhancement to C-x TAB to use the arrow keys to adjust the indentation on the selected region.
What's up with "address@hidden"?
Had you been on the mailing list and received this content via mail, the address would have ostensibly not been concealed.
It also populates all the information useful for devs.
The reporting address seems to be bug-gnu-emacs at gnu.org
Since I cannot say exactly how far lexical scoping would go in making Emacs Lisp more like Haskell in this regard, this is only a partial answer to your question, but certainly, the lack of lexical scope has something to do with it.
Aside from the deficiencies I just mentioned around higher-order functions, I was surprised by how little the lack of lexical scope got in my way. (My reading of the computer-science literature had given me the impression it would cause more trouble than it actually does.)
Getting back to actual question: Elisp supports "real" lexical scoping since previous major Emacs version, and it has had "lexical-let" and other such forms since forever, but most of the code is still dynamically scoped. In practical terms it's similar to having every variable declared as global - it allows for "out of band" communication (outside of arguments passed/value returned) between routines. This is sometimes handy if you want to change some function behaviour in a way that it didn't think of (ie. it has no argument dedicated for this). As a very contrived example, if you have a routine which beeps furiously every time you invoke it and you find it unbearable (I did) you can instead call it like this:
(letf
(((symbol-function 'beep) (lambda ())))
(beeping-function))
On the other hand, every out-of-band communication has a set of problems to it: you can forget to check it, or you can accidentally pass something to a called function you didn't want to. In practice this is worked around with using longer, prefixed identifiers and the semantics of `let`. As long as every variable your function uses is let-bound inside it it is essentially safe to call with any kind of environment, as it won't ever look at it. Most functions are like that.
In short, dynamic scoping has it's advantages and drawbacks, and it feels quite well suited to an extension/scripting language of an app. It makes certain patterns easy enough that they don't even need a name ("monkey patching"), and it makes others much harder (like the linked dash-functional library, which would be very hard to write without lexical-scoping: t).
It's nothing I find bad or not understandable. All errors stem directly from my lack of skill. (and the different key layout of most of my colleagues)
I hope some day an editor, written in Haskell, allowing to emulate Vi and and Emacs behaviour will become more appropriate for Haskell programming than any other editor and offer you to either the Vi or Emacs style.
Heh... what a perfectly beautiful little invitation to a flame-war. If it was about 5 years ago, I would have fallen for it in a minute ;-)
Then crontab -e will start emacs instead of vi.
export ALTERNATE_EDITOR=emacs EDITOR=emacsclient VISUAL=emacsclient
This way, crontab -e should open a new Emacs frame (or start Emacs, if it isn't already running). It will speed things up and make the experience better, while giving you access to all the things you're working on in an already running Emacs.
See also: http://www.emacswiki.org/EmacsClient.
I know enough vi to open a file, move up, down, left, and right, search, delete and insert text. And I often run afoul of my emacs muscle memory just doing that. But you really need to know the vi basics if you admin unix machines.
Of course I realize that this is mostly me being silly, but it’s also rather educational.
I have been on machines that fire up nano with crontab -e, in the name of user friendliness. These same machines will not respect EDITOR or VISUAL anyway, so I have no idea what to do about them. I usually just get up and creep away making sure not to turn my back on them.
I recommend those who are not familiar with conditions/restarts to read up a bit on them. This is something like exception handling, but an order of magnitude more powerful.
Almost. Restarts and value/retry on a stack frame are mostly unrelated - Restarts are only the UI for implementation specific features. Common Lisp provides no feature to retry an arbitrary stack frame. This is all implementation specific functionality provided by SOME implementations.
(require 'cl)
(setq lexical-binding nil)
(defun beeping-function ()
(save-excursion
(set-buffer "*Messages*")
(goto-char (point-max))
(scroll-up)))
(letf (((symbol-function 'beep) (lambda ())))
(beeping-function))
I think that the fact that scroll-up is built-in is pertinent: there was another incident in the recent past in which the function whose binding I wanted to override ("shadow"?) is called from a built-in function and in which my attempt to use cl-flet to override the binding failed.
If you have Emacs running on a Windows or Linux machine, I would like to know whether the above code causes a beep on that machine. I would like to know because in the past, code that gets a little tricky about bindings that worked on my friend's Windows box failed to work on my Mac (even with an up-to-date Emacs).
ADDED: Actually, let me show you the code that "worked" (i.e., behaved like someone familiar with Scheme or Haskell would expect modulo the trivial "rigamarole" of needing to use funcall) on my friend's Windows box but not on my Mac. The error is "(void-variable a)".
(funcall
(funcall
(lambda (a) (lambda (b) a))
1)
2)IIRC cl-flet was recently (well, in the current decade I think :)) modified to be lexically scoped, so that won't work (anymore). This is why I had to use `letf` with `(symbol-function 'symbol)` instead of a neater `(flet ((beep ())) ...)`.
Personally I deal with beeping like this:
(setq ring-bell-function (lambda ()))
On the other hand my Emacs (on Linux) refuses to beep in any circumstances even if I run it with `emacs -Q` and do M-: (beep) - I have no idea why, I suspect it's either my sound configuration or has to do with the way I built my emacs from source.
I'd say for this:
(funcall
(funcall
(lambda (a) (lambda (b) a))
1)
2)
Yes, it behaves differently (with lexical-binding set to t and with the -Q flag).
There's also the fact that all of these modes are a simple M-x-package-install <package-name> away and they just work. It's kind of like choosing OS X for me after using Linux as my main OS for years and years - I didn't have to worry about the wifi card not being detected or my dual screen display needing a lot of kernel modules : things just work :)