Planet Emacsen

Benjamin Slade: Vote for Emacs and Conkeror in the 2011 LinuxQuestions.org Members Choice Awards

2012-02-04T19:08:27+00:00

Vote for Emacs in the Text Editor of the Year category and in the IDE/Web Development Editor of the Year category.

Vote for Conkeror in the Browser of the Year category.

Irreal: Does Elisp Suck?

2012-02-03T21:05:48+00:00

One of the links from the CategoryCode page that I wrote about yesterday is the Why Does Elisp Suck page. The idea is to give people a place to be grumpy about Elisp. My first thought was that, really, Elisp doesn’t suck—it’s a pretty nice language. I’d like to explore this question a bit more.

The answers to the “Why does Elisp suck?” question fall into two classes: the silly and the substantive. The silly answers are “because it’s not Scheme”, or “because it’s not Common Lisp”, or “because it’s not X” for your favorite language X. Are there better Lisps than Elisp? Of course. I’d argue that Scheme and Common Lisp are both better Lisps but that doesn’t mean Elisp sucks. If your X is something like Python or Ruby I’d wager that you aren’t really comfortable in Lisp but you’re certainly entitled to your opinion. On the other hand, preferring Python or Ruby or whatever also doesn’t mean Elisp sucks. In short, the fact that you’d rather code in a language other than Elisp doesn’t have very much to say about Elisp.

Of the substantive answers, only 3 are really of any concern to me. First and foremost is the lack of lexical scoping. That’s fixed (for certain values of fixed) in Emacs 24. The second problem is the lack of tail call elimination. Technically, Common Lisp doesn’t have this either—in the sense that it’s not in the standard—but as a practical matter all serious implementations of CL do eliminate tail calls. This matters to me because it enables a style of iteration that I prefer: see my rpl function for instance. Finally, there is no threading or concurrency. This bothers me less than the first two but it does mean that packages like gnus can slow things down.

Some of the other substantive problems with Elisp are no object system (a feature not a bug in my opinion), no module system (a pain because of name collisions but I can live with it), clumsy regular expressions (especially if what you really want are Perl regexps), and the API sucks.

Someone also noted that the Elisp implementation is slow. That’s true, I guess, but doesn’t really speak to whether or not Elisp sucks. It would be nice if things were snappier but on modern machines it seems fast enough to me. I’d guess that font locking and things like that have more to do with performance problems than the Lisp engine.

All-in-all, I find Elisp to be a comfortable language to write in. Not as powerful as Common Lisp and not as well designed as Scheme but still nice. What does everyone else think? Is Elisp something you put up with or do you like the language? I’d be surprised if very many people said it was their favorite language but I’d also be surprised if many Elisp users really do think the language sucks.

Ben Simon: Friday Funnies

2012-02-03T17:07:00+00:00

Been a heck of a week...here a few items that made me chuckle...

These videos are too cute. I give you: Rich Kids for Romney (and another one here). Seriously, watch and try not to laugh?
I'm not a big fan of pranksters. And I'm especially not a fan of pranking police. But even I couldn't help but smile at this story. Inmates were in charge of creating the decals for police officers and this is what they came up with:

Nothing wrong with that, right? Except, there is. Read on why here.
Rule number #1: if you're going to cause a dust up on the Internet, you want someecards on your side. Man, they can quickly produce hilarious stuff.

Irreal: Learning Elisp Idioms

2012-02-02T20:19:30+00:00

I’ve said before that Emacs Lisp is pretty much like any other Lisp except for its library, which is specialized for editing tasks. One of the things I like about Xah Lee’s Emacs Lisp Tutorial is that it doesn’t concern itself too much with Lisp itself but presents Elisp use cases and idioms. If you already know a little of any Lisp, then Xah’s tutorial is a good place to go to come up to speed with Elisp.

Today, I found another good resource: The CategoryCode page on the Emacs Wiki. They’ve got a long list of articles that show you how to do various tasks in Emacs Lisp. One page, the Elisp Cookbook, is particularly helpful. It contains a collection of code snippets for many common chores. Other articles are more specialized; they have, for example, an article on a Password Generator. Some of the articles are quite detailed while others merely describe a library that’s good for doing some task or another.

If you’re new to Elisp but have a basic knowledge of Lisp, I’d start with Xah Lee’s tutorial and then try some of the articles on the CategoryCode page. Of course, the definitive source is the GNU Emacs Lisp Reference Manual, which is also available in the built-in documentation. If you need to know the particulars about some function or slightly broader area, that’s the place to look but I don’t find it particularly useful for learning the ins and outs of Elisp. The other outstanding resource you have for that is Emacs itself. You might try reading simple.el, for example, to see how some of the simple editing functions are implemented. It will give you a good feel for Elisp idioms.

tycho garen: Persistent Emacs Daemons

2012-02-02T05:00:00+00:00

I've been subject to a rather annoying emacs bug for months. Basically, when you start emacs with the --daemon switch, and the X11 session exits, and any emacs frames are open, then the emacs process dies. No warning. The whole point, to my mind, of the daemon mode is to allows emacs sessions to persist beyond the current X11 session.

This shouldn't happen. I think this is the relevant bug report, but I seem to remember that the issue has something to do with the way that GTK interacts with the X11 session and emacs's frames. It's something of a deadlock: the GTK has no real need to fix the bug (and/or it's a behavior that they rely on for other uses,) and it might not really be possible or feasible for emacs to work around this issue.1

I also think that it's probably fair to say that daemon mode represent a small minority all emacs usage.

Regardless, I've figured out the workaround:

.. don't use GTK.

Turns out, it's totally possible to build GNU emacs without GTK, by using the "Lucid" build. Which is to say, use the windowing system kit built for Lucid Emacs (i.e. XEmacs,) rather than GTK. I was able, using the code below, to get an emacs experience with the new build that seems identical2 to the one I used to get with GTK, except without the frustrating crashes every time that X11 spazzed when I decided to unplug a monitor or some such. A welcome improvement, indeed.

The following emacs-lisp covers all of the relevant configuration of the "look and feel" of my emacs session. Install the Inconsolata font if you haven't already, you'll be glad you did.

 (setq-default inhibit-startup-message 't
               initial-scratch-message 'nil
               save-place t
               scroll-bar-mode nil
               tool-bar-mode nil
               menu-bar-mode nil
               scroll-margin 0
               indent-tabs-mode nil
               flyspell-issue-message-flag 'nil
               size-indication-mode t
               scroll-conservatively 25
               scroll-preserve-screen-position 1
               cursor-in-non-selected-windows nil)

 (setq default-frame-alist '((font-backend . "xft")
                             (font . "Inconsolata-14")
                             (vertical-scroll-bars . 0)
                             (menu-bar-lines . 0)
                             (tool-bar-lines . 0)
                             (alpha 86 84)))

 (tool-bar-mode -1)
 (scroll-bar-mode -1)
 (menu-bar-mode -1)

Hope this helps you and/or anyone else that might have run into this problem.

I'd like to add the citation and more information here, but can't find it. ↩
To be fair, I mostly don't use the GUI elements in emacs, though having emacs instances outside of the terminal is nice for displaying images when using emacs-w3m, and for having a little bit of additional display flexibility for some more rich modes. ↩

Emacs-fu: update

2012-02-01T18:24:56+00:00

Regular emacs-fu programming will resume shortly, but for now I'll provide a brief update on some of my projects.

