I am unable to reach the administrative panel of Irreal to release today’s blog. Technical support reports that they are undergoing a DOS attack that (somehow) only affects administrative logins.
I’m going to try pushing today’s post again. If you see the post for 2013-04-13, you will know I succeeded. If you don’t see the post, all we can do is wait until the hosting folks resolve the problem.
Sorry for the outage.
jcs
Xah Lee has a couple of nice posts on managing window configurations. One posts deals with having a single (large) frame and dividing it into several windows. The other deals with the opposite case of having several frames with one or two windows in each. I tend to prefer a single large frame (although I sometimes pop up another temporarily) while Lee likes several frames.
No matter, between the two posts he’s got you covered. The posts will be useful mostly for n00bs but he does mention winner-mode and windmove, packages that I only recently became aware of and started using, so there may be something there for you even if you’re an old hand.
Here’s a simple Elisp challenge suggested by a problem from by ProgrammingPraxis. We call one string a cycle of another if one string can be transformed into the other by a rotation of the characters. Note that this means
Thus, “abc” and “cab” are cycles of each other because if “abc” is rotated right by 1 (or left by 2) it equals “cab.” Notice that “abc” and “acb” are not cycles of each other even though they meet conditions 1 and 2.
The challenge is to write an Elisp function, cyclep, that tests whether two strings are cycles of each other.
Arne Babenhauserheide, who you may remember as the “Eminent Babenhauserheide” from Episode 7 of Emacs Rocks!, has a nice post up on Babcore, his version of Bozhidar Batsov’s prelude. If, like me, you enjoy mining other people’s configurations for ideas to improve your own workflow, you will probably find something useful in Babcore. Everyone’s needs and interests are different so rather than list everything that Babcore contains, I’ll let you follow the link and see for yourself.
One of the really nice things about Babenhauserheide’s post is that he wrote it in Org mode so he was able to export it in many different formats. There’s HTML, of course, put he also has a link to a PDF version (for printing) and a version that contains just the Elisp that you can import directly into your .emacs. He also includes the Org source file so that you can see how he did all this. That’s very nice and serves as an excellent go-by for others who want to do something similar. As usual, the power of Org mode continues to astound me.
The indefatigable Sacha Chua volunteered to edit the videos of the recent Emacs Conference and I’ve been looking forward to watching them. The problem was that I haven’t been able to find a list of those ready for viewing. Until now. I stumbled across this play list on the emacs-reddit which has the videos for the talks by
Presumably Chua will add others as she completes them.
This is a tremendous resource for those of us who couldn’t attend in person. We all owe Sacha Chua a huge thank you. Head on over to her blog and say hi and leave a note of thanks. You might also want to check out her sketch notes of the talks.
It’s been a while since we’ve had a EmacsGolf challenge but I just ran across this post from Cameron Saul with the perfect problem for us. Here’s the problem: Saul is writing some Java code that looks like this
TextView textViewRoute = (TextView)convertView.findViewById(R.id.textViewRoute); TextView textViewDirection = (TextView)convertView.findViewById(R.id.textViewDirection); TextView textViewStartStop = (TextView)convertView.findViewById(R.id.textViewStartStop); TextView textViewStartDist = (TextView)convertView.findViewById(R.id.textViewStartDist); TextView textViewStartPrediction = (TextView)convertView.findViewById(R.id.textViewStartPrediction); TextView textViewEndStop = (TextView)convertView.findViewById(R.id.textViewEndStop); TextView textViewEndDist = (TextView)convertView.findViewById(R.id.textViewEndDist); TextView textViewEndPrediction = (TextView)convertView.findViewById(R.id.textViewEndPrediction);
Notice that each line is the same except for a single symbol that is repeated twice. Saul says he wouldn’t have to write all this boilerplate if he were writing in a language that didn’t hate fun. My first thought was, “or if you had a decent editor.” So our job is to show Saul how to leverage Emacs to make this a trivial problem. You’ll appreciate the challenge more when you see his solution.
Update: Fuco points out that I didn’t specify a starting buffer. Let’s assume that the buffer is empty to begin with.
James Bennett over at The B-List has an interesting post on editors and why, no matter what you finally decide, you should learn either Vi(m) or Emacs. He begins by noting that every couple of years there is a wave of enthusiasm for the newest greatest editor. In previous years it was TextMate, now it’s Sublime Text. But, he notes, there’s a lot to be said for investing in tools that will grow with you through the years. He makes a couple of points worth considering
All this is especially true of Emacs, I think, because the individual user can adapt it for whatever behavior is needed. If those needs change, it’s simple to adjust the behavior to the reflect current needs. As Bennett says, good tools grow with you.
Bennett’s point is not that you should use Emacs or Vim (although he probably thinks you should) but that you should be aware of the “old,” reliable, and proven editors and what they have to offer. That’s something we can all agree on.
Before coming to Lisp, I spent many many years writing C code. Despite the disrepute that C has fallen into with some of those damn kids playing on my lawn, I think it’s a really great language for the problems in its domain—certainly superior to C++, no matter what they tell you. In any event, if you’re a C (or C++ or other GCC-based language) programmer, one of the handiest debugging tools at your disposal is GDB, the Gnu Debugger.
The problem is that GDB can be a bit intimidating for the uninitiated. Happily, Ryan Schmidt wrote a nice tutorial to get you started. It’s written in a question/answer format and takes you through all the basic operations. After he discusses the commands there are a couple of examples that show you how to actually work with the debugger.
Emacs users will, of course, want to use the Emacs interface to GDB. It’s separate from GUD (the Grand Unified Debugger) and has a nice multi-window IDE-like presentation. For more information, visit the online documentation for it with【Ctrl+h F】 gdb (note the capital F).
Non-Emacs users might want to look at cgdb, a split-screen, terminal-based interface to GDB. I haven’t used it but it looks quite nice from the Web site.
Update: 【Ctrl+x F】 → 【Ctrl+h F】
I learned something new from Magnar Sveen’s excellent Emacs Rocks! episode on Paredit: the paredit-convolute-sexp command (bound to【Meta+?】). It’s hard to describe exactly what it does so check out the video to see it in action. The thing is, I didn’t even know that command existed; it wasn’t on my Paredit Reference Card. I noticed some of the other commands were missing too so I decided to find out exactly what commands were available and make a list of them.
I brought up the paredit.el file and started looking around and noticed there’s an odd list of commands complete with examples built right into the code. Here’s the first few entries:
(progn (setq paredit-commands `( "Basic Insertion Commands" ("(" paredit-open-round ("(a b |c d)" "(a b (|) c d)") ("(foo \"bar |baz\" quux)" "(foo \"bar (|baz\" quux)")) (")" paredit-close-round ("(a b |c )" "(a b c)|") ("; Hello,| world!" "; Hello,)| world!")) ("M-)" paredit-close-round-and-newline ("(defun f (x| ))" "(defun f (x)\n |)") ("; (Foo.|" "; (Foo.)|")) ...)))
I thought, “This is perfect. I can use this list to programmatically build a reference card and it will always be up to date.” So I started mapping out the Lisp code in my head but then I remembered this is Emacs so I thought I better check the code to make sure it wasn’t already doing something like that. Sure enough, there’s a function called paredit-insert-html-examples that will format a nice HTML reference card for you. What I did was open an empty file called paredit.html and then call paredit-insert-html-examples. Next I saved the file and then opened it with my browser and set a bookmark to it in my Docs section. Now I have a nicely formatted reference card complete with examples and I know it’s correct because it’s generated from the actual code in the package.
You may have seen a version of this reference card on the Internet. It’s not this one, which is nicer looking but not complete. Here’s a older version of what gets generated. If you’re new to paredit or the type of person who doesn’t remember key sequences unless you use them all the time, this may be just what you need and it’s easy to generate when new versions of paredit come around.
The careful Irreal reader will have noticed the quote from Iain M. Banks in the upper right corner of the blog. The quote comes from Excession, my favorite of Banks’ Culture Novels. It’s a description of metamathics, which Banks describes as
the investigation of the properties of Realities (more correctly,
Reality-fields) intrinsically unknowable by and from our own, but whose
general principles could be hazarded at.
The investigation of metamathics is how the Minds—the powerful AIs that effectively run the Culture—amuse themselves. It’s inclusion here is meant to suggest a parallel with Lisp.
Now, sadly, we learn that Banks has terminal cancer and does not expect to live longer than a year. If, like me, you’ve read and enjoyed Banks’ novels you might want to visit Banksophilia, a site set up by his family and friends, where you can check his progress and leave him a message if you like. The Culture is a wonderful place full of hope and progress where something like this could never happen. It’s heartbreaking to see it happen to the Culture’s creator.