Emacs Calendar Extension – Information Unity (Part 3)


Ok, this post should wrap up the series – finally. Sorry it’s taken me a while, but got caught up in life for a bit…

To summarize what we’ve covered so far, I figured out how to get a iCal file imported into Emacs calendaring system, remove duplicates, and do a little post-processing in order to get it looking the way I wanted.

Up to this point, it’s all been manual calls with eval-region and that just won’t cut it! We need an Emacsian way of both a) Automatically running this code on start up (which the provided functions can already handle, and b) Being able to manually re-execute at any time via Emacsian means.

The running on start up, as I’ve said, is already handled via normal elisp code execution. We really just need to enable that same functionality through manual Emacs interaction.

Looking through documentation and many blog posts I discovered how to interact with the Emacs system – and it’s actually pretty simple. You only have to do a couple of things, actually:

  1. defun a standard lisp method.
  2. Include the interactive form (of which there are varying arguments it takes based on the required functionality.
  3. From within this form make calls out to the forms that we already created for importing an iCal

Read more

Tags: , , ,

Emacs Calendar Extension – Information Unity (Part 2)


Go back to the first post in this series, I was trying to solve the problem of having many views of my calendars, but only a single source of record. Specifically, I wanted to be able to view this “source” calendar in Emacs without the manual syncing process.

As was discussed earlier, a few of the issues were solved:

  1. Google Calendar exports calendars in the iCalendar format
  2. Emacs Calendar is able to import an iCalendar format file via URL

Stellar! This is going to be easy! I’ll just list out my calendars’ iCalendar URLs (provided by Google), and have Emacs Calendar cycle through them and import them. Nice 🙂

First, let’s create a var that points to our diary file (that way we can export it to our site config if necessary)

(setq diary-file (concat my-emacs-org "diary_entries"))

Next, I’ll create an alist  to hold all my calendars.

(setq my-ical-calendars-alist '(
 ("test", "https://www.google.com/calendar/icaltest.ics")

All nice and easy thus far. The next thing we need to do is write a nifty function to help import the URL as icalender.el can only import from a file via icalendar-import-file.

No problem, as there’s a built-in function to download a URL to a local temp copy – url-file-local-copy.

We’ll write our function to:

  1. Download the URL
  2. Pass the temp file to icalendar-import-file
  3. Close the buffer
(defun import-remote-ical (url my-diary-file)
 "Download ics file from URL and add to diary"
 (let ((tmpfile (url-file-local-copy url)))
 (icalendar-import-file tmpfile my-diary-file nil)
 (kill-buffer (car (last (split-string tmpfile "/"))))

I run it and am astounded that it works! So I run it a few more times to make sure I’m not imagining things. Yup – it does work!

I hurriedly open my diary file, anxious to see my handiwork and… (wait for it) … uggh. There are multiple duplicates for each event. I should’ve known that it couldn’t of been that easy.

Read more

Tags: , , ,

Emacs Dired “Shortcuts”


I’m always trying to make my development workflow more efficient – whether it be tools or process – and this post solved one of my recent pain points – as well as giving me another practical problem to solve with Lisp.

As I noted previously, I’m really heavy into Emacs use at the moment: development, calendaring, RSS, news, Jabber IM – all from within this awesome thing called Emacs.

As I started to use it more and more for all types of different chores – and more specific to this post – file editing, I began to notice fairly quickly that directory navigation with Dired (Ctrl-X d, by default) led to far too many keystrokes to get to disparate locations – and to boot there was no notion of persistent “favorites” or “shortcuts”.

The above may just be my newness to the Emacs ecosystem and the functionality may actually exist – but it never turned up in my many searches. So I went about providing my own solution.

NOTE: This effort had no intention of making handy-dandy menu items as I don’t like them – or the mouse for that matter – all that much. Maybe I’ll add that at some point for thoroughness sake – we’ll see.

The plan was simple:

  1. Create a dictionary of shortcut to locations
  2. Use Emacs interactive ability to select a shortcut name and open its location with Dired.

Read more

Tags: , , ,

Emacs Calendar Extension – Information Unity


Well, I’ve been away for a while. Honestly, I find it hard to make time to post – but I swear, I’m going to make more of an effort because I’m actually working on some very exciting stuff.

I’ll put off the super exciting stuff for a bit, but did want to post something exciting – to me at least…

As a preface, I’ve been getting into pretty heavy use of Emacs over the last few months. To the extent that I’m on a mission to use it for as a replacement for as many apps as possible. If you are aware of Emacs and the multitudes of extensions then you know just how powerful it can be. To the point that my desires of an Emacs-only desktop are not outside the realm of possibility – but I’ll get into that in some later posts.

So one of the things I hate in life is repeating myself – specifically in the realm of information. Having to put to-do items into multiple devices, multiple contacts apps, multiple calendar apps, etc.

Read more

Tags: , , ,

Great Article On Testibility and Class Design, Part II


This is a follow up to the previous article that I posted on class design – good read!

As an aside, and one of the few things that I disagree with in either of the articles, is the wrapping of collection classes within separate classes solely for encapsulation. As much as I like single use classes, I just don’t think that encapsulating a collection in it’s own class just for access control is necessary. There are other means of achieving this. If this happens to be a concern then more is going on with the collection than probably should be.

Making Large Classes Small
(In 5 Not-So-Easy Steps)

In my previous editorial, I discussed the benefits and other effects on code bases of using small classes, which I defined using a limit of 50-60 lines. I received many letters on this article, most analogizing it to edicts of olden times to keep functions short enough to fit on one pane of glass. (The letters will appear in the upcoming issue of Dr. Dobb’s Journal, our PDF magazine, which ships on June 19.)
Much as I appreciate those letters, they miss a crucial point. I was not discussing a single function, but rather an entire class, which implies multiple functions in most cases. Coding classes as diminutive as 60 lines struck other correspondents as simply too much of a constraint and not worth the effort.
But it’s precisely the discipline that this number of lines imposes that creates the very clarity that’s so desirable in the resulting code. The belief expressed in other letters that this discipline could not be consistently maintained suggests that the standard techniques for keeping classes small are not as widely known as I would have expected. (Given that the original editorial was inspired by an extended effort to clean up a project that contains much of my own code, I say this with all due humility.)
Let’s go over the principal techniques. I presume in this discussion that design has been done and it’s now just a matter of writing the code. Or in the less attractive case, of maintaining code.
Diminish the workload. The first technique to apply is the single responsibility principle (SRP), which states that classes should do only one thing. How big that one thing is will determine in large part how big your classes are going to be. Reduce the work of each class; then, use other classes to marshal these smaller classes correctly.
Avoid primitive obsession. This obsession refers to the temptation to use collections in their raw form. This is definitely a code smell. If you have a linked list of objects, that linked list should be in its own class, with a descriptive name. Expose only the methods that the other classes need. This prevents other classes from performing operations without your knowledge on an object they don’t own. The purpose of the list is also supremely clear and this encapsulation enables you to change easily to a different data structure if the need should arise later on.
Reduce the number of class and instance variables. A profusion of instance variables is a code smell. It strongly suggests that the class is doing more than one thing. It also makes it very difficult for subsequent developers to figure out what the class does. Very often, some subset of the variables form a natural grouping. Group them into a new class. And move the operations that manipulate them directly into that class.
Subclass special-case logic. If you have a class that includes rarely used logic, determine whether that logic can be moved to a subclass or even to another class entirely. The classic example of the benefits of object orientation is polymorphism. Use it to handle special variants.
Don’t repeat yourself (DRY). This suggestion appears pointlessly obvious. However, even coders who are attentive to this rule will repeat code in two methods that differ only in a single detail. In addition, they can overlook the introduction of duplicate code during maintenance. More than the other guidelines here, which are all techniques, DRY is a discipline within a discipline.
Taken together, these tools get you most of the way to small classes. To see how they are implemented in real life, I suggest a book I’ve mentioned many times before, namely Martin Fowler’s Refactoring, which is essentially a cookbook of techniques for cleaning up code, including the step-by-step process, and the illustrative code.
Returning back to my own experience, I am finding that as I insist on this particular discipline in my code rework, my brain is slowly developing a “muscle memory” and is beginning to think automatically about class size prior to class development — and certainly during the cleanup of existing code. Cheers!
— Andrew Binstock
Editor in Chief
Twitter: platypusguy

Tags: , ,