Planet Emacsen

By far the oldest board in this series. Production of these things started in 1985 and slightly modified versions are still being build by Unicomp (the Customizers are the closest to the standard IBM Model M, but always make sure you pick the Buckling Spring versions, see below).

Build quality

I've been using a Model M keyboard for the last couple of years, and in many respects it's the best keyboard I've ever used: it's very sturdy, will last for decades (mine is 15 years old and still working fine) and the key switches are phenomenal.

Layout

This was one of the first keyboards with what's now more or less the standard PC layout and it's probably the reason that that layout became so popular. Probably not remarkable - even boring - these days, but on the whole it's very well thought out and effective. Especially if you map the CAPS Lock key to Control (Unicomp sells models with CAPS and Left-CTRL swapped, but you can swap the keys on any OS and I don't really see the point of looking at a keyboard when you're typing on it).

Buckling Spring switch technology

The switches work via a so called "buckling spring" mechanism, which means every key is set on top of a fairly long spring that "collapses" sideways when you've pressed the key about half way down and activates the mechanical "hammer" attached to the bottom of the spring. You can easily feel when that is about to happen, and once it does you can feel the key "give" and it makes a very satisfying CLICK sound.

On this keyboard you simply can't get fooled about whether you've pressed a key or not: the auditory and tactile feedback is very immediate.

Issues

As you can probably tell, I really like this keyboard, but there a few issues with it that are annoying:

Size

This is a large keyboard, even for a full size standard layout: the MS Natural 4000 has a big wrist rest and a "split" main cluster and it's still only marginally larger than the Model M.

Size is especially important if you're a right handed mouse user. With the num-pad to the right, your mouse is quite a long way away from the main alphanumeric cluster where your hands are when you're typing, which means that you're not always using an optimal position for the mouse, the keyboard or both. You can tell these things were invented before PCs had mice.

There used to be Model M variants that didn't have a numeric key pad, but production of those stopped somewhere in the early '90s. Expect them to be expensive - if you can find one. Ebay US seems to have a few, but once you include shipping, you might want to consider something else if you live in Europe. Clickykeyboards (where that link is to) sells them for fairly reasonable prices, but they don't seem to have them all that often - and you still have to pay shipping from the US.

Finger fatigue

The switches on these keyboards are very good, but also quite heavy: they require noticeably more force than most conventional keyboards. You get used to it, especially since the force is consistent over all keys, but for me, it's just barely on the edge of "too heavy".

Sound

The click sound, while satisfying, can get on your nerves late at night. Not that much of an issue for me, but sometimes you just wish it made a bit less noise. If you have coworkers or family in the same room, I expect they won't like this keyboard much.

Pro: price

On the other hand, second hand full-size Model Ms are cheap and not that hard to get. New ones from Unicomp are also very competitively priced compared to other well-built keyboards with mechanical switches (the basic model is $69), even if you have to ship them across the Atlantic.

Previous episode: In search of a better keyboard - Early history.

Next episode: what now? (not finished, stay tuned).

-1:-- In search of a better keyboard; The IBM Model M (Post Joost)--L0--C0--September 01, 2010 08:55 PM

Yes, that's another el-get related entry. It seems to take a lot of my attention these days. After having setup the git repository so that you can update el-get from within itself (so that it's self-contained), the next logical step is providing recipes.

By that I mean that el-get-sources entries will certainly look a lot alike between a user and another. Let's take the el-get entry itself:

(:name el-get
       :type git
       :url "git://github.com/dimitri/el-get.git"
       :features "el-get")

I guess all el-get users will have just the same 4 lines in their el-get-sources. So let's call that a recipe, and have el-get look for yours into the el-get-recipe-path directories. A recipe is found looking in those directories in order, and must be named package.el. Now, el-get already contains a handful of them, as you can see:

ELISP> (directory-files "~/dev/emacs/el-get/recipes/" nil "[^.]$")
("auctex.el" "bbdb.el" "cssh.el" "el-get.el" "emms.el" "erc-track-score.el"
 "escreen.el" "google-maps.el" "haskell-mode.el" "hl-sexp.el" "magit.el"
 "muse-blog.el" "nxhtml.el" "psvn.el" "rainbow-mode.el" "rcirc-groups.el"
 "vkill.el" "xcscope.el" "xml-rpc-el.el" "yasnippet.el")

Please note that you can have your own local recipes by adding directories to el-get-recipe-path. So now your minimalistic el-get-sources list will look like '(el-get cssh screen), say. And if you want to override a recipe, for instance to use the default one but still have a personal :after function containing your own setup, then simply have your el-get-source entry a partial entry. Missing :type and el-get will merge your local overrides atop the default one.

