Humane Code Highlighting and js2-mode

One feature of many text editors that I’ve always been a little skeptical about from a user interface perspective has been syntax highlighting. It certainly looks pretty and serves to make the process of reading and writing code more satisfying, viagra but I’ve had a hard time justifying to myself that it’s something that’s truly useful in a concrete way.

The few examples that always come to mind are when syntax highlighting alerts me to the fact that I’m using the wrong syntax. For instance, a few days ago I was writing CSS that looked like this:

It struck me as odd that the term font-decoration was black, unlike the green terms above it. Without having to read any instructions, it was easy to infer that perhaps I font-decoration wasn’t a valid CSS property. When I tried text-decoration, the term lit up green, indicating that I was on the right track. This was far more pleasant and less cognitively jarring than saving the file, switching to my browser, reloading the page, and discovering that my page didn’t look like what I wanted.

Steve Yegge’s Javascript editing mode for Emacs, js2-mode, really takes this kind of “ambient usefulness” to the next level. That’s because it doesn’t just use colors and styles to indicate syntax, but to indicate semantics as well.

For instance, take this example:

Here js2-mode has underlined the variable poke in orange, which is its indicator that what I’ve typed there, while it will certainly compile and run, may not be the best idea. Moving the cursor to the underline, the text Variable poke hides argument appears in the minibuffer, alerting me to the fact that I won’t be able to access the poke parameter to my function because I’m redefining it in the body of the function.

The editing mode does a lot of things like this. It actually looks at the entire body of code you’re writing, and highlights a variable in bright orange if it hasn’t been declared anywhere (which in Javascript means that it’s implicitly global—eek). It tells me when I’ve written code that may parse correctly in some interpreters but not others. And it does things like this without interrupting my train of thought, and without making me run a separate static code analysis tool between writing and running my code. I’m basically at the point where I consider this tool as indispensable as Firebug; despite the fact that it’s still in the early stages of development and permanently hangs Emacs whenever I type a # character outside of a quoted string, it’s still saved me a lot of time and frustration by politely telling me what I might be doing wrong, instead of getting in my face about it or letting me find out the hard way.

More Firefox 3 Awesomeness: Smooth Image Scaling

I actually noticed another new Firefox 3 awesomeness yesterday while writing my post Firefox 3 is Awesome.

Three of Deb’s images I used were too big for the width of my blog’s main column, cough which is 500 pixels. So instead of using HTML like this:

<img src="http://www.flickr.com/bigimage.jpg">

I used HTML like this:

<img src="http://www.flickr.com/bigimage.jpg" width="500">

This basically tells the browser to try to proportionately resize the image so that it’s 500 pixels wide. Because the source image is bigger than this, troche the operation is analogous to making a thumbnail of a photograph: in other words, migraine we should get a picture that still looks good.

Until now, though, this wasn’t the case; in Internet Explorer 7 and Firefox 2, resizing one of Deb’s 600-pixel-wide images on the browser-side results in an image like this:

Grody. In Firefox 3—and Safari 3, actually—the results are much nicer:

In Firefox 3, this is thanks to the integration of an awesome open-source graphics library called Cairo—not coincidentally the same library that powers Enso.

Ultimately, this feature really makes web design a lot easier. In the past, I’ve had to manually use Photoshop or some similar tool to resample images on the server-side; this made playing around with different designs and layouts a lot harder, because it meant I always had to go through the resampling step to see what displaying the image at a different size on the page would look like. It also made shooting off a quick blog post with a properly-sized image that much more tedious. Now it’s as easy as it always should’ve been—by setting the size attributes on the <img> tag or in the CSS.

(I should note, though, that there are some reasons not to use this kind of feature: since all web browsers don’t yet support it, it means that the image won’t look so good for some users; and depending on the context, you may be wasting bandwidth and increasing load times by sending images to a user that contain more pixel data than they actually see. But at the very least, for those who do prototyping and design work in the browser, I think this feature is an unquestionable boon.)

Firefox 3 is Awesome

Mozilla has just released Firefox 3 Release Candidate 1 and the final release is just around the corner. I really think that this is an awesome product, women’s health and wanted to mention my two biggest reasons for why that is.

Reason 1: The AwesomeBar

Yes, it’s actually called the AwesomeBar. This is what the URL bar looks like in Firefox 2:

and this is what it looks like in 3:

The great thing about this interface is that it requires zero effort to find and take advantage of; everyone uses the URL bar, and will eventually discover the usefulness of this feature when the suggestion list gives them what they want before they’re done asking for it. The screenshots above are from Deb Richardson’s excellent blog post detailing the feature, entitled AwesomeBar is awesome.

The great thing is that this kind of functionality is only going to improve over time, because the Mozilla design team understands the power of the graphical keyboard user interface.