Recently, I discussed sauron, and event-tracking tool for emacs. I added some new features, fixed some bugs, and got some contributions (yay!)
- tweak/improve priority handling
- add a backend for the emacs-24 notification system
- add settings to make the sauron frame 'sticky', and to hide the mode-line
- enable dbus-message source outside your session; useful for cron/procmail etc.
- display events in a tabular fashion
- add support for John Wiegley's event.el
- much improved documentation
- other things…
Sauron version 0.2 is available through Marmalade (see Package Management Revisited)
I released version 0.9.8 of mu (e-mail searcher/indexer, previously discussed in Searching e-mails with Wanderlust and mu). Now, for emacs-users I've added mu4e (manual), a new & experimental e-mail client. It won't be big and professional like gnus, but it's fun to hack on, and I've been using it for a few months.

Got Emacs?: No Gnus v0.19 is released

2012-02-01T17:10:43+00:00

Lars has tagged and released v0.19 and created a new branch ma gnus 0.1 too.

Got Emacs?: Installing AucTeX and Preview LaTeX on Windows

2012-02-01T17:05:39+00:00

So, I upgraded my Emacs to the latest version and went through the steps of compiling my elisp packages on my Windows XP laptop and promptly struggled a bit on getting Auctex and Preview LaTeX to work. I've decided on documenting it; well, only the key steps with a lot of hand waving and assumptions thrown in.

Namely,