Finally, the way to share your recipes is by sending me an email with the file, or to do the same over the github interface, I guess I'll still receive a mail then.

-1:-- Want to share your recipes? (Post Dimitri Fontaine)--L0--C0--August 31, 2010 02:15 PM

-1:-- Another August Build of Emacs 24 available (Post sivaram (noreply@blogger.com))--L0--C0--August 31, 2010 02:23 AM

I've been thinking a lot about ZZ Top recently. This isn't something I generally do as a rule, but it was prompted by re-reading a blog post by the inimitable Giles Bowkett ostensibly about the song I'm Bad; I'm Nationwide. Go ahead and cue that up in the background while you read this post; it's vaguely relevant.

"Bad" in this sense of course is the good kind of bad, like the Michael Jackson song. It seems to be mostly about attitude. Giles makes the point that generally being bad is not correlated with being nationwide.

"I'm Bad, I'm Nationwide" is a ZZ Top song. Hopefully you can figure out what it's about, but just in case, the singer's point is that he is bad, and he is nationwide. [...]

It's good to be bad. It's good to be nationwide. It's even better to be worldwide. How can we apply the lessons of ZZ Top in the workplace?

Obviously if you walk into your boss' office, jump on his or her desk, pull down your pants, and perform toilet functions all over the place, that would be bad. But it would not be nationwide, and it would not encourage becoming nationwide. In fact, it would not really be bad, it would just be stupid. But this silly example highlights a deeper paradox: that which is bad is usually local, and that which is nationwide is usually good.

Giles goes on to talk about how the bad/nationwide balancing act applies to a career in software development, which is interesting, but I've been thinking about it in terms of projects instead. Take the familiar realm of editors. There are a few of them that are nationwide just by virtue of having survived and built up a following over the course of several decades. And they're also often bad when flame wars erupt over them, as is fairly common.

So Emacs and vi have somehow achieved the intersection of bad and nationwide, which as Giles posits is tricky to pull off. Simply being bad doesn't work in the long-term, and while quiet competence sometimes does, it's worth noting that in many cases attention helps a project improve in concrete ways—especially projects whose users are developers. This is pretty key for things like languages, libraries, and build tools.

The problem I'm faced with here is that being bad is also often correlated with being inflammatory. The easiest way to get attention in the software world is to pick a fight. You see this all the time on sites like Reddit; when people smell blood they upvote, which is why stuff like Aleph vs Node.js: the smackdown makes it to the front page despite being a superficial comparison.

The thing you have to remember about picking fights with another project or language just for the sake of it is that often the attention fallout is more evenly distributed than is intended. When someone goes out of their way to pick a fight, they usually aren't much good at hiding the fact that they've got an investment in one side. Impartial readers can usually pick up on this pretty easily, and they're likely to spot holes in the argument or write it off it as a piece of cheerleading. In cases of particularly unfair partisanship, they may even begin to sympathize with the target under attack.

The closest I've come to this sort of bad/nationwide is this post I made on Twitter a few months back:

Q: What's the difference between Ant and Maven? A: The creator of Ant has apologized.

This turned out to be just the right mix of nasty and clever to really take off; hundreds and hundreds of people passed it on, and over the next few days searches for my name came up with just pages and pages of this over and over again. At the time of this writing it's still on the second page of results in a search for my name.

I've got to admit, as the author of a build system that competes with Maven, this felt kind of good. The problem is it's totally a cheap shot—everyone involved with build tools ends up in a position of needing to apologize to their users given enough time. James Duncan Davidson has expressed his regrets over the use of XML in ant, Dave Thomas is less than proud of how RDoc has turned out, and I'm pretty sure the only reason the guy responsible for the tabs/spaces distinction in Makefiles hasn't apologized is that he fled to Tijuana for facial reconstructive surgery. Anyway, Leiningen will eventually be in the same position if it's not already.

So we're still left with this question of whether you can be bad and nationwide without also being a jerk. I think it's doable, but you just don't see it much because picking fights is so much easier. One example that comes readily to mind is _why the lucky stiff. He qualified not just by his off-kilter visual style but by his aversion to what he scoffed at as "best practices".

Perhaps this is why I have trouble swallowing unit testing or extreme programming or other best practices as the law. I guess there’s a place for these tricks (the work place,) but they do not speak to the pure form of hacking for hacking’s sake, which I so ardently defend! Unit testing, in particular, is designed to reel in spontaneous hacking. It is like framing a picture before it has been painted. Hacking, at heart, will continue to be something of spontaneous order, something of anarchy, and the landscape of hacking is something which comes from human action but is not of human design.

