Posts Tagged ‘emacs’

“Multi-tty support” is a feature that is currently in Emacs CVS for what will eventually become Emacs 23. It lets different Emacs windows (“frames”) share the same session. This means that you’ll always have all your buffers, and Emacs starts faster. Emacs has had this “emacsclient” feature for a long time now, where you can edit new files in an Emacs instance that is running as “server”, but what is new is that you no longer have to hunt for where you had started Emacs first — you can simply edit in a new frame. For example, if you had originally started Emacs under X, and you log in remotely, you can reuse the running Emacs process by starting a new “frame” in the terminal. Instead of explaining better what it does, I’ll let you see for yourselves:

video by EnigmaCurry

Note that it is not necessary that all (or any) of them be in a terminal — you can have multiple GTK Emacs windows too. Also, note that every new window starts with the *scratch* buffer, not necessarily the same buffer as the one on top in other windows.

Installing:
Multi-tty Emacs used to be maintained separately (which is why older posts have complicated instructions), but it has been merged into the main Emacs CVS branch for a long time now. This means that it is available on Ubuntu by simply installing the emacs-snapshot package (this has been true since 2007-09-02). On other distributions/platforms, use whatever it takes to get Emacs from CVS.

Using:
To use it, start one Emacs session, and, if you don’t have (server-start) in your .emacs already, do M-x server-start. Once done, you can either leave this Emacs window hanging around, or hide it, or whatever.
Now to start subsequent Emacs instances, use emacsclient -c. The “-c” stands for “-­-create-frame”, and means that a new Emacs “frame” is started instead of using the old one. (Emacs calls windows frames and what it calls “windows” is closer to “frames” in a web browser.)
Use emacsclient -t if you want to start it in the terminal.
It appears that you can quit each individual instance the normal way with C-x C-c; it is not necessary to use C-x 5 0 (that’s delete-frame).

Automatically start an Emacs session at login and hide it, so that it runs like a “daemon” and you can simply use emacsclient -c consistently and forget about it. You can use screen -d -m emacs -nw, or use the more lightweight dtach: dtach -n /tmp/emacs emacs -nw

Do the above with some “name” for your emacs server. You can give your server a name by using (setq server-name "asdf") before (server-start), then you can can connect to it with emacsclient -s asdf -c (or -t). I don’t entirely see the utility of this; it might be so that you don’t start extra servers by mistake and always use the same one. There are scripts to do this.

You could probably combine all the above by writing a wrapper that checks if a server exists, connects to it if it does, else starts one, etc., and use that wrapper as your default system editor. That is what the wrapper script “ec” at EnigmaCurry does.

It would be nice if Emacs made this the default, though: Starting Emacs would by default work as multi-tty and share session with whatever previous Emacsen had been started, unless one explicitly told it not to do so.
Why not?

[The code you’re looking for is at the end of the post :)]
Following up on my previous post on auto-save…

