Continue reading ‘On the death of Google Reader’ »]]> You can probably tell the sort of on-line company I keep from the deluge of noise on the social networks regarding Google’s decision to shut down Reader. However we shouldn’t be that surprised. In fact some companies that source content from Reader have anticipated the need to collect content themselves.

I of course will have to make a decision at some point. However I’ll not do it today like a lot of Reader users have. The rush to try out alternatives has over-whelmed some open source based projects who were quietly growing organically. I don’t envy those that have to suddenly gear up their back-end systems because an Internet behemoth gave us 2593 hours notice to sort out a replacement.

I’m mulling over the difference between self-hosting and having someone else do it. I’m not overly worried about going for convenience if I know I can get my data back if I need to. In fact the knowledge that you can theoretically self-host might be enough. To be fair to Google their Data Liberation team made exporting all my Reader data easy.

Before I make a choice I need to decide what my priorities are. Currently I subscribe to 250+ RSS feeds. Obviously I don’t read every single post but I make extensive use of tags to quickly process through stuff I do need to see when I need to see it. Aside from news, blog posts, funny cat pictures I also subscribe to other data feeds like bug trackers, code repositories, and other data sources. I of course want access to all of this data at any point on one of a number of devices. This makes a web hosted solution pretty much a must. There is no point having the data on my desktop when I’m somewhere else. From my point of view I want it to be open source compatible because if the company hosting now decides it no longer wants to I’ll only have to move the data and not break my work-flow.

It would also be very useful if it had a public API so others can interact with the data. I don’t need the solution to be all provided by one company. It’s perfectly fine to have multiple 3rd parties sorting out the Android integration. I might even look to doing something to integrate it with my favourite editor (the name of which even my non-geek readers probably know by now). So far my experiment with moving all of IRC and IM into Emacs seems to be working well and should be a subject of another post.

Are you a Reader user? What are your criteria for it’s eventual replacement? Is RSS just a dying protocol or is the need to aggregate and sift through data becoming more important?

There may well be a much better way of solving this problem around the corner. I certainly am open to persuasion. But don’t take away my current preferred solution until I’m convinced I’m ready to switch

Continue reading ‘Edit with Emacs v1.12 now available’ »]]> Apologies for the extended delay in getting out a new release of Edit with Emacs. Real life has been doing a good job keeping me busy that spare hacking time is in short supply. A number of people have submitted pull requests and I’ve also done a bit of clean-up on the code.

The JavaScript in the extension has had the hacky change tracking code replaced with a modern funky 21st century Mutation Observer implementation. This should solve some of the more obvious performance problems on highly dynamic pages.

I’ve also implemented the iterative save method for edit-server.el. Unfortunately it doesn’t quite work as intended if the edited region uses encoding (e.g. longlines). In theory the buffer you have saved should have it’s contents replaced with the new data from the browser but it just doesn’t seem to work. For now I’ve just ensured the kill-ring has the real data in it so it’s not overly painful to restore formatting. Patches and/or explanations are of course welcome!

So grab it now from webstore. The changes are as follows:

Extension

* Upgraded manifest to version 2 for future releases of Chrome
* Added an “Enable Debug” flag to control logging to console
* Use Mutation Observers to better track changes in dynamic DOMs
* Fake a keypress when updating the textarea
* Bug fix for handling editable DIV elements

edit-server.el

* Now available from the MELPA package archive!
* Beta support for iterative C-x C-s saving (it works but is ugly, see kill-ring)
* Default to using UTF-8 coding for process communication
* Raise existing frame consistently on Mac
* Tweak the portion of the URL used to name buffers

Continue reading ‘Many ways to skin a GNU’ »]]> It’s time for another examination of Emacs LISP and a selection of ways to solve the same problem. In this case it’s the behaviour of the etags-select package. This handy function will present a selection table when it finds multiple definitions of the same tag. This is handy if your global TAGs file contains reference to multiple binaries that might have a common code heritage. It even provides a handy function etags-select-find-tag-at-point which will check point to see if that is a tag. However if point is on a blank line I’d prefer it to just prompt me for a tag name.

First version:

(defun my-naive-find-tag ()
  "Find at point or fall back"
  (interactive)
  (unless (etags-select-find-tag-at-point)
    (etags-select-find-tag)))

Unfortunately this fails rather badly. I naively assumed etags-select-find-tag-at-point would return ‘nil on failure. Instead it bombs out with an error because etags-select-find expects a parameter and when find-tag-default fails it errors out.

Second version:

(defun my-working-find-tag()
  "Find tag and call etags-select-find-tag-at-point if it will work"
  (interactive)
  (if (find-tag-default)
      (etags-select-find-tag-at-point)
    (etags-select-find-tag)))

This works by checking find-tag-default will work before calling etags-select-find-tag-at-point. Of course there is some duplication here because find-tag-default will get called again once I know it will work. Dissatisfied I asked the stackoverflow community for suggestions. The first solution is to simply trap the error case.

Third version:

(defun my-try-except-find-tag()
  "Find at point or fall to etags-select-find-tag on error"
  (interactive)
  (unless (ignore-errors (or (etags-select-find-tag-at-point) 't))
    (etags-select-find-tag)))

This works by utilising deep lisp black magic to stop the error propagating and returning a ‘nil if it does. The (or (etags-select-find-tag-at-point) ‘t) line is to ensure a successful call returns something so we don’t then fall through. Interestingly the comments around subr.el mentions some of the keywords used may be redefined by common lisp.

Forth version:

(defun my-efficent-find-tag()
  "Find tag at point, caching find-tag-default"
  (interactive)
  (let ((ftd (find-tag-default)))
    (flet ((find-tag-default () ftd))
      (if (find-tag-default)
          (etags-select-find-tag-at-point)
        (etags-select-find-tag)))))

While I expected something like ignore-errors to exist this demonstrates the flexibility of dynamic languages like Emacs Lisp. The key is the use of flet to redefine find-tag-default so when it gets executed again inside etags-select-find-tag-at-point it simply returns the cached value.

So as usual with these posts I try to invite feedback. Which of these forms do you prefer? Would you solve the problem another way? Have you just learnt something new about Emacs Lisp?

Continue reading ‘Living la vida ELPA’ »]]> I’ve been running Emacs 24 direct from the version control tree (technically a git mirror, bzr still confuses me) for some time now. As many people have mentioned ELPA is one of the big features that helps de-clutter an Emacs users ~/.emacs.d directory. I thought it might be a useful exercise to discuss which packages I’m now loading from ELPA and which I still track directly.

First and formemost is my my dotemacs collection. Weighing in at around 2700 lines of elisp it’s small by some standards. I’ve toyed with moving my config across to things like the Emacs Starter Kit but I’m not sure if it’s worth the transition pain. There is certainly a lot of cruft in my code but there is also quite a lot of muscle memory now invested in it. I have been trying to modularise it a little more but to be honest most of that was driven by a desire to get autoload working nicely which is no longer much of an issue as my session tends to stay up for weeks at an end.

I’ll gloss over edit-server.el surfice it to say I’d hope your not surprised I keep the development version running given it’s for my extension

After that we have Johnathan Rockway’s eproject. I work with lots of code bases during the day and some sort of sensible project type structure is a must. I’ve tried a number of different solutions and this one stuck as it was fairly lightweight and easy for my smaller lisp brain to extend. I’ve even managed to contribute some changes back. As a result I find tracking the bleeding edge of development useful.

The same reason applies to Stephen Bach’s lusty-emacs. While ido-mode and ibuffer work well for speed nothing matches lusty’s lazy file and buffer matching. It can get a little too much once you start dealing with hundreds of buffers at a time (something midnight-mode is trying to keep on top of). It’s still seeing some activitiy on the repository hence the local checkout.

Finally the biggie but generally unused cedet. There has been some work to make it comparitively easy to run out of a src checkout and as long as it’s included early enough it won’t conflict with the built in cedet shipping with Emacs 23+. I still haven’t really made much use of it although I have managed to get a completion out of it when editing some C. It’s basically sitting there until I can commit enough time to figuring out how to use the beast.

Finally a quick review of the ELPA packages that I’ve got loaded. Obviously there is the latest org-mode which I’m spending an increasing amount of time in. I also have my favourite zenburn-theme for easy on the eyes goodness. The popular GIT interaction mode magit also sits there which I use every day. js2-mode and ssh_config_mode completes the list of modules that I actually use.

I have a number of additional things in there which I don’t actually use at the moment but I plan to try out including nose (for python unit test), jsshell (for JavaScript coding) and another one I see a lot of the wizards using yasnippet but again is awaiting time to play with.

So what ELPA packages have you discovered and what hidden gems to you track directly in your .emacs.d?

Continue reading ‘Edit with Emacs v1.11’ »]]> I haven’t really had much time for hacking at home unless programming my daughters wetware counts. However a few enterprising users have been sending me in some pull requests that fix a few minor bugs that slipped through the extensive pre-release testing I did for v1.10 so I thought it was worth pushing out a bug-fix release:

Extension

* Fixed some breakage to the “edit focused area” feature
* Fixed broken link to embedded edit-server

edit-server.el

* A couple of fixes for Emacs 24 compatibility
* Globalize the minor mode so it persists through major-mode changes

Continue reading ‘Now a Windows user!’ »]]> I’ve finally buckled and now have a Windows laptop. It was mainly forced on me by the need to have some sort of access to the intranet during the large number of meetings I’m now involved in at work. I have to say the experience has been enlightening, especially seeing all the hacky stuff that has to be done to get things working under Windows. For example by default I couldn’t connect to any https (SSL) pages. Luckily I can just hand the laptop back to IT to fix it so I don’t have to scratch my head too much.

I’ve had only sporadic luck getting Emacs up and running on it though. Having been running the tip-of-tree release on my Linux workstation so long going back to Emacs 23 has been a bit of a retrograde step. It doesn’t help there are multiple suggestions for installation. I’ve been trying to get EmacsW32 working but I’ve run into problems on start-up. So far I’ve been unable to fix the issue as the paths Emacs references don’t seem to show up in the system file browser. This seems to be the only avenue by which I can fix the permissions it’s complaining about.

Getting my init file onto the system and in the right place has also proved to be more complex than it should have been (there seems to be two “HOME” directories, one under a Roaming title). The Windows shell has finally gained completion but it’s still a shadow of a decent Unix shell. On the positive side I can already run eshell from within Emacs which provides a nice alternative to the command shell. I’ve yet to get tramp working though but I suspect that’s just a case of getting ssh keys sorted out.

If there are better solutions to getting a decent Emacs set-up on Windows I’m all ears.

Continue reading ‘Switching buffers and Google+’ »]]> 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.

Continue reading ‘Getting organised’ »]]> 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?

Continue reading ‘Edit with Emacs v1.10 released’ »]]> I received a bunch of feedback and patches from my last announcement but I think all the outstanding bugs are now squashed. The edit-server.el has seen some love to make it more idiomatically correct for elisp. The main change is new code to handle editable DIV tags beloved of such sites as Google+ (which you are welcome to follow me on, maybe I should have an elisp circle?).

A big cosmetic change is a brand new settings page which looks less like a web-form from the early 90′s and more like part of Chrome. Alas I can take no credit for this but can thank Frank Kohlhepp’s fancy-settings library. In fact a lot of the credit should go to third party libraries like jQuery and of course the growing list of contributors who have submitted code for merging.

So the final changelog for 1.10 is:

Extension

* Ignore textareas marked as read only
* Don’t tag areas that are not visible
* General clean-up to use jQuery to find elements
* Explicit CSS for edit button to override page settings
* Handle editable DIV blocks (e.g. Google+)
* Optimise the finding of text areas for highly dynamic pages
* Revamp the settings page with “Fancy Settings”

edit-server.el

* Allow customisation of edit-server-default-major-mode
* Allow edit mode to be set by matched URL
* Tweak detection of MacOS X Emacsen
* Change behaviour of C-x C-s to save to kill-ring
* Persist the buffer-local variables beyond mode changes
* Setup keymap within defvar
* Clean-ups to code to be more idiomatic.

Continue reading ‘Call for testing for Edit with Emacs’ »]]> I’ve been doing a bunch of house-keeping on Edit with Emacs recently in preparation for a new release. I can only apologise to those people who have submitted patches and merge requests for my tardiness. I’m afraid Real Life ^tm has been taking precedence.

As regular readers of the non-emacs sections of my blog will be aware my recreational coding time is about to be severely curtailed. As it’s been a while since the last release and a number of new features have been added it would be nice to get some wider testing. I therefor am hoping to elicit the help of the Emacs community to check out the code and give the tires a bit of a kick before I push out the final release to “the cloud”. I’d rather not regress behaviour for the 1917 users who get Edit with Emacs from the Chrome store just before I disappear into a haze of nappies and parental responsibilities. The current changes over the last release are:

Extension

* Ignore textareas marked as read only
* Don’t tag areas that are not visible
* General clean-up to use jQuery to find elements
* Explicit CSS for edit button to override page settings
* Handle editable DIV blocks (e.g. Google+)
* Optimise the finding of text areas for highly dynamic pages

edit-server.el

* Allow customisation of edit-server-default-major-mode
* Allow edit mode to be set by matched URL
* Tweak detection of MacOS X Emacsen
* Change behaviour of C-x C-s to save to kill-ring