Use Jetpack?  Occasionally write unit tests so you won’t be a complete hypocrite when criticizing other people’s code?  Think that picture up above looks more useful than this?:

error: fail: list contents ("4,5,6,7" != "3,4,5,6,7")
info: Traceback (most recent call last):
  File "resource://wmsy-jetpack-core-lib/timer.js", line 57, in notify
    this._callback.apply(null, []);
  File "resource://wmsy-jetpack-core-lib/unit-test.js", line 257, in anonymous
    timer.setTimeout(function() { onDone(self); }, 0);
  File "resource://wmsy-jetpack-core-lib/unit-test.js", line 282, in runNextTest
    self.start({test: test, onDone: runNextTest});
  File "resource://wmsy-jetpack-core-lib/unit-test.js", line 300, in start
    this.test.testFunction(this);
  File "resource://wmsy-jetpack-core-lib/unit-test.js", line 57, in runTest
    test(runner);
  File "resource://wmsy-wmsy-tests/test-vs-static.js", line 37, in anonymous
    slice.seek(6, 2, 2);
  File "resource://wmsy-wmsy-lib/wmsy/viewslice-static.js", line 51, in anonymous
    this._list.slice(this.bufLow, this.bufHigh));
  File "resource://wmsy-wmsy-tests/test-vs-static.js", line 31, in anonymous
    "list contents");
  File "resource://wmsy-jetpack-core-lib/unit-test.js", line 229, in assertEqual
    this.fail(message);
  File "resource://wmsy-jetpack-core-lib/unit-test.js", line 147, in fail
    console.trace();

Then do I have an .el for you!  This lives here.  You mileage may vary and may involve things catching on fire which can, in turn, affect your mileage.

Let’s say you’ve suckered someone into performing their review in my review board install (more info).  It looks pretty, no?  As the Amish say: ‘Tis a fine web page, but sure ’tis no emacs buffer, English.

Get your reviewboard-viewer.el here (repo here).  It basically just wgets the review with paths in a format the GNU regex will recognize and tells the temporary file to be a compilation-mode buffer with a little help in setting up the file search path.  There are instructions in the file, but the key non-intuitive things that are going to trip you up:

• You really want to invoke reviewboard-viewer-view-review from a dired buffer showing the root directory of what the patch is against.  This lets us set up the search path to be exactly correct with no heuristics.
• The argument the above wants is the id that you will see in the “bugzilla-style export” link on the review page.  For example, I had to type the number 72 above.

Other notes to people who are interested/care:

• There was a dumb bug in the bugzilla export code involving caching.  Previous bugzilla exports likely only showed the selected hunk for the first comment on the file.  I fixed this.
• OpenID snafus:
  • Weave OpenID support via the Accout Manager doesn’t work.  (Account Manager is where it got refactored to after it got dropped from Weave core).  I feel like it worked recently with 0.0.2, but just now when I tried (with 0.0.2) it pretended it was going to work and then failed to do so.  When I upgraded to 0.0.10 it decided to not even do that.  This is sad because Weave was the whole reason I went with OpenID; I wanted to make it easier than creating another throwaway account for people.
  • I hear that whatever Google OpenID-ish thing exists, it apparently does not work either.  This was not surprising since it was my understanding Google made their implementation correct but not interoperable without some extra work.
  • Verisign’s freebie OpenID thing does work!
  • If someone knows of a django auth-compatible OpenID/OAuth/whatever implementation that will at least fix the Google situation and requires practically no work on my part, I would be happy to change to using that.  Right now I am using django-openid-auth which is old but works.  My reviewboard repo is here if you are feeling especially generous about fixing things.

About the name.  David Ascher picked it.  My choice was flamboydoc in recognition of my love of angry fruit salad color themes and because every remotely sane name has already been used by the 10 million other documentation tools out there.  Regrettably not only have we lost the excellent name, but the color scheme is at best mildly irritated at this point.

So why yet another JavaScript documentation tool:

• JavaScript 1.8 support.  JSHydra (thanks jcranmer!) is built on spidermonkey.  In terms of existing JS documentation tools out there, they can be briefly lumped into “doesn’t even both attempting to parse JavaScript” and “parses it to some degree, but gets really confused by JavaScript 1.8 syntax”.  By having the parser be the parser of our  JS engine, parsing success is guaranteed.  And non-parsing tools tend to require too much hand labeling to be practical.
• Docceleterator is not intended to be just a documentation tool.  While JSHydra is still in its infancy, it promises the ability to extract information from function bodies.  Its namesake, Dehydra, is a static analysis tool for C++ and has already given us great things (dxr, also in its infancy).

