GNU Emacs 23.2 released | Hacker News Reader

GNU Emacs 23.2 released

permalink.gmane.org

133 pointsboskom86 comments

Open articleView on HN

The NEWS file http://www.gnu.org/software/emacs/NEWS.23.2 is more helpful.

* CEDET http://cedet.sourceforge.net/ is now part of emacs(!!!)

* RMAIL now uses mbox

js.el is a new major mode for JavaScript files.

I think js2.el (Steve Yegge) was combined with javascript.el to make a new mode. Might be interesting...

has anyone got more information about this? I recently started using js2mode, its awesome but has way too many bugs.

No, it's espresso, not js2. But don't worry, that was the only sane Javascript mode; js2 is like its own program, completely independent of Emacs. Cool, but useless for real work.

espresso/js actually works like Emacs, and it doesn't try to treat Javascript as a dialect of C anymore.

Useless for real work? I never saw negative comments from js2 users...

I remember it was similar to nXML in having its own parser... do you think nXML is badly engineered or useless too ?

I wrote a mode inspired by your Stylish for Lua one day. I wish there were more editors that would let you do that kind of thing...

I love js2-mode and only use espresso-mode for JSON. Do you know of any comparison of the two modes I could read to get more info on this?

> * RMAIL now uses mbox

Wow. Never thought I'd see that happen. Been wanting that for 20 years.

Mac OS X users can get a binary at http://emacsformacosx.com/.

I had been using http://aquamacs.org/, I'm going to have to weigh up whether to switch for these features.

Crashes here (on 10.5) with:

Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000002, 0x0000000000000000 Crashed Thread: 0

Dyld Error Message: unknown required load command 0x80000022

I guess it is for 10.6 only?

I wrote him a mail. It was not by purpose. He will check that later.

Heh, I also did digging and sent him a mail. Looks like a missing linker flag.

Thanks, both of you. :-) The version up there now works with 10.5, according to holygoat (thanks to the magic "-mmacosx-version-min=10.5" compiler flag).

Cool thanks, works fine! :)

Also good to know about that compiler flag. :)

Wow. I was using CarbonEmacs 22.3 till now, so I'm not sure if it's the switch from CarbonEmacs or just v23, but startup is about 1-2 seconds now instead of 5-10 (2ghz Core Duo "Yonah"). Either way, I'm sold!

Thanks for that link. I spent some time late last night comparing this new pure Emacs release with Aquamacs. I have been a happy Aquamacs user for a long time but I will probably switch because of the faster startup times and cleaner looking interface. When Aquamacs is released with an update, I would like easier options for simplifying the look and feel (e.g., having to hide the button bar, etc.)

BTW, really off topic, but does anyone know how to bind the speedbar to the main frame window instead of being in a separate frame window?

As a tip, if you enjoy quick startup times, you might want to try running emacs in daemon mode. Just fire up a emacs --daemon instance, and you can then use emacsclient to instantly connect to it.

You can also put (server-start) in your .emacs config.

Answered my own question: found what I needed here to have the speedbar in the main window frame. Nice: http://www.emacswiki.org/emacs-en/SpeedBar

The maximum size of buffers (and the largest fixnum) is doubled. On typical 32bit systems, buffers can now be up to 512MB.

This limited buffer space has long been a criticism of mine and an often-used point I make when I choose to play the Holy War game between vim and emacs. 512MB is still a weak and arbitrary limitation (vim just uses up your memory), but this is much better than it was.

Can you give me a situation where you would need more space ?

- Viewing/modifying a fasta file containing human chromosome data

- Extremely large log files

Why not use less? Because it's ugly and does not allow me to edit or copy specific sections out. I like having the full power of a good text editor at my back.

I have brought this concern up before, and the excuse I heard was, "Well, you should not have to work with files that large." Seems someone in emacs-land disagrees; now you can play with files up to 512 MB on a 32-bit system! If there is a legitimate use case for, oh, 500 MB, we can imagine a use case for 2 GB. The world is moving on; we aren't playing with 64 KB systems any more, and data keeps growing.

In 2010, our text editors still have hardcoded memory limits? (I understand emacs's architectural reasoning for it -- and that is a choice.) IIRC, DOS 6.2's Edit could handle large files; it accomplished this with a partial-loading/paging trick, rather than actually loading the entire file in memory.

So yes, I would like to and have enjoyed opening files of large size. Admittedly, I have to wait a bit for the I/O to catch up! :) I also have to be conscious of my memory usage, since I am unaware of any paging mode in vim (or emacs). I expect, on average, to have the option to open a file of at least 3 GB size -- and that is without taking advantage of swap. Next year, I expect more.

I know it is not a common desire, so I do not blame anyone for imposing an arbitrary limit other than to say "nyah nyah; I am free".