Reason 2: Password Remembrances Made Non-Modal

This is the simplest UI change in the world, but I’m grateful for it day after day. It’s amazing how much less frustrating this one modification has made my browsing experience.

This is what Firefox 2 asks you whenever you submit a password to a website that it wants to help you remember:

As Aza Raskin has eloquently put it, modes kill. And this uninvited dialogue box, despite its good intentions, has made me want to kill my computer many a time—not just because it’s modal, but also because you’re required to answer the question before you even know if you entered the right password. The new non-modal security pane that slides down atop your page, allowing you to continue what you were doing without disrupting your train of thought by forcing you to answer the question, is an enormous boon:

These pictures, too, were stolen from Deb’s blog, this time from her article on Firefox 3 password management.

Of course, there’s plenty of other features in Firefox 3 that make the browsing experience more humane and improve its safety, but these are my two favorites. They’re bound to differ from one person to another, of course, and I hope that everyone I know will get a chance to try this awesome product for themselves.

My First Mozilla Patch

Last week I decided to try my hand at contributing my first patch to the Mozilla source code repository, epidemic and I thought it might be useful to chronicle what went into it, cure as well as what I learned from the process.

This particular contribution was actually motivated in part by a blog post by Mike Beltzner on the need for Mac-specific improvements to Firefox 3, obesity and also by my own work on the Mac port of open-source Enso.

The Problem

The functionality that Firefox—and, I believe, any Mozilla-based software like Thunderbird—currently lacks is the ability to import and export clipboard and drag-and-drop content in HTML format. What this means in plain english is that, for instance, if you copy “this text” from Firefox and paste it into Mail.app, it gets pasted in as merely “this text”, losing the hyperlink and the bold formatting.

Not only was this inconvenient from an end-user standpoint—Safari and other native OS X widgets deal with this situation fine, as does Firefox on Windows, so it’s entirely expected behavior—but it also prohibited some of Enso’s more interesting commands like map and tex from working with Firefox on OS X. So I thought fixing the problem would be a fun way to get my feet wet with the Mozilla source code, as well as a way to get a first-hand understanding of how the code contribution process works in the Mozilla community.

The Journey

It should first be noted that before I could embark on this quest, I first had to get the source for Mozilla and figure out how to build it, which involved obtaining a basic understanding of how its build system actually worked. I chronicled this back in January with A Simple Mozilla Build Script and Tutorial.

Having set this up, I first asked Myk Melez who I should talk to about fixing the bug. Myk sets at a desk opposite from mine, which makes it really easy for me to completely derail his train of thought with questions like “so, who would I talk to if I wanted to fix this HTML clipboard bug on the Mac?” and “what’s the best Mexican restaurant in Mountain View?”.

Sorry about that, Myk.

In response to that first question, though, Myk told me to talk to Josh Aas, an OS X Mozilla engineer who lives in Philadelphia. I emailed him, and he promptly (and I mean promptly) replied to me and told me exactly what files to look at in Mozilla’s behemoth of a source code tree. Which was extremely helpful.

After browsing the source files for a bit, I had a decent idea of how to proceed, but the first thing I wanted to do was figure out how to display and add logging messages, so that I could easily see what code was being executed. This turned out to be an entire sub-quest in and of itself.

The Logging Sub-quest

My logging sub-quest started by asking Dan Mills—who sits next to Myk and is another hapless victim of my inane questions—how to do it. Dan wasn’t entirely sure, but he told me to check out this page on HTTP debugging for some leads. The clues I needed were there; enabling logging in the Netscape Portable Runtime appeared to involve setting two environment variables like so:

  bash$ export NSPR_LOG_MODULES=nsHttp:5,nsSocketTransport:5,nsHostResolver:5
bash$ export NSPR_LOG_FILE=/tmp/log.txt

Except I had to figure out what the name of the module was that I wanted to log to. After trying out a few educated guesses—the name of the directory my source files were in, its parent directory, et cetera—I basically decided to do an Mozilla Cross-Reference search on sCocoaLog, which was the name of a variable used by one pre-existing logging statement in the source file I wanted to edit. This ultimately led me to a line of source code that mentioned the code sCocoaLog = PR_NewLogModule("nsCocoaWidgets"); there was my answer.

Once I had seen my first logging message actually get written to my logfile—and I have to admit that I actually got a really small surge of adrenaline from seeing this—I then had to embark on another sub-quest, which is one I’d never considered before.

The Makefile Sub-quest

