Hm, this doesn't mention support for lexical closures (not turned on by default, of course) which supposedly has been merged into the master branch. I sure hope this will make it into the release.
Ultimately, this feature isn't as important as everyone thinks it is. One thing that's great about Emacs is that it's easy to extend in ways that were not intended. When everyone starts doing Java-style enforced privacy, that's one less way to extend Emacs. The whole system becomes more rigid with no actual benefit. (When you are writing a server-side Java application, it's worth the increase in reliability to be able to know that your local variables are in a well-defined state; not knowing that leads to subtle and annoying bugs. But when you are writing a text editor that has a programmer sitting in front of it, interacting with it for every second that it is alive, this becomes significantly less important. As a thought experiment, I tried writing an Emacs extension as though it were a Java or CL program. It sucked.)
Ultimately, a closure is a (function . state) cons cell. Emacs doesn't need desperately need any new primitive to handle this; it's easy to pass in state to a function that needs it. So while I will certainly take advantage of closures when they become available, I'm not excited like a little kid waiting to open his Christmas. It's nice, but not Earth-shattering. And lexical variable binding comes with significant extensibility downsides when misused.
And lexical variable binding comes with significant extensibility downsides when misused.
It sure does. Consider the draconian module system in Node.js that wraps all your code inside a lambda sandwich, shutting it away completely, and then forcing you to petition for access to it on a case-by-case basis. (The justification for this apparently being nothing more sophisticated than "But encapsulation is good.")
This is the programming equivalent of bureaucracy stifling innovation. It is particularly disastrous for writing new tools, which of course is an area where Emacs shines.
If something is not easy to extend in ways that were not intended, it is not easy to extend.
Nothing is impossible in Emacs, but it did not ship with the function previously, yes. It also does not ship with a function for copying a line. It does, however, ship with a lisp which lets you do whatever the hell you want.
C-S-backspace is already bound to kill-whole-line.
But barring that, I don't think the point of using Emacs is to write shortcuts for nearly everything. That will effectively kill many benefits of Emacs.
Emacs has various verbs for moving around and learning those and combining them with other verbs will allow you to reuse the same patterns on various types of files and use-cases.
For example, without shortcuts, copying one line is C-a C-SPC C-n M-w but actually you just keep your finger on control all the time and it becomes C-(a SPC n) to select: I can do that pretty much instantaneously. Then I can choose whether to kill or copy: in the latter, I just add M-w and the former goes even faster: C-(a SPC n w).
But the benefit of doing the more complex way is that if you want to copy/kill the line above your current line, you just do C-(a SPC p w). Or if you want to kill a few words from the beginning of the line: C-a [M-d ...] or copy them: C-a [M-f ...] M-w. Or mark a few paragraphs, starting from the current one: M-{ [M-h ...] and you get the point.
If you had shortcut functions for various complete combinations then you'd actually have to step out of the flow whenever you don't have a readily available shortcut for something. And it's much faster to type a couple of "extra" characters because you can leverage the same operations into more complex combinations without consciously thinking about it.
I agree with you on many points, but there are a few things for which I prefer to have a dedicated shortcut. Specifically, basic functionality such as copying a line. More importantly, by your logic, we shouldn't have the C-k shortcut either. Wouldn't we be poorer for such a lack of divergence from bedrock abstraction?
I've started trying to switch over from vim to emacs, due to the fact that emacs seems better designed in general, with more - better extensions. I'd been wondering if there was some standard way of doing line deletion than the one I'd come up with. Apparently not.
Well, time to go back to viper-mode, with my old friends 'yy', 'dd', and 'kyy'.
Vim is better designed than Emacs for editing. Emacs is just better designed for everything else. To this day, there is no better way of scrolling text than j/k. That doesn't change the reality of Emacs' incredible flexibility.
C-v runs the command scroll-up.
It is bound to C-v, <kp-next>, <next>.
(scroll-up &optional ARG)
Scroll text of selected window upward ARG lines.
If ARG is omitted or nil, scroll upward by a near full screen.
So C-v scrolls by a screenful; M-1 C-v (which you could bind to a single key if you wish) scrolls by a single line.
But keep in mind that parsers are designed to parse well-formed documents, not to parse non-well-formed documents pretending that they are well-formed. When you are typing in code, you are often in an invalid state that a formal grammar would reject. Hence, syntax highlighters try to guess what a piece of text is in based on as little state (previous lines of the document) as possible. Yes, you lose absolute accuracy, but the heuristics get a lot right, run extremely quickly, and are tolerant of errors.
As an example, nobody has a formal grammar that will parse Perl 5, but cperl-mode highlights (and indents, etc.) almost everything you throw at it correctly. In fact, I can't think of anything that doesn't highlight correctly!
(Also, CEDET is in core now, and it has a library for writing parsers. Never seems to work for me, though.)
Theoretically some time around January, but that's what they said with 23, which was released in March. It's been in feature freeze since the beginning of July though.