> I understand emacs's architectural reasoning for it -- and that is a choice.

I think the choice they make is to spend their very limited time on more useful features. I'm sure many of the core Emacs developers would be very happy if someone would fix this limitation. It would be a very invasive change, a fair amount of work.

Any change on 32-bit machines will require special CPU instructions, massive Lisp slowdowns, or massive integer math slowdowns.

Considering you can't even buy a new 32-bit machine anymore, however, I don't really see this as a major problem.

>Considering you can't even buy a new 32-bit machine anymore, however

Netbooks.

Most netbooks that have come out in the past 6 month have a 64-bit CPU. Only the old atom N2xx series is 32bit, and they are rapidly being phased out.

The "hardcoded memory limit" you see is Emacs stealing three bit of a 32 bit word as type tags for its dynamic type system.

It might be time for Emacs to switch to 64 bit words internally, should give plenty of bits left for buffer addresses after taking a few bits of for type tags.

The memory overhead when editing small files would be larger, but I haven't really heard people complain about Emacs' memory footprint lately.

I don't understand what you mean by "Viewing Large Files" - Is it the case the Emacs doesn't gracefully handle viewing greater than 512 MB Text Files? That isn't a particularly large log file (In Debug Mode, our Java APP gets there in about three-four hours), and we routinely work with files of 2 Gigabytes in size without considering them "large".

Having once managed to delete a file with hours of edits just before committing to version control, I opened my 60 GB partition in vim, found the text of the file and copied it out. While this is "stupid" — there will be better ways to do it — searching and recovering with vim worked immediately and easily.

Edit: it's possible I used "less", I can't remember.

Hehe, cool trick, I'll have to try it out someday :)

Can you explain in just a bit more detail how you did this? This sounds really neat. I faced a problem like this a while ago, but luckily the file was still open in emacs (and in an emacs buffer), so I just re-wrote it back to disk.

This was a linux laptop. I immediately powered off and booted with a live CD. To be honest I'm not sure exactly what I did next. I might have just done "less -f /dev/sda5". I think what I actually did was make an image of the partition using dd to an external drive so I would be able to recover the file at leisure. Trying now, it seems that vim won't open a /dev block device directly, but an image is just a regular file.

It's not arbitrary. It's simply the largest int pointer your emacs can represent. It's also a non-problem on 64-bit machines. Run the following code in your emacs buffer:

(let ((i 1024)) (while (> i 0) (setq i (* i 2))) (1- i))

The number it returns is your max file size. Mine is 1152921504606846975 bytes.

Great summary of clipboard and mouse related features here: http://www.reddit.com/r/programming/comments/c1gsi/emacs_232...

From NEWS.23.2: "The pointer now becomes invisible when typing.Customize `make-pointer-invisible' to disable this feature."

You might also like mouse-avoidance-mode. I've got it set to 'exile.

Can someone very briefly explain the popularity of emacs and vim among programmer types? I'm aware that they're unix based text-editors with some degree of reprogrammability... but what's the big deal?

Don't... even... start. ;)

The gist is that these editors are both customizable to the extent that proficient users don't see the need to go elsewhere. They're both keyboard driven, so one finds their productivity soaring as their dependency on the mouse decreases. They're text oriented, so moving around and manipulating text is much more natural and speedy than other modern editors.

In short, give either a shot. You might find it does everything and more that your current editor does. Neither be 100% comfortable to you over night, but in time you'll wonder why you worked with anything else.

Both? There is only one.

It's a fair question. Emacs is one of few editors left that makes it possible to work on multiple files at once without taking your hands off the keyboard. No fumbling with the mouse. Watch someone who has mastered Emacs edit some code and you'll understand its appeal.

Going a little further, Emacs is itself (at least a lot of it, including js-mode, for instance) written in Emacs Lisp. This makes most of it modifiable by its user. It's not impossibly hard either - I have made a minor mode for Pyccuracy tests in a couple hours. Learned some in the process.

Even the "configuration files" are, really, Lisp code, not bags of values and options.

Just to add to the language-configuration thing on the vim side...

Vim configuration is also not a bag of options and values; by default, it uses vimscript. vimscript is an interesting language (supports a form of OOP) but only really usable in the vim world, so it is up to you if you want to learn it to do things besides assign values to options.

Alternatively, vim allows you to do editor customization in perl, and while I have found very little documentation for it, it also supports mzscheme.

How does this kind of thing help anyone? Why is Notepad just not good enough? You can add entire text-manipulation features to your editor, including Intellisense to your specifications, tools for refactoring, integration with other tools outside the editor, and so forth.

Both editors have large communities and have few real competitors for fast and powerful text editing (I hear TextMate comes close).

I just checked the breakdown with sloccount.

C: 20% ELisp: 78%

What's the last 2%?

Python? http://pymacs.progiciels-bpi.ca/pymacs.html