― This Hack was not Properly Planned

This may not sound particularly controversial, but in the context of the test-driven-fanatic Ruby community it was a pretty weighty heresy. But he was all about exploring the fringe, and some excellent ideas came of it. It caught peoples' eyes and drew them in, so much so that when he disappeared, the communities surrounding his projects picked up the orphaned bits and carried them forward.

Bad... and nationwide.

This is way more productive than us-vs-them fights that normally accompany attempts to be bad and nationwide. So what does this mean for you and me? Most people can't draw like _why, but injecting your own particular brand of crazy into your projects may be a slick hack you can pull to sidestep the negativity.

Here's an example: the new task in Leiningen spits out a blank Clojure project skeleton. At the time I saw a few too many "foojure"-type names popping up for new projects, and when I saw one called "Couverjure" I said enough is enough. Now the new task will refuse to generate projects named after *jure puns. Arbitrary? You bet. Ridiculous? Perhaps. But harmless and easy to work around. And don't forget controversial:

The point is: don't take yourself too seriously. Hack the good hack and leave an easter egg or two around for the adventurous. Then you too can be bad... and nationwide.

-1:-- in which the lessons of ZZ Top are applied to the marketplace (Post Phil Hagelberg)--L0--C0--August 30, 2010 06:23 PM

After many years of development, numerous 1.0preX versions, version 1.0 of CEDET package was released.
This version differs from previous version - 1.0pre7, and contains many changes in Semantic, EDE, and other subsystems. Full list of changes you can find in official announcement.
Source code you can download from project's page and compile it according to instructions.
And after release 1.0, development team continue to work on further integration of package into GNU Emacs, development of new parsers and other stuff, that will allow to improve work with different languages and build tools.

-1:-- Release of CEDET 1.0! (Post Alex Ott (alexott@gmail.com))--L0--C0--August 30, 2010 07:17 AM

When you're typing as much as I do, sooner or later you realize that having a good keyboard is important. Years ago I was having issues with wrist-pain and switching keyboards was - for me - a very effective way of almost eliminating the problem.

But this is not about health issues directly. What I found is that the best way to stay healthy while working is to keep irritation to a minumum, and keyboards can do a lot of things that are just plainly annoying:

• Keys in wierd and/or hard to reach places
• Keys in half-size
• Keys that only work most of the time
• Keys that are much harder to press than the others

Looking at that list, there are two main things that can go wrong: keyboard layout and the key switch technology. I'm going to address both throughout this short series.

I'm going to present the main keyboards I've used in chronological order (that is; order that I used them), but I'm ignoring the very early stuff. Some were not that good (Commodore 64), some were horrible (Atari 400, I'm not even sure if I'd call that thing you've got a keyboard) and some were pretty nice (like the Amiga 500). My focus is on keyboards that are still available and useful to today's PC or Mac user.

As an example of frustrating design, I present:

The MS Natural Elite

All in all it's not a bad board; they're cheap and they're fairly pleasant to type on with light-weight keys, but all the navigation keys are in half-size AND in non-standard places (and yet close enough to the standard locations to get really confusing). Get used to pressing INSERT instead of END and fumbling for the cursor keys. Bad, ugly and unnessessary. Also, in my experience, they break after 3 years or so.

The MS Natural 4000

The successor to the Elite that solved most of the issues with the layout, but the modifier keys and especially the space bar were so heavy I found myself slamming my thumbs on them which can't be good.

The extras, like the horrible multimedia "keys" and the vertical "joystick" or whatever that thing is, I won't further address, since I never used them.

Also, it broke down after only a year. Not good at all for a keyboard that cost about 60 euros at the time.

By now I was getting frustrated by key switches, and I wanted something that would actually let me type in a consistent way and KNOW that I was really pressing a key when I thought I was, without me having to slam every one of them into the ground.

Which brings me to the next post: In search of a better keyboard; The IBM Model M.

-1:-- In search of a better keyboard; Early history (Post Joost)--L0--C0--August 29, 2010 08:04 PM

-1:-- narrowing buffer contents (Post djcb (noreply@blogger.com))--L0--C0--August 29, 2010 07:48 PM

-1:-- Using Emacs for Twitter (Post sivaram (noreply@blogger.com))--L0--C0--August 29, 2010 04:06 AM

We've ditched having a land-line in favor of cellphones and VOIP. My wife uses a cellphone and I mostly use VOIP via Linphone's command-line linphonec.

