What’s New In Emacs 24.4 | Hacker News Reader

What’s New In Emacs 24.4

masteringemacs.org

126 pointslispython51 comments

Something I've heard about is integrating Guile into Emacs. Will Guile become the primary language for Emacs with Emacs Lisp as an option, or will Emacs Lisp remain the "default" choice, with Guile for those who want it? And does anyone know what sort of timeline we're looking at before Guile support is released?

Current status seems to be summarized here.

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

Seems to be going quite slowly. However, I would think getting a good Scheme implementation as the Emacs default is probably the single most important feature. All Emacs is, after all, is a Lisp interpreter.

It's also one of the hardest features, since all Emacs is, after all, is a Lisp interpreter with a dialect that is incompatible with Scheme. :-)

Emacs users and developers would continue to write Elisp. The difference is that Elisp would be running on the Guile VM, which will improve performance and bring some features that are currently missing from Emacs (threads, and some other stuff that I can't remember).

Take this with a grain of salt, but I believe that Emacs Lisp will be implemented on top of Guile. More precisely, ELisp code will be compiled to Guile bytecode (which runs on a register VM[1]), which should make ELisp code run faster.

As a result, Guile and ELisp code will be able to play together.

[1]: http://wingolog.org/archives/2013/11/26/a-register-vm-for-gu...

This is indeed the case. Elisp will be another language running on the Guile VM.

The developers have sent out this survey with emacs 24.4 requesting that users provide some information about vanilla packages. This might also be of interest to people looking for fun extensions to play with.

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

I did a quick write-up of the top packages from the survey with brief descriptions of what they are and links to their respective Emacs Wiki pages:

http://adereth.github.io/blog/2013/12/08/most-frequently-ena...

    New hooks focus-in-hook, focus-out-hook.
    These are normal hooks run when an Emacs frame gains or 
    loses input focus.

Cool. I think the lack of such a hook is what was preventing an implementation of "save all buffers" when the user clicks outside the window, something commonly used in IDEs.

Prelude also adds hooks to save a buffer every time it loses focus. It also triggers when the point is placed by a mouse click.

Very useful!

Thank you for the news!

My personal favorite UI item: C-x TAB (indent-rigidly) now makes it faster/easier to multiple-indent, much like Sublime.

And for development: the Lisp debugger’s e command now includes the lexical environment.

I like how both emacs and vim continue to make improvements, while still maintaining a lot of the features that make them great.

This would be a lot more useful if the person writing the blog hadn't copied release notes in one character set into their blog entry in another character set. Tons and tons and tons of borked characters which make it very difficult to actually read what's going on.

He also did not escape angle brackets, so for instance “typing <left>, <right>, <S-left>, and <S-right> adjusts” from the original becomes “typing , , , and adjusts” in the text.

I've fixed this now.

I'm not seeing the character set issue at all. Both Wordpress and Emacs are set to UTF-8.

Here's an imgur album:

http://imgur.com/a/ehla9

Despite your comment saying you've fixed it, I'm still seeing this in Firefox, Chrome and Safari (OS X). No amount of fiddling with character sets client-side seems to fix it.

Lot of it seems to be punctuation and ligature characters getting borked. Some still seems to be escaping issues. Some I don't even know.

Sounds like a font or machine issue? I've never had any reports, ever, about this issue and my blog has been around for three years. I also tested it on my Android phone and it looks as fine as it ever does.

In SCreenshot #1 where the two odd chracters appear around "indent-rigidly" - those characters are normal parentheses. Here is what Emacs reports the opening character to be:

    position: 13888 of 66844 (21%), column: 37
    character: ( (displayed as () (codepoint 40, #o50, #x28)
    preferred charset: ascii (ASCII (ISO646 IRV))
    code point in charset: 0x28
    script: latin
    syntax: ()	which means: open, matches )
    category: .:Base, <:Not at eol, a:ASCII, l:Latin, r:Roman
    to input: type "C-x 8 RET HEX-CODEPOINT" or "C-x 8 RET NAME"
    buffer code: #x28
    file code: #x28 (encoded by coding system utf-8-unix)
    display: by this font (glyph code)
    xft:-microsoft-Consolas-normal-normal-normal-*-19-*-*-*-m-0-iso10646-1 (#x17F)
    Character code properties: customize what to show
    name: LEFT PARENTHESIS
    old-name: OPENING PARENTHESIS
    general-category: Ps (Punctuation, Open)
    decomposition: (40) ('(')
    There is an overlay here:
    From 13888 to 13889
    face                 show-paren-match
    priority             1000

Very odd. Seems like I might have a corrupt italic Constantia. Disabling the italic variants (forcing fake-italic rendering) immediately fixed this.

Strange indeed. Mystery solved though. Thanks for the screenshots - they helped debug it!

Oh, and what I fixed were the missing angle brackets.

ProTip: the iconv utility (part of flinch, so yes, it's installed on Linux / Mac) is quite helpful for fixing this.

Fixing linewrap issues would also be useful.

> Great news for beginners of Emacs who mistakenly use Emacs in a terminal instead of in a window manager.

I use emacs on purpose in the terminal. Is he being sarcastic here?

Ditto. Can't stand the UI.

It's just a basic menubar for new users; two lines in .emacs and it won't bother you again:

    (menu-bar-mode 0)
    (tool-bar-mode 0)
    (scroll-bar-mode 0) ; also possibly annoying

It's not so much the menubar--I've disabled that--but that I spend most of my time in ssh sessions, and I tend to re-launch emacs all of the time, to the extent that the start-up time of the GUI version bothers me.

So launch it in tmux, and reconnect the next time you jump to that server. If you want faster start time you can also start emacs, run start-server, and then use emacsclient everywhere else to quickly open files from the commandline. In general though, opening and closing emacs all time is the wrong workflow to use with emacs.

Note however you can't use emacs-server/emacsclient with the GUI over a SSH connection and tmux. With remote sessions and emacs you really have to choose between long start-up times and terminal-only editing.

Exactly.

I'm probably misunderstanding you, but that is exactly what I'm doing. I have an emacs-server running on a remote server to which I connect via SSH to a tmux session and from there start an emacsclient gui via SSH X forwarding (you might have to set DISPLAY). Works like a charm.

I think parent was saying that you can't run a single daemon on machine emacs-host and launch clients from needs-editing-a-conf-server1...n (possibly with x11 only running on different host workstation1)?

You seem to be running n daemons on needs-editing-a-conf-server1..n and launching n clients on each of these, and "just" transporting the display(s) back to your workstation via x11 forwarding over ssh.

Henche - either run "redundant" daemons or suffer long-ish startup times.

How much resources does your typical long-running daemon consume?

How about this approach? http://blog.habnab.it/blog/2013/06/25/emacsclient-and-tramp/

He's using tramp to copy an auth key to the remote system, but then using that to allow the remote emacsclient to talk back to the host. Has some caveats, but it's essentially the single daemon, many remote clients approach?

Are you sure you can't? Pretty sure I have used a remotely started emacs --daemon and used emacsclient -c with DISPLAY set correctly and X forwarding to bring a GUI frame locally, and then use emacsclient on that machine to pop open files from the remote command line to the existing, local gui frame. If you lose your connection the gui client might kill your daemon (at least with gtk) though.

Or do your editing from ansi-term or eshell from within the long startup gui you have running on the remote system. Eshell find-file will pop to that buffer from the commandline.

It is unfortunate that tramp often feels too slow for these tasks, as that would seem like another logical approach. Maybe it's faster without ido and friends doing lots of completion requests?

> In general though, opening and closing emacs all time is the wrong workflow to use with emacs.

Depends what you are doing. When I'm remote I almost always have an "emacs --daemon" running. Remote admining a custom server ends up with me editing random .conf files in multiple tmux windows. Emacsclient is heaven sent in that case—it pops up faster than vim, with all context already there.

For coding, I tend to run a GUI locally and just have a bunch of buffers open. I still do server-start/emacsclient so the occasional random git command that spawns an editor just pops open a new frame instead of launching a whole new Emacs process...

You could use `emacs --daemon` and `emacsclient -c` if you don't really need to fully relaunch Emacs constantly (you shouldn't).

I like GUI Emacs because you get more colors. 256 isn't enough for beautiful, subtle shades.

He specified "beginners", where I think a GUI makes sense. I know I found it somewhat helpful.

I interpreted it as beginners who mistakenly use Emacs in a terminal, possibly not knowing that there's a GUI mode as well. I don't think he means that running Emacs in a terminal is a mistake in itself.

But who knows...

I suspect you're right. It's not hard to find numerous stack overflow questions clearly posed by people trying to learn emacs, who've mistakenly run the terminal version - and who now, as they say, have two problems.

But even for more experienced emacs users I'd argue that the terminal version probably is a mistake. Think of it as akin to eating out-of-date food: even if the only other option is starvation, it still probably won't taste very nice, and it could even make you ill.

About all you can say about terminal emacs it is that (unlike vim) it does at least use the familiar emacs keys... provided you can remember that the meta key probably doesn't work. Along with some (random) set of key chords that involve shift. Sometimes by playing with your terminal program's options you can change which half of the keyboard shortcuts are broken.

Still, I'm sure some people like it, and they shouldn't listen to me. It takes all sorts.

I frequently use emacs when SSHed into remote servers where terminal mode is the only option. When I run it locally I still prefer terminal mode out of familiarity, I guess. Also, I'm usually working on shell scripts or the like. And I like being able to drop to a bash prompt with a keystroke (ctrl-Z).

Emacs can do all this and so much more; it can be a far more inclusive and flexible "screen" replacement.

I will have to write an article explaining why I feel using Emacs to handle all that is "the more Emacsy way."

Fixing meta is easy, if for some reason it's broken, and it has the nice effect of also allowing you to use it for shortcuts in Bash and other readline enabled programs, not just in emacs. For best compatibility have your terminal output +Esc on Option/Alt.

The only other problem I had in terminal was getting combinations involving arrow keys to come across properly, but even that was a relatively easy fix.

So glad electric-indent-mode is enabled by default. That was the only thing I absolutely needed to make a .emacs config for when using a foreign computer for a little while.

Interesting to see how good multi-monitor support is. Good changes, anyway.

I disabled electric-indent-mode, because it really doesn't get along well with org-mode in my experience. I only really use it for select languages, but otherwise tend to disable it globally.

My hope -- and I have yet to try it in anger in 24.4 -- is that these annoying issues are fixed.

> Interesting to see how good multi-monitor support is.

I used Emacs for 13 years on VMS workstations, all of which used separate X displays for each monitor. Multiple-X-display support was added to Emacs in version 19.3x, but Emacs on VMS [1] was stuck on an older version (19.28?) for a very long time. So I longed for, but lacked, any multi-monitor use with Emacs for a long time. I take it for granted today.

[1] That Emacs was available on VMS at all was due to the efforts of Richard Levitte--one of the unsung heros of FLOSS in my mind. The system interface stuff worked quite well on VMS.

The title needs changing to future tense because it implies 24.4 has been released.

> yow.el is obsolete; use fortune.el or cookie1.el instead.

I guess everyone older than I am has died off.

emacs is awsome

it is

Reply on news.ycombinator.com