"magic"... ;-)

The parts that are written in C are mainly the lisp interpreter itself, and some windowing stuff. Unless you are doing something really strange you never need to dive into the C internals.

I'm too tired to think of just the right witty comment, but no one ever truly masters emacs; there's simply too much to learn. Which is what makes it so fun - it's a continuous learning process, where there's always something new and cool to be dug up.

Hmm, I'm still not quite sure I 'get it.' For instance, your comment, 'no fumbling with the mouse' confuses me. I've always viewed the mouse as something that saves time, a shortcut to where you want to go or what you want to do. Especially on a Mac with non-maximized windows and Exposé mapped to a mouse button, I've never felt like I was 'fumbling.' I guess I'll ask an Emacs user to demonstrate next time I meet one.

There are operations where the mouse is more efficient than the keyboard and vice versa. Anyone who says otherwise is selling something.

That said, I often trade the time + context switch of moving to the mouse for a slightly less-efficient keyboard command. Overall it's probably a toss-up, I just like to stay near the home row.

My friend at work uses the mouse a lot and he's very good at using it to edit text.

Agreed. IDE with extensive keyboard shortcuts + using the mouse occasionally for the odd-length text jump/highlight VS emacs baroque command structure is probably about the same for those who have mastered each. Years of surfing the web have most people very adept and quick with a mouse.

Exposé breaks down when you have a hundred buffers open, though. iswitchb cuts through that like a bullet through butter.

The mouse is better for some things (especially relative/spatial stuff), and the keyboard for others, but interfaces that make you switch back and forth are clearly problematic. Rather than popping up dialog boxes and alerts, Emacs displays results (such as compiler output) in another buffer. If it needs immediate input, it uses the minibuffer, a one-line buffer at the bottom of the screen.

In either case, its full text-editing functionality is available. You can run a directory browser/editor, a web browser, shell, interpreter, e-mail client, irc client, etc., and it's just another text window.

FWIW, Marco Baringer's SLIME screencast ( http://common-lisp.net/project/movies/movies/slime.mov ) is a pretty good example of proficient Emacs usage. That convinced me to try Emacs after using vi for several years.

Thanks for the slime.mov link, I learned a couple of nice things about Emacs UI from that.

Ok after watching that link and reading these comments i'm starting to understand a little. I installed Aquamacs (other emacs clients were too ugly IMO). I can see that emacs perhaps had a lot of features Visual Studio had BEFORE vs, and that it's a stable, multi-platform, multi-language environment. I can see also that some of the text editing/formatting functions would probably work better than what I currently use Excel for. I can see the attraction of an uncluttered dashboard/interface too. And extensibility. But as a beginner I can't yet relate to this 'context-switching' problem and the appeal of running all sorts of applications inside a text editor.

No problem. I'm not trying to convince you one way or the other (heck, I use vi too), but I figured a video might help.

Also, for you or anyone else reading this thread, http://emacswiki.org/ is the place to go for info.

Huh? I can edit multiple files in Windows Notepad by pressing Alt+Tab. There are some nice features in Emacs but any editor allows working on multiple files without a mouse.

That is technically true, but no one would actually be productive in that environment. Switching to the file you want is an O(n) operation with that workflow. That would drive anyone insane. In proper editors you can switch to the file you want by hitting a command and then typing a few chars of the file you want, then return.

Nonsense. I've done it both ways, and doing it the way you describe is actually slower.

Perhaps that says more about the person than the method.

It's slower for small N. That's why emacs has Tabbar mode, which I have bound to \C-Tab.

http://www.emacswiki.org/emacs/TabBarMode

Tabbar works great for switching between the 3 haskell files I have open (note: tabbar only switches between files of the same type).

Regular buffer switching (or even better, anything mode http://www.emacswiki.org/emacs/Anything) works great for switching between the roughly 200 java files I have open right now.

You can bring up Emacs' buffer list sorted with the most recently used at the top (bs-show). This is equivalent to alt-tab in the worst case. Because I can search this list (it's a standard Emacs buffer), I can get to anywhere in the end or middle far faster. You cannot see filenames in alt-tab until you select the icon.

Further, Emacs standard switch-to-buffer command selects the last visited file by default so you can flip between files with C-x b RET. Slightly longer than alt-tab, but not much once it becomes muscle memory.

A previous post from HN summarizes some of this:

http://news.ycombinator.com/item?id=403967

So, Emacs can be any or all of 4 things depending on your point of view.

1) lisp interpreter

2) text editor library written in lisp

3) a very flexible text editor

4) whatever you want to make it

Because it's a general purpose programming language you can write anything you want in Emacs lisp. That's why you find tetris, web browsers, and e-mail clients written for Emacs. There's a great culture of sharing your work too[1], so Emacs can be a powerful toolkit that supersedes traditional shells in some ways.