Consequently I've started writing a GNU/Emacs interface to Linphone. I realize that at least one other attempt has been made by I. Poretsky. But Poretsky's version sends commands to linphonec. This is the Wrong Way To Do It™ since linphonec is a command line interface for humans.

The right way is to send commands via linphonecsh. As described: "Linphonecsh is a console utility to send non-blocking commands to an instance of linphonec running in the background."

The initial revision can be yours for the low-low price of:

git clone http://yrk.nfshost.com/repos/emacs-linphone.git/

unrelated appendix:

After listening to this excellent Yale course on classical music I felt ready to tackle slightly more complex classical material: Igor Stravinsky's "Le Sacre du Printemps" and Bach on piano by Hélène Grimaud. For some reason the Stravinsky puts me in mind of "Bitches Brew" (not the Nomeansno cover though).

-1:-- emacs-linphone, and some more music (Post)--L0--C0--August 29, 2010 03:30 AM

Today I have written code that displays kanji reading in Japanese while chatting on IRC. I often know the meaning of the character but forget the pronunciation. Other people who go to Japanese channel might find this hack helpful.

;; lisp/emacs.d/ivan-erc.el

(defvar ivan-erc-japanese-channel
  "#japanese\\|#nihongo"
  "Regexp of channels that are in Japanese")


(defun ivan-erc-furigana ()
  "Display furigana when receiving a message in Japanese"
  (when (and (string-match ivan-erc-japanese-channel (buffer-name))
             (memq 'unicode (find-charset-region
                             (point-min) (point-max)))
             (ivan-japanese-kanji string))
    (insert (kakasi (buffer-substring-no-properties
                     (point-min) (point-max))))
    (erc-restore-text-properties)))

(add-hook 'erc-insert-modify-hook 'ivan-erc-furigana)

;; /lisp/emacs.d/ivan-japanese.el

