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?
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.
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.
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.
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.
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.
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
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.
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).
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.
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.
> 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...
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.
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?
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?
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?
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.
> 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.
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.