GNU Emacs is one of the oldest programs existing, and it has had an auto-save-mode for god knows how many decades now, but it doesn’t quite do what I want. Like this other user, I was annoyed that it saves to a different file (/dir/filename is saved to /dir/#filename# while the file is being edited), and still requires you to save the file when you quit Emacs or close the buffer, thus making it not auto-save at all, but merely a backup facility guarding against Emacs crashes.

Someone at Emacswiki’s AutoSave page suggested M-x run-with-idle-timer RET SECONDS RET save-buffer RET, but I tried that for a while and it is really not a good idea; it tries to save every buffer, even those not associated with files, like completion buffers. I considered trying to figure out how to make it run on only buffers associated with files, but then I realised that it would probably be better to modify the built-in auto-save mechanism do what I want, instead of rolling my own new one, because that was smart about things like this.

C-h f auto-save-mode is actually quite sparse compared to the usual Emacs documentation. Anyway, I figured out with a bit of looking in the source files that I could edit make-auto-save-file-name function to modify what filename it used for auto-saves. On a bit more thought, I realised that it is usually never necessary to edit Emacs functions; you can always use hooks (or, in rare cases, advice). So this works: (add-hook 'auto-save-hook 'save-buffer). Yeah, it will still be saving the file in the #filename#, but it will be saving it to your file too. Actually I then realised I don’t need that either. Doing M-x apropos-variable RET auto-save RET gives several variables including:

auto-save-file-name-transforms
Variable: Transforms to apply to buffer file name before making auto-save file name.
auto-save-timeout
Variable: *Number of seconds idle time before auto-save.
auto-save-visited-file-name
Variable: Non-nil says auto-save a buffer in the file it is visiting, when practical.

and setting auto-save-visited-file-name to t seemed to do what I want. Until I actually tried to use it, and discovered that whoever added that feature probably hasn’t actually used it at all — it asks a “File has changed on buffer, really edit it? (y/n/r/h)” each time it auto-saves and you try to continue editing. You could turn on auto-revert-mode to make that problem go away, but I’m unsure if that’s a good idea: sometimes I overwrite files by mistake (gcc hello.c -o hello.c) and having Emacs not auto-revert is very helpful in those cases. So I’ll stick with my earlier idea, which works perfectly, after being fixed by Bryan Murdock:
(defun save-buffer-if-visiting-file (&optional args)
"Save the current buffer only if it is visiting a file"
(interactive)
(if (buffer-file-name)
(save-buffer args)))
(add-hook 'auto-save-hook 'save-buffer-if-visiting-file)

Emacsclient, essentially, says “use a running emacs”. With it, you can have only copy of Emacs running, and every time you need to edit something, you can call “emacsclient filename” to use the existing instance of Emacs without having to wait several seconds for a new one to start. To use it, simply put (server-start) in ~/.emacs, or type M-x server-start from within Emacs.

There are two (minor, irritating) problems with it, though:

When you are done with a file, you have to close it by hitting C-x #. Closing it normally (hitting C-x k, or exiting Emacs) brings up an annoying

Buffer `buffername' still has clients; kill it?

message. The rationale for this is in server.el:

;; Ask before killing a server buffer.
;; It was suggested to release its client instead,
;; but I think that is dangerous--the client would proceed
;; using whatever is on disk in that file. -- rms.

I don’t see what’s dangerous about that, but then again, I’m not RMS! …
One could put something like (global-set-key (kbd "C-x C-k") 'server-edit) to replace C-x # by an easier keystroke, but I found a better solution to be to remove the thing altogether, assuming that you’re going to be careful against whatever it is that is dangerous:

Remember to put this after the (server-start) line in .emacs (If you’re doing M-x server-start manually, you’ll have to call the above remove-hook manually too.) After doing this, you can simply save and close the buffer as usual (or even quit Emacs), and everything will work fine — you won’t get the annoying message any more.

The second problem is that when you call emacsclient from a shell, although the file gets loaded in Emacs, the Emacs window rarely pops up, at least on GNOME and KDE (and, on hearsay, OS X as well). It was suggested to put (add-hook 'server-switch-hook 'raise-frame) somewhere, but that doesn’t work either. (In KDE, it only flashes the Emacs window in the task bar, but that is better than nothing, as Ctrl-Alt-A is KDE’s shortcut for “Activate window demanding attention”.)
At least it appears that people arewere discussing it of late, in a gnu.emacs.help thread “raise frame no go”, and related discussions here, and also a GNOME bug here. These discussions are specific to Metacity (GNOME’s default WM), but it also doesn’t work on KDE and Cygwin.

Update: Emacsclient just got a lot more friendly. You no longer have to go find where the original emacs “server” was started — you can simply start up a new frame for your new buffer, wherever you want (all such Emacs “instances” share the same buffers). This makes the second problem above entirely irrelevant. (It seems to be an Emacs tradition to give up on fixing things that don’t work and implement something better instead :P) Read more about it.

(This
I just found something that’s amazing in its simplicity, and yet neatly solves a problem. Maybe you’ve sometimes wondered how to markup your email (perhaps in cases where you want the same text to be reusable) and yet retain its readability. (I have a friend who sometimes writes email in TEX markup, which is just incredibly wrong and annoying.) There is a solution that is as close to perfect as imaginable: Markdown. Its Basics page was itself written in Markdown. The syntax is perfectly readable; it is available on Ubuntu and Debian, and can even be generated from HTML, in case one wants to go in the other direction. It even has a Wikipedia article, and (even without looking!) I’m sure it’s the best “lightweight markup language” there is. There seems to be a markdown mode for Vim, but no “standard” mode for Emacsyet. (But with such good and readable syntax, who needs an Emacs mode, anyway?) There is a comparison here. There are converters from MarkDown to other formats (such as LaTeX), see Pandoc (written in Haskell!) and MultiMarkdown.

Another thing that looks impressive (and even more useful, because it is well-integrated into Emacs) is Emacs Muse, can be published to a lot of formats, including DocBook and LaTeX. Documentation here, and someone’s personal notes here.
I haven’t tried either of them yet.

[Update] Emacs Muse is nice, but it’s really not polished enough yet. (Either that, or if it’s not going to change then I don’t like it.) There are no nested lists yet. (It does now.) Markdown says

The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions. While Markdown’s syntax has been influenced by several existing text-to-HTML filters, the single biggest source of inspiration for Markdown’s syntax is the format of plain text email.

That doesn’t seem to be Emacs Muse’s “overriding design goal” to me (I need to figure out why I feel so, but somehow the syntax feels kludgy and seems to have many bad corner cases).
As I see it, the most powerful and compelling features of Emacs Muse are

The entire publishing system, where you can take a document and publish to multiple formats based on syntax translation rules, keeping a daily journal, etc. (planner-el depends on Emacs Muse for some of its functionality.)

Its integration with Emacs

Frankly, IMHO, the actual markup language is not one of its greatest features, and it would be great if they used — or allowed plugging in — other existing languages.