

A Peek at Emacs 24 - bozhidar
http://batsov.com/Emacs/2011/08/19/a-peek-at-emacs24.html

======
monopede
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.

~~~
jrockway
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.

~~~
gruseom
_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.

------
klausa
>New scrolling commands scroll-up-line and scroll-down-line scroll a line
instead of full screen.

Sorry, I never used Emacs, but are you trying to say that this was previously
impossible? Or is it just some new binding?

~~~
spiffworks
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.

~~~
omarqureshi
I've always gotten round the whole line copy thing with C-a C-k C-w, goto
where you want, C-w. It's become second nature :(

~~~
spiffworks
You should look in to one of the functions listed here:

<http://www.emacswiki.org/emacs/CopyingWholeLines>

Not having to use 3 keystrokes in the place of one is the whole point of using
Emacs.

~~~
yason
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.

~~~
Symmetry
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'.

~~~
spiffworks
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.

~~~
jbbourgoin
Yes, and Emacs can also emulate ... Vim.

=> VIPER mode.

------
drdaeman
Does GNU Emacs have standardized (out-of-the-box) parser generating
facilities, or every package still has to hack their own?

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

------
flocial
This still quite far away isn't it? I know there is a 24.50 and lots of
activity but the release cycle is pretty long.

------
basman
Anyone know the release schedule for this?

~~~
technomancy
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.