Cygwin toolchains are installed(that's what I have)
MiKTeX is installed(whatever version)
Win32 Emacs from the official GNU site (I used 23.4)
Ghostscript is installed too (I used the cygwin based one)

In the cygwin terminal, either checkout the cvs version of Auctex or download the tarballs and untar it somewhere. Presumably you have MiKTeX and Emacs installed already somewhere; preferably in a folder path that doesn't contain spaces in it's name(It should work with spaces in the path name but I haven't and daren't try that; I really don't need that aggravation).

First you run configure to generate the Makefile

./configure --with-emacs=c:/gnu/emacs-23.4/bin/emacs --prefix=c:/gnu --with-texmf-dir=c:/MiKTeX2.9

If you haven't got all the build tools needed (make, install, latex,perl..) it will stop. Fix each one of them by installing the necessary packages by using the cygwin package manager setup.exe. Of course, you need to adjust the paths above.

By default, the preview build is enabled by default, which, you can disable by adding the option --disable-preview to configure above, if you don't want to preview your latex document that's got figures and maths.

When the Makefile is generated, run make. Do not do a make install. You can use the files in situ by following the instructions of Tassilo Horn here. You'd probably need to add the following to get the correct info files of Auctex.

;; AUC TeX
(add-to-list 'load-path "C:/gnu/elisp/auctexcvs/auctex/")
(load "auctex.el" nil t t)
(add-to-list 'load-path "C:/gnu/elisp/auctexcvs/auctex/preview/")
(load "preview-latex.el" nil t t)

;;set the path to info files of auctex

(setq Info-default-directory-list
(cons "c:/gnu/elisp/auctexcvs/auctex/doc" Info-default-directory-list))

I prefer it this way as this does not change the directory structure of a stock install of Emacs on Windows. Easier to share the folders for someone to copy without borking something.

Navigate to the preview folder and load the circ.tex and compile it. It should hopefully do so.

For preview you need the png or jpeg image support with Emacs. I've used the dlls mentioned in the Emacs README.w32 that are hosted on the GTK website. Specifically, the png and zlib ones that I downloaded and just dumped in the Emacs bin directory. Added the following to my .emacs

(setq preview-image-type 'png)

Ran the preview command on the circ.tex buffer and it showed the equations and images inline which is what it's supposed to do. If you want jpeg support you'd have to get the jpeg dlls for win32 somewhere(the install files mentions gnuwin32 site)

Which is where I stop now as it all works fine and dandy for me. The various install files tell you not to mix the cygwin paths and normal DOS paths and other such warnings. But I haven't seen anything that has knackered my installation or borked my usage of them with different bits of win32 and cygwin tied together with AucTeX

So far.

Marco Zuliani: How do I visualize nicely a CSV file in *macs?

2012-01-31T17:38:12+00:00

Once you load the CSV file enter the org-mode: M-x org-mode. Then select the entire data and create a table: C-u C-c |.

Johan Andersson: Wrap region 0.4.0

2012-01-28T08:00:00+00:00

I just updated wrap region to version 0.4.0. The update includes two important changes: custom trigger key and mode specific wrappers.

Custom trigger key

When you add a wrapper, say ( and ), the left punctuation will be used as the trigger key. Now you can add wrappers with a custom trigger key. For example, lets say you want p to wrap with the p-tag. Then you can do this:

(wrap-region-add-wrapper "<p>" "</p>" "p")

This feature is implemented by tkf, thanks!

Mode specific wrappers

The most notable feature though is mode specific wrappers. This allow you to specify wrappers for specific modes. The docstring for wrap-region-add-wrapper now looks like this:

(wrap-region-add-wrapper LEFT RIGHT &optional KEY MODE-OR-MODES)

An example usage is the wrapper above. That wrapper only makes sense in html-mode, which can be specified.

(wrap-region-add-wrapper "<p>" "</p>" "p" 'html-mode)

Now p will only wrap in html-mode.

Lets say you want # to wrap with # and # in all modes except css-mode and java-mode, then # should wrap with a comment (/* and */).

(wrap-region-add-wrapper "#" "#")
(wrap-region-add-wrapper "/*" "*/" "#" '(css-mode java-mode))

This feature is implemented by me and tkf, thanks again! :)

Check out the README for more information.

Tom Tromey: Difficulties of elisp

2012-01-28T03:36:02+00:00

The thesis that underlies my project to translate the Emacs C code to Common Lisp is that Emacs Lisp is close enough to Common Lisp that the parts of the Emacs C code that implement Lisp can be dropped in favor of the generally superior CL implementation. This is generally true, but there are a few difficult bits.

Symbols

The primary problem is the translation of symbols when used as variable references. Consider this code:

(defvar global 73)
(defun function (argument)
  (let ((local (something-else))
    (+ local argument global)))

More is going on here than meets the eye.

First, Emacs Lisp uses dynamic binding by default (optional lexical binding is a new feature in Emacs 24). This applies to function arguments as well as other bindings. So, you might think you could translate this straightforwardly to:

(defvar global 73)
(declare (special global))
(defun function (argument)
  (declare (special argument))
  (let ((local (something-else))
    (declare (special local))
    (+ local argument global)))

This was the approach taken by elisp.lisp; it defined macros for let and let* (but forgot defun) to do the dirty work:

(defmacro el::let* ((&rest vars) &rest forms)
  "Emacs-Lisp version of `let*' (everything special)."
  `(let* ,vars (declare (special ,@(mapcar #'from-list vars))) ,@forms))

But not so fast! Emacs also has buffer-local variables. These are variables where the value is associated with the current buffer; switching buffers makes a different binding visible to Lisp. These require no special syntax, and a variable can be made buffer-local at any time. So, we can break the above translation simply by evaluating:

(make-local-variable 'global)
(setq global 0)

Whoops! Now the function will return the wrong result — the translation will have no way to know that is should refer to the buffer-local value. (Well, ok, pretend that the setq magically worked somehow…)

My idea for implementing this is pretty convoluted. Actually I have two ideas, one “user” and one “kernel”:

User

I think it is possible to use define-symbol-macro on all symbols that come from Elisp, so that we can tell the CL compiler about the real implementation. However, a symbol can either be treated as a variable, or it can be treated as a symbol-macro — not both at the same time. So, we will need a second location of some kind to store the real value. Right now I’m thinking a symbol in another package, but maybe a cons or some other object would work better. In either case, we’d need a macro, a setf method for its expansion, and some extra-tricky redefinitions of let and defun to account for this change.

This would look something like:

(define-symbol-macro global (elisp:get-elisp-value 'global))
(defsetf elisp:get-elisp-value elisp:set-elisp-value))
;; Details left as an exercise for the reader.

This solution then has to be applied to buffer-, keyboard-, and frame-local variables.

Kernel

The kernel method is a lot simpler to explain: hack a Common Lisp implementation to directly know about buffer-locals. SMOP! But on the whole I think this approach is to be less preferred.

Phil Hagelberg: in which an interview is posted

2012-01-27T03:58:25+00:00

The folks over at The Setup just posted an interview with me wherein I rant about hardware, interactivity, and Emacs.

Note: this was written up over a month ago; if I were interviewed today I couldn't help but mention the Nix package manager. I use it on my Debian Squeeze system to complement apt-get; I get all the system-level stuff that has to be stable from Debian and anything that needs to be fresh from Nix.

Rubén Berenguel: Learning to use vim in my iPad (even if I'm an emacs geek)

2012-01-26T14:37:08+00:00

Just in case you don't know, vi is an advanced text editor, drting back from the same era as emacs was developed (emacs started slightly earlier). Sort of the Jekyll to emacs' Dr Hyde. Emacs users despise vi users, and vi users mock emacs users. This is what the editor wars are all about: "Eight Megabytes And Constantly Swapping" versus "vi has two modes: writing and beeping". If you have been long enough in this blog, you know I'm in the emacs side, but you also know I'm curious enough to delve into the other side.

My first contact with vi was in our first programming class at the University, Informatica (Computer Science). Vi was the editor of choice for the course, so much that you did not have any other option given. Along with a Linux cheatsheet and a short C manual came a vi cheatsheet. A lot of people came to hate vi, a lot of people came to love it. I was more in the hating side, but it wasn't that bad. After a while I just started using a "normal" Linux editor (it was Kate, maybe?) and kept using it (or UltraEdit when I was in Windows) until the end of my degree.

When I finished my degree I had to be a teacher of Calcul Numeric (Numerical Analysis), the third (and last) programming class in the degree. At home I was still using Windows, because the wifi card in my notebook had no Linux drivers and in my office we were using Ubuntu. I needed a cross-platform editor that was quick, versatile and could last for a lifetime. I tried vi (again) and emacs, emacs won the war for two reasons. First was the fact that it was extensible programming in Lisp, and I had already a decent knowledge of Lisp. The second was AucTeX and its "preview" option for LaTeX editing. Nothing can beat pressing C-p C-p C-d and seeing your formulae come to life in your editor. I became an emacs advocate for this reason, then after 5 or 6 years I've found many more reasons why this is the editor. Or, the operating system, if you prefer.

But advocacy is nice, but knowing all the players in the field is better. My department pals used vi (at least most of them), and it was impossible to convince them to switch. I decided learning vi (or vim, vi iMproved) was something I had to do some day, to learn what was there. After all, if I liked it so much I could set viper-mode in emacs and use vi keys in emacs. The best of two worlds, if that world is so nice.

Then the guys at Applidium released a Vim port for iOS devices. Whoah! Even if I'm an emacs guy to the bone, a modal editor is way better than anything else available in the app store, at least for raw editing power. And I say with knowledge, because I've tried most writing apps for iOS devices (see this post).

As an additional reason, Matt Might posted a New Year's post detailing several resolutions for programmers. Among them was breaking your comfort zone to keep your mind sharp. The first example? Switching to vi from emacs or vice-versa. He used to be an emacs user before getting to use Vi. I don't think I could go that far, but these were enough reasons: advocacy (from me, not against me), iPad+bluetooth keyboard and breaking my comfort zone.

How is the experience so far?

Well, I'm writing this post in my sofa, with my iPad and my bluetooth keyboard sitting in my lap. I'm still getting used to having to exit editing mode to move around: I'm very used to pressing C-a or C-e to go to the beginning of end of line. An additional problem is that even with the bluetooth keyboard, Esc can't be mapped to the Esc event, and I needed something to do it. I have jk (pressed together) for it. It was a suggestiond I saw in Hacker News' comment thread for the release of the app, and it's quite handy. Not so much with the on-screen keyboard, but for now it's okay. To remap this, press backslash (the current mapping for Esc) and then :imap jk . Of course if your usual writting language involves writing the jk combination frequently (I think I could come up with one or two examples in Icelandic), this is not the best combination. The other suggested option is :imap al . Easy to tap in a virtual keyboard, not so straightforward in a normal keyboard.

I found out also how to change the font size, at least for now this works (maybe there will be more fonts available in the future), type :set guifont=Courier:h24 (for 24 pixels)

To round everything, I just installed the famous solarized color theme, dark in vim for iPad. Until now I had just thought it was an overhyped color scheme: I had tried in my emacs and didn't enjoy it that much. But in my iPad it shines with a distinct colour, it's so much easier on my eyes that it hurts to get out and write an email! To install it in your vim for iOS, first download solarized.vim from the git repository, then plug your iDevice and use iTunes File Sharing to copy this file to the vim app. Then open vim, :e solarized.vim and :call mkdir(.vim/colors/) (to create the directory needed for it) :w .vim/colors/solarized.vim This is just because I didn't seem to get iTunes File Sharing to work with hidden files (a file starting with a dot is hidden). Then you have to add the following to your .vimrc:

syntax enable
set background=dark
colorscheme solarized

I recommend using this app for any emacs lover out there with an iPad. Of course, it is not emacs, but vim is a pretty awesome text editor, and it's always handy to learn to use it.

To have a useful list of vim commands at hand I installed the Vimmy app, a universal app with the most common vi commands. I can switch to it via the multitasking gestures in my iPad, or use it in my iPod Touch while I'm using it in the iPad.

Conclusion

I don't think I'll ever switch from emacs to vim any time in the future, as I said AucTeX is definitely too good. Of course since then I've found many more things I love: having a REPL for Python, Clojure or Lisp inside my editor. There's even a REPL for PostScript! Also local remote editing with tramp... There are too many things I use on a daily basis and I can't barely remember, they are so entrenched in my .emacs file I can't even realise what they are. But for my iPad it is an awesome addition to write text on the go.

Again, if you have never used vim before and are interested, give it a try. Of course the first time you open it it will be... a jump into the unknown. Tap the screen, press :e filename and start editing happily. Esc (well, jk or backslash, as the initial mapping) :w to save. And you can even :q to exit to springboard!

Tom Tromey: Emacs and Common Lisp, Part 2

2012-01-25T15:01:21+00:00

This is a followup to my earlier post on converting the Emacs C code into Common Lisp. This one is a bit more technical, diving into some specifics of the conversion process.

Basics

One important fact is that we do not need to convert an arbitrary C program to Common Lisp. This might or might not be efficiently possible — but we do not care. We only need to convert Emacs. This is simpler for two reasons. First, we can just ignore any C construct that Emacs does not use. If the translator barfs after some new update, we can fix it then. Second, Emacs itself is already written in a relatively Lispy style, being a Lisp implementation itself. We further exploit this by allowing the translator to know some details about Emacs. As a trivial example, all the Smumble globals created by the DEFUN marco need not be translated into Common Lisp as structure constants — they are an artifact of the implementation, and will show up directly in the generated defuns instead.

What to ignore

A good portion of Emacs is simply redundant in the CL world. There are a few types (cons, vector, integers, functions) that are shareable — in fact, sharing these is part of the goal of this effort. There are also a number of functions which are effectively identical. There are also entire redundant modules, like the garbage collector, or the bytecode interpreter.

The question is how to have the translator differentiate between what is useful and what is not, without breaking builds of future versions of Emacs.

I don’t currently think there is a high road to solving this problem. For modules like the GC, I plan to have ad hoc translator rules for the particular source files. For functions and data types, I’m adding new GCC attributes that I can use to mark the ignorable definitions.

Types

There are two type-related issues that arise when translating the source.

First, how should Emacs-specific types be represented? Primarily these types are structures, like struct buffer or struct string (we cannot use the CL string type, because Emacs adds properties directly to the string, and Emacs has its own idiosyncratic character handling). My answer here is to just straightforwardly translate them to defstruct.

The other question is when translating a C function, what do we do with the types of local variables? For the most part I am pretending that they don’t exist. This works fine except for local arrays and structures, but these are easily handled by initializing variables properly. My rationale is that while this is slower, it lets me get something working more quickly, and we can always update the translator to emit CL type declarations later on.

This simple approach doesn’t actually cover all the needed cases. For example, there is code in Emacs that takes the address of a local variable and passes it somewhere. This is easy to deal with; much of the remaining work is just digging through the code looking for special cases to clean up.

I’m similarly omitting type declarations from the generated structures. One possible nice side effect of this approach is that it will make it easier to lift Emacs’ file-size restrictions, because there will no longer be any code assuming that the size is a fixnum.

Macros

Many low-level details of the Emacs implementation are hidden in macros. For example, Emacs stuffs some type information into the low-order bits of pointers. It uses macros to add or remove this information. For this build, I redefine these macros to do nothing. This makes the GCC Gimple representation much closer to the abstract meaning of the program, and thus simpler to translate.

There are also some macros that are useful to redefine so that we can more easily hook into them from the translator. For example, Emacs has a C macro INTEGERP that is used to check whether its argument is an integer. Normally this macro uses bit twiddling to get its answer, but I redefine it like so:

#undef INTEGERP
extern Lisp_Object *INTEGERP (Lisp_Object)
    __attribute__((lisp_form("integerp")));

Example

The translator is not nearly complete, but it can already do a fair job at translating simple functions. For example, here is “forward-point” from the Emacs C code:

DEFUN ("forward-point", Fforward_point, Sforward_point, 1, 1, 0,
       doc: /* Return buffer position N characters after (before if N negative) point.  */)
  (Lisp_Object n)
{
  CHECK_NUMBER (n);

  return make_number (PT + XINT (n));
}

Here is what the translator comes up with:

(defun Fforward_point (n)
  (let (
    temp-var-0
    Qintegerp.316
    temp-var-1
    current_buffer.317
    temp-var-2
    )
    (block nil (tagbody
      bb-0
        ; no gimple here
      bb-1
        ; no gimple here
      bb-2
        (setf temp-var-0 (integerp n))
        (if (== temp-var-0 nil)
          (go bb-3)
          (go bb-4))
      bb-3
        (setf Qintegerp.316 Qintegerp)
        (wrong_type_argument Qintegerp.316 n)
      bb-4
        (setf current_buffer.317 current_buffer)
        (setf temp-var-2 (buffer-pt current_buffer.317))
        (setf temp-var-1 (+ temp-var-2 n))
        (return temp-var-1)
  ))))

(defun elisp:forward-point (arg0)
  (Fforward_point arg0))

The output looks pretty weird, because the translator works after GCC’s CFG is built, and so the most straightforward translation is to use this mess with tagbody. I doubt this matters much, but in any case the translator is readily hackable — it is still less than 400 lines of Python, including comments.

One thing to note is the translation of “PT“. This is actually a macro that refers to the current buffer:

#define PT (current_buffer->pt + 0)

The translator properly turns this into a reference to “buffer-pt“.

Another detail is the handling of packages. My plan is to put the Emacs implementation into one package, and then any elisp into a second package called “elisp“. A DEFUN in the C code will actually generate two functions: the internal one, and the elisp-visible one; hence the “elisp:” in the translation.

Next Steps

There’s still a good amount of work to be done. The converter punts on various constructs; type translation is implemented but not actually wired up to anything; the translator should emit definitions for alien functions; and plenty more.

"David's World": Cognitive Modeling and Computational Linguistics

2012-01-25T02:30:13+00:00

This workshop provides a venue for work in computational psycholinguistics: we invite a broad spectrum of work in the cognitive science of language, at all levels of analysis from sounds to discourse. It will be held at NAACL-HLT'2012 in Montreal.

Find the full Call for Papers here.

Ben Simon: My Dozen Lines of Code

2012-01-24T13:52:00+00:00

Today's ProgrammingPraxis challenge is this gem:

A high-school programming teacher recently asked for examples of short programs with a high “cool” factor, the idea being to get his students interested in programming computers. I’m not sure the suggestions would work; today’s high-school students have been surrounded by computers their entire lives, and it takes a lot to make them think a program is cool. Being from a different generation, I can remember when I thought it was cool that a program properly skipped over the perforation on a stack of green-bar paper — many programs didn’t! Your task is to write a cool program in a dozen lines of code. You can define cool in any way that you wish. Try not to abuse the definition of “line of code,” at least not too badly; to be concrete, we will say that your solution must not exceed 12 lines, and each line must not exceed 80 characters including white space. When you are finished, you are welcome to read or run a suggested solution, or to post your own solution or discuss the exercise in the comments below.

The ideal intro-to-programming example should meet two needs: (1) it should be relevant and interesting to students and (2) it should lay the groundwork for learning good habits.

Meeting those two goals in 12 lines of code is tricky. But, I think doable. In fact, I believe I've done it below.

Using AutoHotKey, I've written a simple implementation of the classic Boss Key. While not exactly some exciting 3D game, I'd say that this sort of example is relevant and at least interesting to students. And while it may not be obvious, there are a number of best practices taught, including:

Use the right programming language for the job. AutoHotKey makes scripting trivial, so embrace it.
Learn about regular expressions
Learn how to read language reference documentation
Learn about loops
Learn that programming is all about solving your problems and making life better
Learn about variables and the advantages of not hard coding values throughout code
Many opportunities for growing this example

OK, enough talk, here's the code:

;; A simple Boss Key app. My contribution to the dozen-line program contest.
NeedToHide = .*(Mozilla|Explorer|Chrome).*
WantToShow = .*emacs.*
#b::
  SetTitleMatchMode, RegEx
  WinGet, id, list, %NeedToHide%
  Loop, %id% {
    this_id := id%A_Index%
    WinHide, ahk_id %this_id%
  }
  WinActivate, %WantToShow%
  Return,

You can run this by downloading autohotkey (it's free) and running:

  autohotkey bosskey.ahk

Once you run the above code, hitting Windows+b will hide all your browser windows and bring emacs to the front. The windows aren't just minimized, they are hidden so they don't appear in your start bar.

You'll probably want this command available (Windows+w) too, as it restores all your browser windows:

#w::
  DetectHiddenWindows, On
  SetTitleMatchMode, RegEx
  WinGet, id, list, %NeedToHide%
  Loop, %id% {
    this_id := id%A_Index%
    WinShow, ahk_id %this_id%
  }
  WinActivate
  Return

And yes, I know the syntax and semantics of AutoHotKey are hideous. But, given how powerful it is, I think it's a platform worth learning on.

Alex Bennée: Switching buffers and Google+

2012-01-24T08:36:44+00:00

When you do so much of your work in one text editor the efficiency of switching between buffers becomes more important. For a long time I’ve had two bindings “C-x b” and “C-x C-b” which in days of yore I had bound to bs-show and a hacked up list-buffers that opened another window. These are broadly the “quick switch between working buffers” and “show me all the buffers”.

For some time I’ve relegated bs-show to the longer binding and now use Stephen Bach’s excellent Lusty Explorer which works really well when you know the name of the buffer and it’s fairly unique. However when you’ve been going a while it can get un-manageable with a large number of open buffers, especially if you’ve opened second copy of a file from another source tree. This is what I would use the old classic bs-show for.

A few days ago I discovered ibuffer-mode with it’s ibuffer-bs-show buffer navigator. Looking back through the Planet Emacsen history I can see it has been mentioned before and given it’s been in Emacs since version 22 I’m surprised I hadn’t cottoned on to it earlier.

One thing that might have put me off is the initial buffer list can be quite sparse. By default you only see buffers with files associated which misses out IRC, Edit with Emacs and *scratch* buffers. However hit “h” and you’ll see there are a plethora of quick keys for chaning the view. A quick “//” and all filters are removed and you can quickly filter by different criteria. To get the most out of the mode you’ll probably want to set up some custom filters (“/r<completing filter name”>) to make quickly switching to groups of buffers easy. I currently have “work”, “remote”, “irc” and “logs” as filters. You can filter by name as well as major-mode.

ibuffer-mode does have the concept of Filter Groups although I’m not sure what they add on top of having normal filters which as far as I can tell can be arbitrarily complex. It also has some quite handy sorting and selection modes e.g. “sv” – sort by last viewing time. Given the amount of space the wiki devotes to the topic I wish I’d re-examined my buffer switching habits sooner. The change is already paying dividends for my productivity.

Before I go I thought I’d put in a quick mention of Google+. There is growing community of fellow Emacs users starting to post on it. One thing that attracts me to Google+ over Facebook (too data-miney) and Twitter (too short) is the concept of “Circles”. It makes sharing geeky Emacs posts with people that might actually care easy while sparing them the flood of baby pictures I share with friends and family. If you’d like to follow me or my alter-ego please do mention Emacs in your profile or in a message so I can assign you to the correct circles.

Ignacio Paz Posse: emacs using recode-region for encoding failures

2012-01-23T21:07:05+00:00

I had an encoding issue that was bugging me inside the remember-data-file. I don’t know exactly how some latin-1 characters copy-pasted there ended up being saved as raw-text and were shown like non-ASCII characters (so a multibyte characters like “é” will appear with it’s escaped octal code “303\251″ )

I tried at first setting the file’s encoding system with the tag “-*-coding: utf-8 -*-”, though it seemed not sufficient. The raw characters remained there and I soon grew tired of having to type in: “utf-8” at the prompt to select the encoding every time I needed to save the file.

Today searching the manual found here one easy cure on the command “recode-region” which allows to convert the text that was decoded with the wrong coding system.

Really all it took after marking the whole buffer (C-x h) was doing: “M-x recode-region RET” “Text was was really in: utf-8” “But was interpreted as: raw-text”

That was it!, the drag is over, I’m back to storing notes quickly doing just C-c r and C-c C-x with the worthy remember mode.

Robert Adesam: First Post

2012-01-23T16:13:54+00:00

Ok my first blog post, should be about me right? No, you can read about me on my web site http://www.adesam.se/robert/.

Instead let's talk about what I am presumably going to write about. I think it's going to be about computers, technology in general and Emacs in particular. Maybe I will find time to post notes about GTD etc as well...

Emacs -- what is it and why do I use it? It's a way of life... or as stated in Wikipedia, it's a text editor that is higly extensible and customisable. If you know a little bit of LISP one can very quickly tweak Emacs to do what you want. I use Emacs for writing papers, programming, reading/writing emails, and organising my life. Now days I am quite comfortable with Emacs, but over the years I have tried to exchange Emacs for other tools like Eclipse, Thunderbird, Mail.app, etc but I have given up. Emacs is for me, and it works basically the same way on all systems I use: Mac OS X, Windows, Linux, Solaris...

Flickr tag 'emacs': Vim user

2012-01-21T14:26:29+00:00

santosh.wadghule posted a photo:

I love vim editor

Vincent Toups: Shadchen: A pattern Matching Library for Elisp

2012-01-19T19:52:27+00:00

A pattern matching library for Emacs Lisp

One of the things I like most about Racket (and other functional programming languages) is that they have good support for pattern matching, which is a great way to simultaneously dispatch on structure type, enforce constraints on values held in a data structure, and bind variables. A tremendous amount of code is devoted to these activities, and pattern matching combines them all in a succinct, easy to read form.

It's been my intent for some time to write a complete pattern matching library for Emacs Lisp, since it is a Lisp which I use very frequently. Shadchen is the first time any attempt to do so has resulted in a reasonable product. Shadchen is a Yiddish word for matchmaker, in case you were wondering about the title. The library is available in my elisp repository. Even though it comes in a giant directory full of junk, it runs standalone.

[EDIT: Here it is in a standalone repo.]

How it Works

Shadchen's interface consists of just three forms. match is the work horse - it actually performs a pattern match. match has the syntax:

(match <VALUE>
 (<PATTERN1> FORMS ...)
 (<PATTERN2> FORMS ...)
 ...
 (<PATTERNN> FORMS ...))

The <VALUE> expression is evaluated, and then each pattern attempts to match against it. If a pattern succeeds, it's associated FORMS are evaluated, in a context where the environment has been extended by the pattern's bindings. If a match fails, the next pattern is tried. If no patterns succeed, an error occurs.

Here is an example:

(match (list 1 2 3)
  ((list x y z) (+ x y z)))

The expression (list x y z) is the pattern in the above expression. Patterns are such that they resemble the code which creates the data structure in question, in this case a three element list. The pattern (list x y z) basically specifies that a match occurs when the input value is a three element list. When a match occurs, x is bound to the first element, y to the second and so on. Hence this form evaluates to 6.

Here is another example: summing a list:

(defun* dummy-sum (lst &optional (acc 0))
 (match lst
  (nil acc)
  ((cons hd tl)
   (dummy-sum tl (+ acc hd)))))

First we specify the pattern nil, which matches only nil. When the input is nil, we return the accumulator. Then we match against (cons hd tl) which matches a cons pair, binding hd to the car and tl to the cdr. We then recur, adding to the accumulator.

The pattern matching language is rich. There are patterns for matching against literals, applying functions to values, matching against arbitrary conditions, matching against structs.

Eg:

(defstruct a-struct f1 f2)

With this struct defined, the pattern:

(struct a-struct (f1 (? #'numberp x)) (f2 (? #'stringp y)))

Matches only a struct whose field f1 is a number, and whose field f2 is a string. When that is true, x and y are bound.

Extending Shadchen

The pattern matcher is user extensible using defpattern. Defpattern defines a function which receives the pattern's arguments, and returns a new pattern which effects the desired match. For instance, the struct pattern is defined thusly:

(defun cl-struct-prepend (s)
  (intern (format "cl-struct-%s" s)))

(defun make-cl-struct-accessor (struct-name slot) 
  (intern (format "%s-%s" struct-name slot)))


(defpattern struct (struct-name &rest fields)
  `(and
    (? #'vectorp)
    (? #'(lambda (x) (> (length x) 0)))
    (? #'(lambda (o)
           (eq (elt o 0) ',(cl-struct-prepend struct-name))))
    ,@(loop for f in fields collect
            `(funcall 
              #',(make-cl-struct-accessor struct-name (car f))
              ,(cadr f)))))

Note that the defpattern body must return a valid pattern in terms of previously defined patterns (or itself, patterns can be recursive). In this case we use the patterns and, ?, and funcall to create a new matcher.

Supported Patterns:

Shadchen supports the following patterns:

Shadchen supports the following built-in patterns.

<SYMBOL>

Matches anything, binding to that value in the body expressions.

<KEYwORD-LITERAL>

Matches only when the value is the same keyword.

<NUMBER-LITERAL>

Matches only when the value is the same number.

<STRING-LITERAL>

Matches only when the value is string= is the same string.

(CONS <PATTERN1> <PATTERN2>)

Matches any CONS cell, or NIL, then matches <PATTERN1> and <PATTERN2>, executing the body in a context where their matches are bound. If the match value is NIL, then each PATTERN matches against NIL.

(LIST <P1> ... <PN>)

Matches a list of length N, then matches each pattern <PN> to the elements of that list.

(LIST-REST <P1> ... <PN> <REST-PATTERN)

Matches - to elements in at list, as in the LIST pattern. The final <REST-PATTERN> is matched against the rest of the list.

(QUOTE DATUM)

Only succeeds when DATUM is EQUALP to the match-value. Binds no values.

 (AND <P1> .. <PN>)

Tests all <PN> against the same value, succeeding only when all patterns match, and binding all variables in all patterns.

 (? PREDICATE <PATTERN>)

Succeeds when (FUNCALL PREDICATE MATCH-VALUE) is true and when <PATTERN> matches the value. Body has the bindings of <PATTERN>.

 (FUNCALL FUN <PATTERN>)

Applies FUN to the match value, then matches <PATTERN> against the result.

 (BQ EXPR)

Matches as if by BACKQUOTE. If EXPR is an atom, then this is equivalent to QUOTE. If EXPR is a list, each element is matches as in QUOTE, unless it is an (UQ <PATTERN>) form, in which case it is matched as a pattern. Eg:

(match (list 1 2 3)
  ((BQ (1 (UQ x) 2)) x))

Will succeed, binding X to 2.

(match (list 10 2 20)
   ((BQ (1 (UQ x) 2)) x))

Will fail, since 10 and 1 don't match.

(values <P1> ... <PN>)

Will match multiple values produced by a (values ...) form.

(struct struct-name (field-name <P1>)
                    (field-name <P2>)
                    ...
                    (field-name <P3>))

Which matches when the input is a struct of type struct-name, whose fields match <P1> ... <PN>.

Conclusions

If you are an elisp hacker like me, now you don't have to envy those snooty Racket, ML and Haskell programmers. Happy Hacking!

(PS - the library is also available in Common Lisp, check my github).

(PPS - I love Racket, ML and Haskell programmers and they aren't at all snooty.

sachachua: Emacs: Telling external processes about terminal capabilities, and watching over other people’s shoulders

2012-01-19T03:06:03+00:00

Justin Giancola (@elucid) wanted to use full-ack.el to search through his project files using the Ack tool, but Ack refused to run because it didn’t think his terminal had enough capabilities. A simple fix was to set the TERM variable with

(setenv "TERM" "xterm")

which told Ack that Emacs was fine with its output.

(Speaking of Ack integration – This being the Emacs world, there’s more than one way to do things. You might also want to check out ack-and-a-half.el, which is midway between ack.el and full-ack.el.)

It was interesting hanging out with someone else who used Emacs, and being able to share tips. I don’t run into many other Emacs geeks, but I sporadically hang out in the #emacs channel or browse Planet Emacsen to be inspired. It’s funny how many of the meetups I go to end up involving Emacs conversations. It’s like I have a big M-x banner hovering over my head. =) It’s awesome, actually!

Read the original or check out the comments on: Emacs: Telling external processes about terminal capabilities, and watching over other people’s shoulders (Sacha Chua's blog)

John Sullivan: Sent to the ACLU today

2012-01-18T20:51:29+00:00

I was on the brink of mindlessly clicking through the ACLU action center as usual to send an email opposing SOPA. But then I read their boilerplate text, and ended up cancelling the letter to my rep and instead sending this quick note to the ACLU:

Your SOPA suggested letter text supports current copyright law, and also backhandedly supports PIPA (the Senate version of the bill).

This is far too weak of a position. As a donor, I ask you to take a stronger position that current copyright law unjustly restricts free speech, and that no further enforcement measures should be instituted until that fundamental problem is addressed.

At least take on BOTH of these bills strongly. Most of the significant Internet is blacked out today to oppose both bills -- why would you cede so much ground to copyright maximalists? We have the support to oppose and defeat both bills.

For reference, here was their text:

While I believe it's important to protect copyrighted material online, the language of the Stop Online Piracy Act (SOPA) is flawed and will lead to the blocking of lawful content.

Unlike the Senate version of the bill, SOPA eliminates the concept of sites 'dedicated to infringing activity' and enables law enforcement to target all sites that contain some infringing content -- no matter how trivial. The potential for impact on non-infringing content is much greater under SOPA than under other versions of this bill. Sites with user-generated content, like YouTube, Twitter, and Facebook, would be especially vulnerable, as one small piece of infringing content could lead to blocking the entire site.

Even though proposed changes would narrow the amount of lawful content impacted, the changes don't go far enough. It is still likely that search engines will end up blocking access to perfectly legal online content.

Congress should focus not just on the goal of protecting copyright owners, but also protecting the speech rights of consumers and providers who are reading and producing wholly non-infringing content. Congress must eliminate the collateral damage to protected non-infringing content. Only in that way will Congress truly achieve its goal of protecting authors while respecting the constitutional right to free speech.

Maybe I'm overreacting, but I dislike it when good organizations take weak positions unnecessarily. Usually this is not a problem with the ACLU, for me. It doesn't help that I keep seeing this meme everywhere in the anti-SOPA/PIPA conversation: "I agree we need to do something about piracy, but not this..."

I don't think we need to do anything to fix violations of an extraordinarily unjust law until the law itself is fixed. I don't find that to be a very radical position.

Robert Adesam: Issue with VM and IMAP over SSL/stunnel

2012-01-18T13:49:53+00:00

Problem -- after migrating from Mac to Mac @work I could no longer get emails via imap over ssl/stunnel, using VM 8.1.1 on Emacs 23.3 and stunnel 4.35 with openssl 1.0.0d. The *Messages* buffer stated
vm-imap-protocol-error: IMAP protocol error: "unexpected char (10)"
and the trace buffer of the IMAP over SSL session showed no errors.

With help from my friend, and some ssl/stunnel debugging, I quickly found the problem in the stunnel program, so I set out to revert to the version working on my old Mac, version 4.23. Finding instructions on the Macports wiki page on how to install older ports with subversion, I did

jump over the part on installing subversion as a fairly new version comes with Mac OS X 10.6.7,
locate and check out the revision, 36499, from the Macports repository containing the old version of stunnel,
$ svn co -r 36499 https://svn.macports.org/repository/macports/trunk/dports/security/stunnel
install it with the port command.
$ cd stunnel $ port install

Problem solved! Now I can once again get emails to VM using IMAP over SSL, stunnel 4.23 with openssl 1.0.0d.

There are quite a few tips on how to test a ssl connection, so I will leave it out and show how I debugged stunnel by

creating a stunnel.conf file with
debug = 7
output = stunnel.log
to be appended to the VM generated config file,
setting vm-stunnel-program-additional-configuration-file in the VM init file, ~/.vm, to point to to stunnel.conf file, eg
(setq vm-stunnel-program-additional-configuration-file "/PATH/TO/STUNNEL.CONF")
and reloading the VM init file.

Fetching emails now created stunnel.log in the mail folder. This file showed the error
LOG5[3793:140735082364064]: Error detected on socket (read) file descriptor: Socket operation on non-socket (38)
which I could find almost no information about, even less a solution to, so the quick fix was to revert back to an old working version of stunnel as described above.

Update: Since I wrote, but not published, the above text I found out in the stunnel changelog that some Mac OS X bugs have been fixed. Downloaded the latest version, 4.37, and compiled it without any hickups. Though, when now running stunnel it segfaults in addition to the stunnel socket error above...
Update: The above error has been fixed in version 4.52 of stunnel, excellent work from Michał Trojnara!

Alex Schroeder: SOPA Blackout Protest

2012-01-17T09:53:39+00:00

I just saw Twitter CEO says SOPA blackout protest "silly" on BoingBoing. I wonder: Should I shut down Emacs Wiki for US residents? I’d have to do a quick geo location of the IP numbers before serving anything. That sucks.

kensanata: Do US #Emacs users require a reminder to fight #SOPA and # PIPA? I think Emacswiki will stay up for the USA. I doubt US Congress uses it.

I always felt that I was as safe as I can be running Emacs Wiki: I live in Switzerland, the server is hosted in Germany, the domain name registrar is French, the top-level .org domain is the only thing connecting it to the USA. But then I read US Can Extradite UK Student For Copyright Infringement, Despite Site Being Legal In The UK – and now I wonder about the worst case. Perhaps I should get myself a different domain name.

Actually, I think the main problem is that with all the scare mongering around copyright infringement and the astronomical punishments dealt out in the US, I have lost my confidence in their judicial system when it comes to copyright and patents. The most positive explanation for that is that I’m just misinterpreting all the bad news I’m reading online. My impression is formed by following @internetlaw, @privacylaw, @techdirt and @boingboing, following the occasional link. I end up reading Actual damages for single unauthorized download of software program held to be cost of single license fee (from $1,370,590 down to $4,200) and I wonder how much it cost the accused in time, energy and money to get this result. I would not want to fight this battle in court, even if I win.

Case in point: How USPTO's recklessness destroys business, innovation, and competition – a company produces something and years later a competitor is awarded a patent. The cost of going to court is prohibitive, and so they just give up.

Overprotective copyright and a judicial system that encourages statutory damages, patent offices unable to cope with new technology, a highly networked world making it easy to publish internationally with incompatible legal systems. It makes my head hurt!

Update: I decided to post a more personal message on EmacsWiki:2012-01-18.

Tags: Emacs Web USA SOPA Copyright Patents

Mickey Petersen: PComplete: Context-Sensitive Completion in Emacs

2012-01-16T18:40:01+00:00

In my What’s New In Emacs 24 series (part one, part two) I briefly mentioned that pcomplete, the programmable completion library featured prominently in Eshell, now supports M-x shell out of the box. That’s great news for shell mode fans as the completion mechanism adds a lot of nifty functionality to a mode that lacks the native completion provided by underlying the shell itself.

The most amazing thing about the completion mechanism is that it has been in Emacs for ages but never made much of a public appearance and has gone virtually unnoticed due to its limited use in Emacs. In fact, I think it’s only used in EShell, ERC, Org Mode and now, finally, Shell Mode.

Programmable, Context-Sensitive Completion

To use pcomplete you won’t have to do anything, because as of Emacs 24 it is now supported automatically when you launch a new shell session. Emacs ships with a handful of pcomplete functions that enhance the otherwise drab filename completion with context-sensitive completion similar to what you can do with bash/zsh completion. Of particular note is the scp, ssh, mount, umount and make support.

The following table lists the commands supported by shell mode (or indeed any mode that supports pcomplete, including Eshell.)

Command	Notes
bzip2	Completes arguments and lists only bzipped files.
cd	Completes directories.
chgrp	Completes list of known groups on the system.
chown	Completes user and group perms, but only if you use `user.group`.
cvs	Completes commands and parameter options and cvs entries and modules.
gdb	Completes only directories or files with eXecute permission.
gzip	Completes arguments and lists only gzipped files.
kill	Lists signals if completed with just a `-`, otherwise it completes all system PIDs.
make	Completes arguments and valid makefiles in the directory; if a valid makefile is completed with `make -f FILE` a list of rule names from the file itself are completed.
mount	Completes arguments and valid filesystem types if completed with `mount -t TYPE`.
pushd	Identical to `cd`.
rm	Completes arguments and filenames and directories.
rmdir	Completes directories.
rpm	Very sophisticated completion mechanism for most of rpm, the Redhat Package Manager. Context-sensitive completion for almost all commands, including package lookup.
scp	Completes arguments, SSH known hosts and remote file lookup (using TRAMP) if the format is `scp host:/`.
ssh	Completes arguments and SSH known hosts.
tar	Completes arguments, including context-sensitive completion for POSIX arguments, and file name completion.
time	Completes directories and files with eXecutable permission.
umount	Completes arguments, mounted directories and filesystem types (like `mount`)
which	Supposed to provide simple filename completion of all known binaries (wouldn’t be useful otherwise!) but appears to not work right.
xargs	Completes directories and files with eXecutable permission.

Custom Completion

It goes without saying that a completion library called programmable completion is, well, programmable.

Adding simple parameter completion is an easy job but anything more than that and it gets hairy as, not surprisingly, this library is virtually undocumented (though an optimist would say the source is all the documentation you need…)

I’ll demonstrate how to add rudimentary support for git.

The first thing we need to do is establish the order in which parameters must be given; for git, it’s somewhat consistent: git [options] <command> [<args>]

For now I’ll stick to the commands as that’s what people use the most anyway. The commands, in list form, are:

(defconst pcmpl-git-commands
  '("add" "bisect" "branch" "checkout" "clone"
    "commit" "diff" "fetch" "grep"
    "init" "log" "merge" "mv" "pull" "push" "rebase"
    "reset" "rm" "show" "status" "tag" )
  "List of `git' commands")

The syntax for pcomplete is rather clever: it will use dynamic dispatch to resolve the elisp function provided it is named a certain way. All commands are named pcomplete/COMMAND or pcomplete/MAJOR-MODE/COMMAND. Provided you follow that naming scheme your command will automagically work.

Next, we need to present a list of valid commands — in this case the ones in pcmpl-git-commands, but it could be any form — to the command pcomplete-here.

(defun pcomplete/git ()
  "Completion for `git'"
  (pcomplete-here* pcmpl-git-commands))

Now when you try to tab-complete the first argument to git it will list our commands. Sweet.

Let’s extend it further by adding support for the add and rm commands. I want the aforementioned commands to provide the standard filename/filepath completion if, and only if, the command is add or rm.

This is surprisingly easy to do using pcomplete-match, a function that asserts a certain regexp matches a particular function argument index. Note that the call to pcomplete-here is in a while loop; this is so you can complete as many files as you like, one after another. One advantage of pcomplete-here is that it won’t display files you have already completed earlier in the argument trail — that’s very useful for a command like add.

(defun pcomplete/git ()
  "Completion for `git'"
  ;; Completion for the command argument.
  (pcomplete-here* pcmpl-git-commands)
 
  ;; complete files/dirs forever if the command is `add' or `rm'.
  (if (pcomplete-match (regexp-opt '("add" "rm")) 1)
      (while (pcomplete-here (pcomplete-entries)))))

Ok, that was easy. Now let’s make it a bit more dynamic by extending our code to support the git checkout command so it will complete the list of branches available to us locally.

To do this we need a helper function that takes the output of a call to shell-command and maps it to an internal elisp list. This is easily done with some quick hackery.

The variable pcmpl-git-ref-list-cmd holds the shell command we want Emacs to run for us. It gets every ref there is and we then filter by sub-type (heads, tags, etc.) later. The function pcmpl-git-get-refs takes one argument, type, which is the ref type to filter by.

(defvar pcmpl-git-ref-list-cmd "git for-each-ref refs/ --format='%(refname)'"
  "The `git' command to run to get a list of refs")
 
(defun pcmpl-git-get-refs (type)
  "Return a list of `git' refs filtered by TYPE"
  (with-temp-buffer
    (insert (shell-command-to-string pcmpl-git-ref-list-cmd))
    (goto-char (point-min))
    (let ((ref-list))
      (while (re-search-forward (concat "^refs/" type "/\\(.+\\)$") nil t)
        (add-to-list 'ref-list (match-string 1)))
      ref-list)))

And finally, we put it all together. To keep the code clean I’ve switched to using a cond form for readability.

(defconst pcmpl-git-commands
  '("add" "bisect" "branch" "checkout" "clone"
    "commit" "diff" "fetch" "grep"
    "init" "log" "merge" "mv" "pull" "push" "rebase"
    "reset" "rm" "show" "status" "tag" )
  "List of `git' commands")
 
(defvar pcmpl-git-ref-list-cmd "git for-each-ref refs/ --format='%(refname)'"
  "The `git' command to run to get a list of refs")
 
(defun pcmpl-git-get-refs (type)
  "Return a list of `git' refs filtered by TYPE"
  (with-temp-buffer
    (insert (shell-command-to-string pcmpl-git-ref-list-cmd))
    (goto-char (point-min))
    (let ((ref-list))
      (while (re-search-forward (concat "^refs/" type "/\\(.+\\)$") nil t)
        (add-to-list 'ref-list (match-string 1)))
      ref-list)))
 
(defun pcomplete/git ()
  "Completion for `git'"
  ;; Completion for the command argument.
  (pcomplete-here* pcmpl-git-commands)  
  ;; complete files/dirs forever if the command is `add' or `rm'
  (cond
   ((pcomplete-match (regexp-opt '("add" "rm")) 1)
    (while (pcomplete-here (pcomplete-entries))))
   ;; provide branch completion for the command `checkout'.
   ((pcomplete-match "checkout" 1)
    (pcomplete-here* (pcmpl-git-get-refs "heads")))))

And that’s that. A simple completion mechanism for git. Put this in your .emacs or init file and you’re done.

Bryan Murdock: What Is So Wrong With Mercurial's Named Branches?

2012-01-16T18:10:49+00:00

I just installed the very latest version of mercurial, 2.0.2. It added a new little feature that warns you when you create a branch. Huh? This is what it looks like:

$ hg branch foo
marked working directory as branch foo
(branches are permanent and global, did you want a bookmark?)

Really? Have we let the git advocates push us this far? Do we really need to start discouraging named branches?

I googled around to see if I could find where the self-hate for mercurial's named branches is coming from and I found things like this, "it is almost never a good idea to use this facility for short-term branching, since branches created this way are inherently 'eternal'." (those quotes around eternal are good, actually, but you didn't explain why they should be there), and this, "you can never really delete branches (since that would mean altering older commits)." (editing history, oh noes!), and others like this. And these were all written by apparent mercurial supporters! I understand when a git developer writes misinformation about mercurial and uses it to try and make git look better (that's only human), but we mercurial users should know not to listen to it!

Here's what I think is going wrong. Git users love flexibility. The love it so much that they even include modifying their local repository history right into their standard workflow. git rebase is a core command. From what I can gather, even though mercurial now (as of years ago, actually) has powerful rebase and patch queue extensions, mercurial users still get the heebie-jeebies when they think about modifying repository history. This is where the git envy comes from. You see, git useres can alter their branch names, or even delete branch names without using scary rebase. Fact is, though, git could adopt mercurial-style named branches and git users would rebase them away or rename them with rebase willy-nilly just like they do with everything else that they deem needs editing in their history. The fact that git users can rename or delete their branches without using rebase is almost completely incidental. If you allow the use of rebase or patch queues, mercurial named branches are not any more permanent than any other changeset in the repository history. Mercurial bookmarks allow mercurial users flexibility around branch names without needing to resort to scary history editing extensions, and that makes us happy, but I don't think that we should talk down mercurial named branches. There are times when you want the branch name associated with a commit to be just as "permanent" as the commit is. Let us do that without dumb warnings that make named branches sound like a bad idea.

The only other argument people may have against mercurial's named branches is the possibility of name collisions. As if that's something that's really hard to deal with. Anyone who has written a fair amount of C code (I'm looking at you, git developers) knows how to prefix a name to get poor-man's namespaces. Alternatively, many projects require an issue tracker number in a feature-branch or bugfix-branch name. Name collision problem solved.

In conclusion, mercurial named branches are fine. Use them more. Use rebase and/or patch queues[1] to rename or delete the branches when necessary. If that really bothers you, you have bookmarks now, but don't go all git-apologetic on named branches. Mercurial is every bit as awesome as git.

1. Before you push to a publicly accesible repository, of course. Ask a git user why that's important.

John Sullivan: At FOSDEM in February

2012-01-15T23:19:00+00:00

I will be helping to represent the FSF at FOSDEM next month in Brussels. I'm speaking in the Legal Issues Devroom on Saturday 2012-02-04. The presentation is called "Is copyleft being framed?":

This short talk will address the following questions, to inspire discussion and contemplation about how we frame descriptions of the state of licensing in free software.

Numbers are increasingly being cited to show that the use of copyleft licenses, specifically the GPL, is declining. What do these numbers actually show, who is propagating them, and why? What do or might other numbers show?

Is the "percentage of free software projects which use copyleft licenses" a useful way to judge the success of copyleft? Does an increase in the percentage of projects using non-copyleft permissive licenses indicate a failure of copyleft?

As a small related case study, what role have the licensing terms of popular mobile application stores played in this debate, and how have those terms changed the frame of the discussion?

Let me know if you'll be there too!

Michael Lockhart: Build and install Emacs24 on Debian squeeze

2012-01-15T12:57:54+00:00

Hacking in Debian is so easy (one of the reasons I switched). Take, for instance, building Emacs. This is such a piece of cake compared to the weird hoops you have to go through to get all the build dependencies on other platforms. It’s something I never tried before, simply because it was too daunting [...]

Alex Bennée: Getting organised

2012-01-13T10:38:21+00:00

What with becoming a parent and getting promoted I suddenly find myself needing to become a lot more organised. Although I’ve been using org-mode for a bit I need to get a lot more organised with it.

Previously I had two sets of org notes. My personal set where sitting on my server which I could access via the terminal. I generally accessed this at home on the odd occasion when I was doing things like the annual round of insurance quote gathering. The second set was a fairly simple time sheet type affair that I was using at work to keep a vague track of where all my time was spent. The big missing part of this is when I’m on the move.

I’ve just recently upgraded my phone to the latest Galaxy Nexus which is a fine Google enabled device. I make no apologies for using Google’s calendering and shared document services. They work very well and importantly allow me to share things with my wife who doesn’t quite share my desire to run everything from a text editor. However for my personal task lists on the move and remembering what’s coming up at work it doesn’t quite cut it. Besides I like org-mode and I’d heard about MobileOrg so I endeavoured to set it up.

MobileOrg has been around some time for the iPhone but the mechanisms it uses for integrating with org-mode are fairly well documented. As a result there is a couple of Android implementations for it. Matthew Jone’s mobileorg-android was the first version I tried.

The original sync method for MobileOrg was to use a service like Dropbox to sync files. Given the history of Dropbox’s security I wasn’t about to move my files into the proprietary cloud. The alternative is to enable WebDAV on my web-server and therefor enable two way communication via HTTP. It was a little concerning to see self-signed SSL wasn’t supported as this does open up a potential attack vector on my machine. I’ve mitigated it a little by using digest authentication instead of basic-auth but I’d still prefer to be conducting these read-write operations over something more secure.

Initial results were a little underwhelming. After some messing around with the format of org-links I eventually got a basic outline summary up. Unfortunately I can’t seem to sync notes created on my phone to the server. This seems to be a Apache problem which I shall have to dig into later.

After perusing the market some more I noticed there is a new project in town. Konstantin’s MobileOrgNG was forked some time ago from Matthew’s code and on installing I found it looked an awful lot better. I’ve still be unable to post any locally added notes (due to previously mentioned Apache config issues). However it’s presentation is a lot slicker and it shows a lot of potential for being a good MobileOrg client.

I’m now stuck with a classic open source fork dilemma. The code bases look to have diverged enough that these two projects are essential going their own way. Looking at the two impact graphs it looks like they diverged around August 2011 and since then MobileOrgNG looks pretty much like a solo effort albeit with an impressive commit rate of new features.

So the questions for my readers. Which code base should I jump on? Has anyone got experience with the two different code bases and the reason they split? Are there any other Android clients for org-mode I should be looking at?