• Support community API docs contributions without forking the API docs or requiring source patches.  DevMo is a great place for documentation, but it is an iffy place for doxygen-style API docs.  Short of an exceedingly elaborate tool that round-trips doxygen/JSDoc comments to the wiki and user modifications back again, the documentation is bound to diverge.  By supporting comments directly on the semantic objects themselves[1], we eliminate having to try and determine what a given wiki change corresponds to.  (This would be annoying even if you could force the wiki users to obey a strict formatting pattern.)  This enables automatic patch generation, etc.
• Mashable.  You post the JavaScript source file to a server running the doccelerator parser.  You get back a JSON set of documents.  You post those into a CouchDB couch.  The UI is a CouchApp; you can modify it.  Don’t like the UI, just want a service?  You can query the couch for things and get back JSON documents.  Want custom (CouchDB) views but are not in control of a documentation couch?  Replicate the couch to your own local couch and add some views.
• Able to leverage data from dehydra/dxr.  Mozilla JS code lives in a world of XPCOM objects and their XPIDL-defined interfaces.  We want the JS documentation to be able to interact with that world.  Obviously, this raises some issues of where the boundary lies between dxr and Doccelerator.  I don’t think it matters at this point; we just need internal and API documentation for Thunderbird 3 now-ish.
• A more ‘dynamic’ UI.  The UI is inspired by TiddlyWiki‘s interface where all wiki “pages” open in the same document.  I often find myself only caring about a few methods of a class at any given time.  Documentation is generally either organized in monolithic pages or single pages per function.  Either way, I tend to end up with a separate tab for each thing of interest.  This usually ends in both confusion and way too many tabs.

1: Right now I only support commenting at the documentation display granularity which means you cannot comment on arguments individually, just the function/method/class/etc.

Example links which will eventually die because I’m not guaranteeing this couch instance will stay up forever:

• Live version of the first screen shot of folderDisplay.js and FolderDisplayWidget
• Live version of the second screen shot of comments on FTBO_stubOutAttributes.  Feel free to add your own.
• Live version with nothing up.  Click on some files, explore!

The hg repo is here.  I tried to code the JS against the 1.5 standard and generally be cross-browser compatible, but I know at least Konqueror seems to get upset when it comes time to post (modified) comments.  I’m not sure what’s up with that.

Exciting potential taglines:

• Doccelerator: Documentation from the future, because the documentation was doccelerated past the speed of light, and we all know how that turns out.
• Doccelerator: It sounds like an extra pedal for your car and it’s just as easy to use… unless we’re talking about the clutch.
• Doccelerator: Thankfully the name doesn’t demand confusingly named classes in the service of a stretched metaphor.  That’s good, right?

• Index non-offline messages.  Currently, gloda only indexes messages that are available offline.
• Show indexing status in the activity manager.  Is gloda indexing your messages?  No way to know*… if only we showed things in the activity manager…
• Do not index junk messages.  Gloda currently indexes your junk mail.  It should not.  Thunderbird knows when a message has been marked as junk, and knows who is a junk folder.  Help gloda give up spam cold turkey.
• Implement a memory reporter for gloda. This would help us debug things.  The follow-on would be to write something that actually outputs the information.

Exciting? Exciting!

I don’t know much about psychology, but I have heard that people on the internet see a call-to-arms like this and say “I’m sure someone else better qualified will step up, maybe even hundreds of them… I’ll just let them take care of it.”  I have news for you, people on the internet are lazy!  Oh, so lazy!  (I am reasonably confident that won’t happen.  If it does happen, I will find enough work for everyone to do while I retire to a life of luxury funded by my ability to inexplicably motivate large swathes of the internet to do my bidding.)

Important steps!

1. Get yourself a copy of the comm-central codebase.
2. Build thunderbird! (Actually, that above link covers it, but you might also want to check out the general building info page.)
3. Dance a victory jig!
4. Leave a note on one of those bugs saying that you are interested.  Or just e-mail me at asuth@mozillamessaging.com!