I’m not even going to say anything.

You’ve got to be kidding me…

C’mon, why are you still reading this here?

Note: I’m mirroring posts from my new blog for a few weeks on this (dead) blog.

Update your feed readers to this feed – http://blog.abi.sh/feed

And, if you’re reading this from Planet Mozilla (which will update itself), you should still subscribe to the new feed because I only syndicate technical posts.

If you have any suggestions or thoughts about the new design, comment there.

Initially, I tried to mimic the Bespin environment and execute it from the command sandbox but then, I figured out that I could simply execute the command using the Bespin object loaded on the Bespin page so the code is actually pretty short. But as I explain below, this also imposed some restrictions.

Get the command and test it right away. Go ahead, try “save” or “help” or “export” or anything else.

Quick Improvements

• Commands ought to be loaded dynamically so if you have custom commands in your BespinSettings project, Ubiquity would be able to load them too. But that doesn’t work currently.
• Commands should only work on the Bespin page. If you typed “save” on any other page, the Bespin command should not even show up.

A Few Notes

• Bespin’s command parser itself is very simple when compared to Ubiquity’s. For example, it is not possible to write “export tgz” to export the current project in .tgz format. You could write “export” to get it in the default format (.zip) but if you wanted it in .tgz, you have to write “export SampleProjectName tgz”. In my earlier (longer) version of the hack, this would work because I was extracting the arguments myself but now, I’m passing it directly to the Bespin parser.
• On a related note, commands are now semantic in Ubiquity 0.5 but Bespin commands aren’t. If a command has two or more arguments, I am artitaribly adding some “semantics”. “export [project] [archivetype]” becomes “export [project] to [archivetype]” (obviously, export [project] as [archivetype] would make more sense here). It would be better to individually figure out how it should be for each Bespin command. At the moment, this screws with the semantic nature of Ubiquity commands.
• Auto-completion in the Bespin command line is broken. Try writing “ex” into the command line and executing it, it will fail. But, why should it throw an error when it clearly knows what the user meant by “ex” (because export is only command that starts with “ex”)? Instead, it requires one more keystroke (TAB).
  
• Bespin should use Yip/Growl notifications and if that fails (for the millions for people who don’t have Yip yet!) revert to in-browser notifications which need to be much better than they currently are. As seen below, they obscure your content and clicking on the notification doesn’t hide them (you have to click the tiny X at the top-right).
  
• The ability to run Ubiquity commands from the Bespin command line might be handy for some who are used to the Bespin command line. “run selector-selector” and “escape HTML entities” are just two Ubiquity commands that developers might find useful.
• Bespin commands need better descriptions and help.

How can this be more useful? What other aspects of Ubiquity and Bespin can be integrated?