You have unlimited access to customize your editing experience. Everything the editor does can be changed because you have the same access to the interpreter & libs as the editor itself. Every key can be bound to a function, and the normal alphanum chars and such are bound to insert themselves by default, but you can change that. So if you want { to insert the closing } automatically, you can do that without much trouble. You can write it, evaluate the code, and then use it instantly without restarting your editor.

Personally I just use it for coding, but for me coding includes running zsh and a host of other REPLs. (ruby, python, javascript, ...) Some of the packages I have used approach or exceed IDE levels of integration with the project being worked on[2][3].

You can compile a C program or run grep and then step through errors/warnings or search results visiting each line and doing what you need to do. This is one way that Emacs one-ups the shell which prints static text as output. Emacs wraps that in an interactive interface, which is great in a lot of situations.

[1] http://www.emacswiki.org/

[2] http://rubyforge.org/projects/emacs-rails/

[3] http://github.com/samsonjs/mojo.el

edit: One really cool thing I forgot to mention: js2-mode. Steve Yegge wrote a JavaScript parser in Emacs lisp which means that when editing JavaScript - which I do a lot of these days - the syntax highlighter has an immense amount of information to work with. Global vars are coloured differently from local vars (very important in JS as undeclared vars are implicitly global, ugh). Syntax errors get underlined in red instantly. If you've experienced this in other IDEs you appreciate how awesome this is. You never run your code only to find that you made a stupid syntax error that needs fixing. Someone could use js2-mode to write advanced IDE-like functionality for JS, such as renaming & refactoring.

Anyone could implement something similar for any other language, if they have the time & will.

Their popularity comes from a few places:

1) Both vim and Emacs are really really good at basic text manipulation. This means for navigating files and entering/changing text, they're really quick (and don't require a mouse). Most other editors and IDEs are really bad at this.

2) They're amazingly customizable, which means whatever you want your editor to do, they can do.

3) People love messing around with them. I've been there, and I can tell you it's really fun. Finding all the amazing little things Emacs/vim know how to do, finding that extra few lines of code to make that make them do some neat trick, it's all very fun for people who love tinkering with their tools.

Disclaimer: I am not an active Emacs/vim user. But I have used both for long periods, and I respect the amazing things they can do and teach.

One nice point about vi(m) especially is the fact that its available almost everywhere as most unixy installations got one.

And a nice point of text-based programs generally is that they are easy to use over ssh allowing you to access your programming environment everywhere.

Here's a dumb question: most *nixes come with vi as the text editor, but the shell uses emacs keybindings. Why is that?

(btw, if you learn emacs well enough, you're commandline-fu goes through the roof)

Actually the keybindings can be changed to those of vim (by typing "set -o vi" on terminal). It is probably not set as default as it is confusing to new users.

"the shell" usually means (on modern Linux distros) bash, which is the "GNU Bourne-Again SHell".[0]

Brian Fox[1] developed the readline library to handle bash's interactive input. Between Brian Fox having been an Emacs maintainer, and bash being a GNU project, the keybindings followed suit...

Had bash been "Bill Joy's[2] Awesome SHell," things might have gone differently :-) Well, it would've just been csh[3] (written by Bill Joy.)

[0] I address this introduction to anyone not already "in the know."

[1] http://en.wikipedia.org/wiki/Brian_Fox

[2] http://en.wikipedia.org/wiki/Bill_Joy

[3] http://en.wikipedia.org/wiki/C_shell

Nice to see that CEDET is now included.

I can't seem to get it to work, though. The information on the CEDET website for setting things up doesn't seem to be valid anymore.

Specifically:

  (global-ede-mode 1)                 ; Enable the Project management system
  (semantic-load-enable-code-helpers) ; Enable prototype help and smart completion 
  (global-srecode-minor-mode 1)       ; Enable template insertion menu

Throwing in (require 'cedet) doesn't seem to work either.

I'm having the same problem. I searched the code for "semantic-load-enable-code-helpers" and it isn't in any of the .el files in any of the directories under "lisp". Would be nice to try this out, but I'm too busy to get this going today (I'd love it if someone else solves this tho :-)

Semantic's now turned on with (semantic-mode 1). See the Semantic manual included in Emacs for details.

Do they have a C# mode yet, or is that still p[r]etty impossible to do?

http://www.emacswiki.org/emacs/CSharpMode

I may not have the latest version, but I find that sometimes this mode has issues with syntax highlighting, especially around comments.

Not a deal breaker for me, though.

They are still using MD5 checksums?

What should they be doing?

They are using digital signatures(Chong Yidong's). The following files are both available from the same places as the tarballs:

emacs-23.2.tar.gz.sig emacs-23.2.tar.bz2.sig

Reply on news.ycombinator.com