(defun ivan-japanese-kakasi (input)
  "Take a Japanese string and return INPUT in hiragana"
  (get-buffer-create kakasi-buffer)
  (with-temp-buffer
    (insert input)
    (let ((coding-system-for-read 'euc-jp)
          (coding-system-for-write 'euc-jp))
      (call-process-region (point-min) (point-max)
                           "kakasi" nil kakasi-buffer nil "-JH" "-s")))
  (prog1
      (with-current-buffer kakasi-buffer
        (setq kakasi-ret
              (buffer-substring-no-properties (point-min) (point-max))))
    (kill-buffer kakasi-buffer)))

(defun ivan-japanese-kanji (string)
  "Return t if string contains Japanese kanji"
  (let ((length (length string))
        (count 0)
        (ret nil)
        (char ?a))
    (while (< count length)
      (setq char (aref string count))
      (if (and (< char ?\u9fa5)
               (> char ?\u4e00))
          (setq ret t))
      (setq count (1+ count)))
    ret))

-1:-- IRC with furigana (Post Ivan Kanis)--L0--C0--August 29, 2010 12:00 AM

[[erc-furigana.gif] Today I have written code that displays kanji reading in Japanese. I often know the meaning of the character but forget the pronunciation. Other people who go to Japanese channel might find this hack helpful.

;; lisp/emacs.d/ivan-erc.el

(defvar ivan-erc-japanese-channel
  "#japanese\\|#nihongo"
  "Regexp of channels that are in Japanese")


(defun ivan-erc-furigana ()
  "Display furigana when receiving a message in Japanese"
  (when (and (string-match ivan-erc-japanese-channel (buffer-name))
             (memq 'unicode (find-charset-region
                             (point-min) (point-max)))
             (ivan-japanese-kanji string))
    (insert (kakasi (buffer-substring-no-properties
                     (point-min) (point-max))))
    (erc-restore-text-properties)))

(add-hook 'erc-insert-modify-hook 'ivan-erc-furigana)

;; /lisp/emacs.d/ivan-japanese.el

(defun ivan-japanese-kakasi (input)
  "Take a Japanese string and return INPUT in hiragana"
  (get-buffer-create kakasi-buffer)
  (with-temp-buffer
    (insert input)
    (let ((coding-system-for-read 'euc-jp)
          (coding-system-for-write 'euc-jp))
      (call-process-region (point-min) (point-max)
                           "kakasi" nil kakasi-buffer nil "-JH" "-s")))
  (prog1
      (with-current-buffer kakasi-buffer
        (setq kakasi-ret
              (buffer-substring-no-properties (point-min) (point-max))))
    (kill-buffer kakasi-buffer)))

(defun ivan-japanese-kanji (string)
  "Return t if string contains Japanese kanji"
  (let ((length (length string))
        (count 0)
        (ret nil)
        (char ?a))
    (while (< count length)
      (setq char (aref string count))
      (if (and (< char ?\u9fa5)
               (> char ?\u4e00))
          (setq ret t))
      (setq count (1+ count)))
    ret))

-1:-- ERC with furigana (Post Ivan Kanis)--L0--C0--August 28, 2010 12:00 AM

A very good remark from some users: installing and managing el-get should be simpler. They wanted both an easy install of the thing, and a way to be able to manage it afterwards (like, update the local copy against the authoritative source). So I decided it was high time for getting the code out of my ~/.emacs.d git repository and up to a public place: http://github.com/dimitri/el-get.

Then, I added some documentation (a README), and then, a *scratch* installer, following great ideas from ELPA. So have at it, it's a copy paste away!

Don't forget to setup your el-get-sources and include there the el-get source for updates, there's nothing magic about it so it's up to you. You may notice that it's not yet possible to init el-get from el-get-sources, though, that's the drawback of the lack of magic. So you will have to still add an explicit (require 'el-get) before to go and define you own el-get-sources then finally (el-get). I don't think that's a problem I need to solve, though.

-1:-- welcome el-get scratch installer (Post Dimitri Fontaine)--L0--C0--August 27, 2010 02:15 PM

emacs: @pragdave I got your back!

-1:-- emacs: @pragdave I got your back! (Post)--L0--C0--August 26, 2010 03:37 AM

Publico la versión en bruto de la traducción del Manual de PCL-CVS,
correspondiente a Emacs 22.2.

Como ya se sabe, se trata de un manual adjunto donde se documenta el
uso de este programa frontis desde Emacs a CVS.

Primera prueba alfa de la traducción, como siempre.

El texto del manual se puede alcanzar en la sección Libros, Mundo
Emacs.

Las actualizaciones las iré poniendo en la página del proyecto.

Copyright de la traducción: TMJQ, S.L.

Agradeceré cualquier sugerencia, crítica u opinión que desee expresar

leer más

-1:-- Publicado el Manual de PCL-CVS para GNU Emacs (Post suso)--L0--C0--August 23, 2010 05:09 PM

Publico la versión en bruto de la traducción del Manual de Supercite,
correspondiente a Emacs 22.2.

Como ya se sabe, se trata de un manual adjunto donde se documenta el
uso de esta utilidad para el citado de mensajes y la adjudicación
de atribuciones en la correspondencia electrónica.

Primera prueba alfa de la traducción, como siempre.

El texto del manual se puede alcanzar en la sección Libros, Mundo
Emacs.

Las actualizaciones las iré poniendo en la página del proyecto.

Copyright de la traducción: TMJQ, S.L.

leer más

-1:-- Publicado el Manual de Supercite para GNU Emacs + html en inglés (Post suso)--L0--C0--August 23, 2010 12:31 AM

I found a Sansa e250 for 10 USD today at a yard sale. I brought it home and immediately installed rockbox. Works fine. Besides playing Doom, I guess I'll start loading it up with music and interesting lectures.

-1:-- More music for me (Post)--L0--C0--August 22, 2010 03:57 AM

doitian posted a photo:

Use xmonad-log-applet to display log in gnome-panel

-1:-- Xmonad, Gnome Panel, xmonad-log-applet (Post doitian (nobody@flickr.com))--L0--C0--August 20, 2010 09:15 AM

First, some background: KDB (a kernel debugger shell) and KMS (kernel mode-setting) combine to let you drop into a graphical shell when something debugger-worthy happens on your Linux machine. That thing might be a panic, or a breakpoint, or a hardware trap, or a manual entry into the kdb shell. Inside the shell you can, for example: get a backtrace, inspect dmesg or ps, look at memory contents, and kill tasks.

This is a big improvement over the previous model of "something bad happens to your laptop while it's in X, and the keyboard LEDs start blinking, and you hard-reboot and wonder what happened and wish your laptop had a serial port".

Here's a video of KDB+KMS in action — it's from Jason Wessel at Wind River, who deserves massive kudos for having enough patience to get all of this debugging code merged into mainline Linux to everyone's satisfaction:



Jesse recently wrote about how to give KDB+KMS a spin on Intel graphics chipsets, and now I've written patches that allow radeon and nouveau users to join in too. The method for testing them is similar to Jesse's:

• git clone git://dev.laptop.org/users/cjb/linux-2.6
• cd linux-2.6
• git checkout kgdb-next
• Config the kernel as in Jesse's post, and build/install it.
• Boot with kgdboc=kms,kbd kernel arguments.
• Enter KDB with sysrq-g, or echo g > /proc/sysrq-trigger, and type go to leave KDB.

If you test with radeon or nouveau, please let me know what hardware you tested on, and whether everything worked. Thanks!

-1:-- KDB+KMS for nouveau/radeon (Post Chris Ball)--L0--C0--August 19, 2010 05:52 PM

I ls-ed some files today and noticed a few listed with blue backgrounds and white text. I use the --color option to ls because it's pretty, and because the colors provide information that's not always blindingly obvious from regular ls output. Case in point, what did this blue background with white text mean?

It turns out that, at least for Ubuntu 9.10 an 10.04 (the two I tried), you can see a list of the colors that ls uses for various things by typing:

dircolors --print-database

Now, I had a hunch that these files were hardlinks, and sure enough, I saw this line:

HARDLINK 44;37 # regular file with more than one link

And looked up a few lines to see that, yes, 44 is blue and 37 is white. Cool. Just to be extra sure I passed the file names to the stat command and saw the, links: 2 for those files.

-1:-- ls colors on Ubuntu (Post Bryan (noreply@blogger.com))--L0--C0--August 19, 2010 04:29 PM

After a relatively quiet period a number of patches have flowed my way so I thought it was worth pushing out a new version. Perhaps the most “important” feature is the edit box flashing and fading from yellow after being updated (like It’s All Text). It wasn’t that hard to do given jQuery and the colour animation plugin do all the heavy lifting.

We’ve added a new hook to the edit-server for pre-edit customisation. If anyone has some nice examples of using the various hooks it would great if you could add examples at the emacs wiki.

As ever the extension can be found at the Chrome Extensions site. Development versions are hosted at github.

Full Change Log

v1.8

Extension

* Added option to enable/disable visual edit boxes
* Improved feedback as editable elements come in and out of focus
* Updated text box will now fade from yellow after an update

edit-server.el

* Added edit-server-start-hook for additional customisation when edit starts

-1:-- Edit with Emacs v1.8 (Post Alex)--L0--C0--August 19, 2010 10:10 AM

I've just released a new version of Leiningen: 1.3.0.

-1:-- in which leiningen valiantly marches on (Post Phil Hagelberg)--L0--C0--August 18, 2010 08:43 PM

emacs: @mediapathic It seems to me that you have some serious anxieties.

-1:-- emacs: @mediapathic It seems to me that you have some serious anxieties. (Post)--L0--C0--August 18, 2010 04:25 AM

Since Emacs predates the widespread adoption of the modern GUI andmouse, its vernacular can be somewhat hard to follow. What you would call a window in a modern GUI is called a frame in Emacs. A window is a panel of a frame in Emacs.

Most window managers have some facility to arrange the visible windows. With Emacs, you cna programmatically manipulate a frame’s size and position from Lisp.

There are a few ways I like to arrange my Emacs frames. I generally use one or two – more are harder to manage – and dedicate them to specific purposes. One always has code buffers in it, and the other can have compilation buffers, IRC, w3m, unit test output, or any other variety of programming-related tools.

When I work with a single frame, I like it to be centered on my screen. When I have two, I like them to be next to each other, in the center. Since it’s hard to align by hand, I wrote some code do to it for me.

(defun screen-usable-height (&optional display)
  "Return the usable height of the display.

Some window-systems have portions of the screen which Emacs
cannot address. This function should return the height of the
screen, minus anything which is not usable."
  (- (display-pixel-height display)
     (cond ((eq window-system 'ns) 22)
           (t 0))))

(defun screen-usable-width (&optional display)
  "Return the usable width of the display.

This works like `screen-usable-height', but for the width of the display."
  (display-pixel-width display))

(defun frame-sort-ltr (frames)
  "Sort frames by their visual order, left to right.

This method takes a list of frames, and returns that list, sorted
by the visual display order. This is determined by comparing the
left position of the frames; the leftmost frames are returned
first."
  (sort frames (lambda (framea frameb)
                 (< (frame-parameter framea 'left)
                    (frame-parameter frameb 'left)))))

(defun frame-box-get-center (w h cw ch)
  "Center a box inside another box.

Returns a list of `(TOP LEFT)' representing the centered position
of the box `(w h)' inside the box `(cw ch)'."
  (list (/ (- cw w) 2) (/ (- ch h) 2)))

(defun frame-get-center (frame)
  "Return the center position of FRAME on its display."
  (frame-box-get-center (frame-pixel-width frame) (frame-pixel-height frame)
                        (screen-usable-width) (screen-usable-height)))

(defun frame-center (&optional frame)
  "Center a frame on the screen."
  (interactive)
  (apply 'set-frame-position
         `(,(or frame (selected-frame)) ,@(frame-get-center frame))))

(defun frame-tile-horizonal ()
  "Tile visible frames horizontally.

This function tiles visible frames, distributing them evenly
across the display, and centering them vertically.

It doesn't know about multi-head displays, and will probably fail
dramatically if used in such an environment."
  (interactive)
  (let ((pos)
        (offset 0)
        (vwidth (/ (screen-usable-width) (length (visible-frame-list)))))
    (dolist (frame (frame-sort-ltr (visible-frame-list)))
      (setq pos (frame-box-get-center (frame-pixel-width frame)
                                      (frame-pixel-height frame)
                                      vwidth (screen-usable-height)))
      (set-frame-position frame (+ offset (car pos)) (cadr pos))
      (incf offset vwidth))))

(defun frame-tile-center-horizonal ()
  "Tile visible frames horizontally, center-weighted.

Rather than tiling frames evenly across the available width of
the display, this function tiles them into the center of the
display, adding a 2% margin in between frames.

It doesn't know about multi-head displays, and will probably fail
dramatically if used in such an environment."
  (interactive)
  (let* ((framewidth (apply '+ (mapcar 'frame-pixel-width (visible-frame-list))))
         (margin (/ (screen-usable-width) 50)) ;; = (/ s-u-w *.02) = 2%
         (totalwidth (+ framewidth (* margin
                                      (- (length (visible-frame-list)) 1))))
         (offset (car (frame-box-get-center totalwidth 0 (screen-usable-width)
                                            (screen-usable-height)))))

    (dolist (frame (frame-sort-ltr (visible-frame-list)))
      (set-frame-position frame offset (cadr (frame-get-center frame)))
      (incf offset (+ margin (frame-pixel-width frame))))))

(defun frame-restore-defaults (frame)
  (modify-frame-parameters frame default-frame-alist))

(defun frame-default ()
  (interactive)
  (mapcar 'frame-restore-defaults (frame-list))
  (if (> (length (frame-list)) 1)
      (frame-tile-center-horizonal)
    (frame-center)))

(provide 'ime-frame)

You can also call M-x frame-tile-center-horizonal or M-x frame-center by hand, if you like.

-1:-- Frame tiling and centering in Emacs (Post Ian)--L0--C0--August 18, 2010 02:05 AM

Today's fun idea was to put all my contacts stored into BBDB on a Google Maps' map, using my Google Maps extension for Emacs.

With the help of a few lines of Lisp glue:

(google-maps-static-show
 :markers
 (mapcar
  (lambda (address-entry)
    `((,(concat
         (mapconcat
          'identity
          (elt address-entry 1) ", ") ", "
          (elt address-entry 2) ", "
          (elt address-entry 3) ", "
          (elt address-entry 4) ", "
          (elt address-entry 5)))))
  (mapcan
   (lambda (record)
     ;; We need to copy the returned list, because mapcan will modify it later
     (copy-list (bbdb-record-addresses record)))
   (bbdb-records))))

we can make that:

It's really simplistic, but I did not need more to have fun. :-) This could be extended to set a specific marker and/or color for each contact, with a legend. I'll let that as an exercise for my readers.

-1:-- Emacs, Google Maps and BBDB (Post Julien Danjou)--L0--C0--August 18, 2010 12:00 AM

I often find myself needing to quickly work on some code that’s mostly unrelated to my task at hand. This comes up often when pair programming and code reviews, where you might want to illustrate a tactic without adding useless code to your current buffer.

Ordinarily, you’d use *scratch*, but it’s useful to have your scratch buffer use mode for the language you want to write code in, and *scratch* doesn’t fulfill this unless you’re hacking on emacs-lisp.

To this end, I created scratch-el, a bit of code for doing just this.

When you invoke it with M-x scratch, it gives you a scratch buffer with the same mode as your current buffer. So if you’re editing Python code, you get a *python* buffer which uses python-mode. If you’re in a shell, you get a shell-script-mode buffer, and so on.

If you invoke it with a prefix argument, as C-u M-x scratch, it will prompt you for the mode to use, which can be helpful if you want to noodle on a SQL query while editing your app code. There is tab completion support for all known major modes.

If you want to save the resulting work, it’s just a C-x C-w away.

-1:-- Scratch buffers for Emacs (Post Ian)--L0--C0--August 17, 2010 03:44 AM

To proper work on different Emacs releases and on different platforms large/complex .emacs config file must check certain condition.

I collect come of them and by this post make it public.

So check variables:

and check functions: Run those checks as below:

-1:-- Determining running environment and platform capabilities in Emacs. (Post gavenkoa (noreply@blogger.com))--L0--C0--August 16, 2010 09:39 PM

The Debian package of Emacs Muse was maintained by Michael W. Wolson, who is also the upstream author of that software.

He announced months ago that Muse needed a new upstream maintainer. That's not something I'm willing to do, since I really think Muse has been superseded by Org mode nowadays.

However, I'm still using Muse to maintain this blog with my muse-blog extension, since Org still lacks some infrastructure to maintain and publish a blog.

Therefore, I adopted the Emacs Muse Debien package and updated it to the latest version!

-1:-- Updating muse-el in Debian (Post Julien Danjou)--L0--C0--August 15, 2010 08:43 PM

I wrote a while ago about my blog-reading woes.  Those woes are now over!

Lars Magne Ingebrigtsen, of Gnus and gmane fame, has now brought us gwene — an RSS to NNTP gateway.  You enter the feeds you want to read, and soon they show up as newsgroups in gmane.  Thanks also should go to Ted Zlanatov, for bringing this up on the gmane discussion list, and thus getting it all rolling.

I haven’t quite retired my rss2email cron job, but that is mostly out of laziness.  Any day now.

Normally I am unhappy about the whole SaaS trend, but gmane gets a pass.  I am not sure if it is because Lars seems trustworthy, or because NNTP is so obviously a fringe interest, or because gmane is at least theoretically replaceable in the event of the worst.

-1:-- Blog Reading Solved (Post tom)--L0--C0--August 14, 2010 07:13 PM

hdaniel posted a photo:

Año 43 Día 89 Número 15795

Programando el Nuevo Sistema de Control de Servicios de Cómputo

-1:-- 43-089 (Post hdaniel (nobody@flickr.com))--L0--C0--August 10, 2010 10:50 PM

Loops are a fairly important part of any programming language and fairly fundamental to a language that is purported to be all about manipulating lists. However it’s not something I use that often in my .emacs code so I thought it might be useful to discuss the various options with some examples.

Problem: I run emacs on a number of machines, each with a different set of sound sets. I want to set up set up a valid sound for erc but I don’t want an overly verbose set of cases depending on what machine I’m on. Instead a given a list of sound files I want a function that will return the first one that actually exists.

This problem can be easily generalised into return the first valid path from a list of paths.

First version: pure emacs lisp

; the 'elisp' way
(defun find-valid-file-elisp-way (list-of-files)
  "Go though a list of files and return the first one that is present"
  (let (r '())
    (mapc '(lambda (f)
             (if (file-exists-p f) (add-to-list 'r f)))
          list-of-files)
    (car r)))

First impressions aren’t good. The lisp parenthesis do seem to get in the way of making what is happening clear. However it’s using one of common mapping functions you see a lot of in lisp. A mapping function essentially takes a list, applies a function to each element of the list and eventually returns a result. The most common of the mapping functions is mapcar which returns a modified list as a result. In this case that isn’t what we want so we use mapc where the only value that is built up is the result r as we identify each valid file. The final return value is just the first entry in that list. This does mean we have processed the whole list of alternatives which is sub-optimal.

Second version: Common Lisp Version

(defun find-valid-file-clisp-way (list-of-files)
  "Go though a list of files and return the first one that is present"
  (loop for path in list-of-files
        until (file-exists-p path)
        finally return path))

This version probably is the easiest to read for people familiar with other programming languages. The intention of the code jumps out at you. However the actual implementation is done with a macro. If you look at the help for loop you’ll see it can take a number of different forms – follow that to the code and you’ll see a fairly complex elisp implementation. However to my mind still easier to follow than the pure elisp version with mapc.

Third Version: Using the dolist macro

; using 'cl-macs
(defun find-valid-file-dolist-way (list-of-files)
  "Go though a list of files and return the first one that is present"
  (dolist (f list-of-files)
    (if (file-exists-p f)
        (return f))))

This is yet another version using an LISP macro but this one has considerably less potential forms to cause confusion. It’s fairly comprehensible what is going on and even follows the traditional parenthesis happy form. It also takes advantage of the common LISP return to early return from the loop when we detect a valid file. If it makes it to the end of the list it evaluates the 3rd optional form to calculate the result which in this case will be ‘nil.

So what do you think? What version do you prefer? Where does the balance lie between writing code is LISPy ways and for code comprehension? Are there any other ways to solve this particular problem? I’ll be looking forward to your comments.

-1:-- Looping in LISP (Post Alex)--L0--C0--August 10, 2010 08:04 AM