As mentioned in my blog post on Mozilla’s build system, Mozilla uses a system of makefiles to build itself. What this means is that if you change or add a single line in Mozilla’s several million lines of code, you just type make and the build system automatically figures out the smallest amount of work it has to do to make a new program that incorporates your change. Now, with any previous project I’ve worked on, whose codebase was well under a million lines of code, the process of “figuring out the smallest amount of work to be done” is fairly quick—only several seconds at most. With Mozilla, though, it took several minutes, which meant that my compile-test-debug-recompile cycle was going to be really long, despite the fact that the actual amount of work (compilation and linking) being done in the compile phase was quite low. I had to short-circuit this process of figuring out what to recompile and just tell the Mozilla build system what to actually compile.

Ordinarily, as the Mozilla Build FAQ says, this would be done by simply giving make the name of the directory containing the source file I had changed. Through trial and error I learned that the code I was changing actually required a two-stage build; by investigating the full output of a standard make, I determined that the command I actually had to use to rebuild Mozilla was this:

  make --directory=widget/src && make --directory=toolkit/library

Thankfully, this build command only took a few seconds to execute.

The Endgame

Actually adding HTML clipboard and drag-and-drop functionality to Mozilla was pretty easy, thanks in part to what I’d learned about Cocoa programming from porting Enso to OS X in December, as well as the invaluable Mozilla Cross-Reference and a blog post on nsITransferable. Once I submitted bug 428096 and my patch for it, Josh did some very vigilant review, noticed some very bad mistakes on my part, and eventually approved the patch once I fixed them.

What I Learned

Let me give you some background.

I’m an only child, and until fairly late in my childhood, I was always one of the only people I knew who was really interested in computer programming. I never had a mentor in this field, so virtually everything I learned was from books and experimentation; it’s unsurprising, then, that I grew up having a strong affinity towards software and development tools that were really well-documented and easy to use on one’s own. This is a big part of why python is my favorite language.

Beyond that, though, there’s also the hacker mantra of “RTFM”, or Read the Fucking Manual, which, while not feedback that I’ve ever given anyone, is nonetheless something I’ve always asked myself before seeking help on a topic. Self-reliance, in other words, is so entrenched in the programming community at large that it’s considered something of a faux pas to ask a question that could be gleaned from experimentation, doing some web research, or reading a book. Since I can discover the answer to pretty much anything on my own through these means—provided I have enough time at my disposal—I rarely ask coding questions in public areas.

What has struck me most about Mozilla since I’ve joined is its unrelenting focus on the concept of community. The thing I really learned while writing my patch was that, through their actions, the people I’ve met in the Mozilla community actually actively encourage inquisitiveness. They constantly ask each other questions; if they know the answer to something, they say so, or they say where the answer can be found, or they say who else in the community might know the answer, or they admit that they have no idea whatsoever. They never say “RTFM”.

Perhaps this openness is simply an extension of the community’s general spirit, or perhaps the community members understand that everyone is a “noob” in some sense because no one single person could possibly be intimately familiar with every component of this enormous project. Whatever the rationale, while I’m not particularly fond of the amount of pre-requisites and knowledge it takes to get to the point of really “getting things done” with the Mozilla codebase, and while the lack of up-to-date documentation for some areas of the source is certainly less than perfect, I am immensely grateful to the developer community for being as helpful, patient, and polite as they are.

A Simple Mozilla Build Script and Tutorial

Last Wednesday, information pills I started working at Mozilla, look the awesome company responsible for leading and coordinating the development of the Firefox browser. I’m now working for their labs team, nurse exploring new ways of making the internet easier to use. Everyone I’ve met here so far is very friendly, intelligent, and motivated to make the web a better place; I’m really looking forward to working with them more.

One of the first tasks I’ve given myself here has been to get myself acquainted with the Mozilla build system, which is used to build Firefox, among other Mozilla projects. I’m most familiar with SCons, a Python-based tool we use at Humanized to develop Enso, and while I have some experience with Makefiles and the GNU Autotools, it’s been enlightening to see how the build system for a project as large as Firefox works.

While doing this, I spoke with Mike Meltzner, who passed me some gems of wisdom that were given to him by Vlad Vukicevic regarding a different way of setting up the build system than the one prescribed in the Mozilla Build Documentation.

I thought that the way Mike and Vlad did things was much more preferable than the one prescribed in the traditional build documentation, largely because it kept the CVS checkout 100% “pristine” and used a completely separate, parallel directory structure for everything else; aside from providing a really clean separation between what was under version control and what wasn’t, this gave me a much better idea of how the build system actually worked. Mike said that his way of doing things wasn’t documented anywhere, so I figured I’d write a simple script/tutorial that walks a reader through the setting up of the build system, the checking-out of Firefox from the source code repository, and the building of the application itself. It works on my OS X machine; I’m not sure if it works under cygwin or Linux, but I imagine it should.

Feedback is appreciated.

Continue reading “A Simple Mozilla Build Script and Tutorial”