My Solution to the Changing Times Challenge

Last week, I posted an EmacsGolf challenge on changing times to 24-hour notation. Most of the solutions were much like mine: they used query-replace-regexp with a complicated regular expression and an even more complex replacement expression. One trick that most responders missed was using \#n to get the nth subexpression as a number. That avoids needing to call string-to-int or something similar.

That said, my solution was to call query-replace-regexp with

\([0-9][0-9]?!\):\([0-9][0-9]!\)\([ap]!\)

as the regular expression to search for and

\,(format "%02d:%s" (if (equal \3 "p") (+ \#1 12) \#1) \2)

as the replacement expression.

David Ongaro had a really great (and surprising) solution leveraging the date handling functions of Emacs Calc. It’s nice because it avoids the horrendous regular expression that the rest of us used and simplified the replacement. Very clever.

Posted in General | Tagged | 3 Comments

Happy Birthday!

Posted in General | Tagged | Leave a comment

Names

Yesterday, I wrote about name spaces in Emacs Lisp and mentioned Artur Malabarba’s names package. In a nice example of serendipity, Malabarba has just published a post that explains what the names package is all about1.

The basic idea is that you wrap your Elisp package in a define-namespace macro and write your code as if you were in a private name space. That is, you needn’t worry about adding the package name to every symbol that might be seen externally. This is pretty much what I was describing in footnote 3: internally all symbols are specified and accessed without worrying about the package name. Externally, the package name must be prepended to access those symbols.

The nice thing about the package is that it has no impact on existing code. Everything still works as before. When you’re writing new code you can choose to use define-namespace and dispense with worrying about adding the package name to all of your variables and functions. The define-namespace macro will take care of doing that for you.

You might think this could be risky—think about how you would write that macro—but Malabarba has already used it in two packages that he’s released to ELPA. When you read his post you will see that he’s considered the edge cases.

This package is really an accomplishment. Head on over and see if you don’t agree. It may even help put the eternal fretting about Emacs name spaces to rest.

Footnotes:

1

We don’t coordinate these things. Really.

Posted in Programming | Tagged , | Leave a comment

Name Spaces in Emacs Lisp

Whenever Emacs Hackers come together to discuss what the most urgently needed enhancements to Emacs are, some sort of module system is always mentioned. In terms of Common Lisp, the idea is to add a (Common Lisp) package system to Elisp1.

It seems like a no-brainer. The current system seems to be a mess where we’re forced to add the module name to each package symbol2 so they don’t leak into other modules. It’s something that I never really questioned until I read RMS’s explanation for why Elisp doesn’t implement name spaces.

RMS takes a lesson from his efforts in implementing the Common Lisp package system back in the 1980’s. He says that although the idea sounds nice, it doesn’t really do what you need it to do: you almost always have to add the module name to each exported symbol anyway so the extra complexity in the language isn’t worth it. He decided that for Emacs you might as well just add the package name to the symbol and do away with all the name space machinery.

When I first read that, I thought it was obviously wrong. On further reflection, I think that RMS had it right. Suppose you have two Emacs packages that implement an insert-results function. If you want to call insert-results, you clearly you have to specify which function to use; you have to specify the package name. But how do you know whether there’s another package that exports the same function name? Maybe you’re not loading it today but will tomorrow or the next day. Just to be sure, you better specify the package name every time.

See what happens? You can either specify some-package:insert-results or some-package-insert-results. It’s the same amount of work for the user either way but in one case the package writer has to deal with the name space machinery. Yes, name spaces do protect internal variables and functions but maybe Malabarba’s names package is good enough for that.

Of course there are many intermediate modules systems that might fit well3, but it’s clear to me that the Common Lisp package system is not what we need. What do you think?

Footnotes:

1

The Common Lisp package system implements name spaces. This is different from the Emacs package system, which deals with obtaining and loading 3rd party packages.

2

Although Artur Malabarba’s names package can help here.

3

Maybe that within a package source file all the symbols are accessible without the package name, but externally the package name has to be specified.

Posted in Programming | Tagged | 8 Comments

Debugging With yasnippet

Bin Chen has an excellent post on adding debug statements into source code using yasnippet. Us old timers are used to adding printf statements into our code to create an audit trail of the execution. There are, of course, modern tools that obviate the need for these statements but sometimes they’re just what you need to do a quick check. The nice thing is that the strategy works with any language.

Chen’s idea is to leverage yasnippet to insert the debug statements with as little effort as possible. His post uses javascript as the example language but, as he remarks, the same idea works for any language. It’s easy to underestimate how flexible yasnippet can be. The examples that Chen gives shows how it can extract a lot of information from the source code. This makes it possible to insert an entire debugging statement with a minimum of input. See Chen’s post for examples of this.

Even if you’re not interested in debugging, Chen’s post will give you some ideas about using yasnippet in non-trivial ways. I highly recommend his post.

Posted in Programming | Tagged | 1 Comment

Sacha Chats with Karl Voit

Sacha Chua has a new Emacs Chat up. This time it’s with Karl Voit. It’s a really interesting chat. Voit is concerned with managing personal information and uses Org Mode and some custom scripts to do that.

One set of scripts, Memacs, captures information from his email, SMS, RSS-feeds, blog posts, bank statements, and VCS commits and exports them into Org format so that they can be included in his Org files. The result is a sort of diary of that records all his appointments, phone calls, text messages, tweets, work product, and other noteworthy events that happened on any given date. That makes it easy to ask easy questions such as, “What was I doing on June 2, 2009?” as well as more difficult questions such as, “Who called me on the day I met my girl friend?” and the like. Org mode makes queries like these easy even if you don’t remember the date you met your girl friend.

Voit also describes his home-grown blogging system, lazyblorg. A nice feature of lazyblorg is that he can write a blog post in any Org file and export it to his blog. Thus, if he’s working in the Org file associated with one of one of his projects, he can write the post about what’s he doing in situ and publish it. If he’s working in some other file and wants to blog about it, he just writes the post and published it. As a result, his blog posts are associated with the files they’re about. Very handy.

Later in the chat, Voit talks about using yasnippet to semi-automate repetitive chores. The example he gives is organizing trips to a local comedy club with like-minded friends. The snippet captures all the details of the outing including the when, where, and who of the act as well as dates he should send initial and reminder emails to his friends.

If you’re interested in organizing your life and capturing the details for later research, you should watch this chat and check out some of Voit’s software.

Posted in General | Tagged | Leave a comment

Emacs Documentation

Eric Raymond (esr) is a hero of mine. He writes great software and has done yeoman work for Emacs, including the just completed conversion of the repository to Git. Recently, he proposed that Emacs abandon info in favor of a Web-based documentation system using asciidoc as the source format.

Esr is a believer in browser-based documentation. A few years ago he made a similar pitch for replacing man pages with Web-documentation. I don’t know how much uptake that effort enjoyed but I, for one, am still happily using man. The reason is simple: when I’m working and need some documentation, the last thing I want to do is change out of my editor to the browser. I want to pop up the documentation in another buffer, read the information I need, and get on with my work. It’s not just an Emacs thing; back then I was still using Vim and its built-in man page reader.

It’s no surprise, then, that I’m not in favor of this latest move either. But even on its own terms, esr’s proposal seems odd. Why get rid of texinfo in favor of asciidoc? If, as he says, texinfo is a barrier to entry for new hackers—something I find unlikely—why use asciidoc instead of the excellent built-in Org Mode? The answer appears to be that esr isn’t very familiar with Org Mode (although he has admitted he should learn more) and fears that it may not be up to producing a manual. Several of the posters pointed out that Org Mode has been used to write books and that it certainly is up to the task even if it hasn’t been used to produce any manuals yet.

Then RMS popped up defending the decision to use asciidoc and saying that he started to read the Org Mode documentation but it didn’t immediately say anything about producing manuals so he stopped reading. Really, all this seems bizarre. Esr and RMS are proposing a major change to how Emacs does documentation but seem unaware of a built in solution.

But that, as I say, is considering the proposal on its own terms. I do not agree that we should abandon info in favor of the Web, Org Mode, or anything else. I find the notion that info and texinfo are scaring away new developers silly and, really, insulting to younger developers. Esr may prefer reading documentation in a browser but many of us do not. Read the thread (warning: it’s long) and you’ll see that most of the commenters agree that the system’s not broken and doesn’t need fixing. Also be sure to check out David Kastrup’s description of what he was able to do with texinfo and info for the LilyPond documentation. It’s very impressive.

The sometimes heated arguments in the thread aside, reasonable people can take either side of the question. What do you think?

UPDATE: LWN has an excellent article on this debate.

Posted in General | Tagged | 9 Comments

Notes for Emacs N00bs

Anthony Tedjamulia has a nice post on What I Wish I’d Known About Emacs. If you’re an experienced Emacser, you won’t find much that you didn’t already know but if you’re just starting with Emacs it’s an excellent orientation. One nice thing is that it explains the terminology that Emacs uses. I remember that I kept getting hung up on “yank” because its meaning was exactly the opposite of the way Vim uses it.

Another point that Tedjamulia makes is that Emacs is not so much an editor as a programming environment. Although Tedjamulia doesn’t say so explicitly, that environment is, in fact, a sort of Lisp Machine environment. He compares it to MS Office, an unsavory comparison to be sure but one not without merit. The idea is that Emacs provides a framework in which you or others can write applications. Notice that those applications don’t necessarily involve editing text. You can play music, chat on IRC, handle your email and many other things all because Emacs provides a framework which makes it easy to implement these things.

The final point that Tedjamulia makes that’s worth mentioning is that Emacs is completely transparent. As he puts it, everything is discoverable. You can easily query the documentation for any function, variable, or key sequence. If that doesn’t answer your question, you can follow the link to the source and see for yourself what a function or variable does. Everything is there for you to learn from or extend.

Tedjamulia’s post is, I think, a valuable resource for those new to Emacs. If you’re just starting out, or want to, give this post a read.

Posted in General | Tagged | Leave a comment

Vertically Aligning Code

Terence Eden has a post in which he argues that code should be vertically aligned. Doing so, he says, improves readability and makes the code easier to understand. As an example, he offers

int robert_age = 32;
int annalouise_age = 25;
int bob_age = 250;
int dorothy_age = 56;

versus

int robert_age     = 32;
int annalouise_age = 25;
int bob_age        = 250;
int dorothy_age    = 56;

as an example of improved readability.

Folks can differ as to whether readability really is improved but the arguments against vertical alignment boil down to

  • It can mess up diffs
  • We don’t have the tools to make it easy

In the comments, Helge mentions that

git diff -w

ignores white space thus solving the first problem. It also has the -b option that ignores white space changes. Even if you aren’t using git, GNU diff also has the -w and -b options that do the same thing.

The second problem is what interested me. I kept thinking, “Just use align-regexp and be done with it.” Most times you don’t even have to highlight the code—Emacs will do the right thing by itself. That’s when I remembered that not everyone uses Emacs. Too bad. Use whatever editor you like but don’t complain we don’t have the right tools to do alignment. We have them; some just choose not to use them.

If you want another view, here it is.

Posted in Programming | Tagged | 1 Comment

N00bris

Jean-Philippe Paradis nails it

Lispers see this all the time with n00b proposals to get rid of those pesky parentheses.

Posted in General | Tagged | Leave a comment