What it means for GMail's web interface to use a different grammar for labeling and searching...

I have been having a hard time explaining this to the Google Apps support team. I originally contacted them because I had a lot of labels with leading special characters that I use to affect their sort order. For example, I have a "?Bulk" label grouped together with other "?Bulk/sublabels" (e.g., "?Bulk/Facebook"). The leading question mark prevents them from showing up in the middle of other labels I have that start with "B". Moreover, using leading special characters lets me put certain important labels at the top of my list where they are easy to see and access.

Now, the search bar at the top of the GMail web interface doesn't have much problem with this. It will match such labels regardless of whether I include the leading special character:

Note that it's not just finding partial matches in the middle of a label. If you drop the first alphanumeric character after the special characters, you get no matches:

Now, you would expect the "Move To" and "Copy To" quick searches to behave the same way. At first, it seems like they do. They'll do partial matches from the front of the label if you include the special character:

But if you drop the special character, you're doomed.

Pretty annoying, huh? See, "Move To" and "Copy To" are using some special grammar to extract information from the list of labels. Apparently this grammar is overly simple. Now, I might be able to live with that if it wasn't the case that GMail Search knows how to get labels right. In fact, Gmail Search can even handle nested labels with leading special characters. Check it out:

See? It was able to recognize that the "/" in big version of the label name separated parent from child label (which actually can be a problem if you're not intending to use nested labels). It then looks for matches at the start of the sublabel, which is in the middle of the big label shown. Pretty cool. Moreover, if you drop the leading alphanumeric character, the match fails:

Now, apparently "Move To" and "Copy To" have some of this matching behavior. That is, they'll properly chop the label into parent and child and look for matches in just the child part:

Unfortunately, you need the special character for the match to work:

So, again, for some reason GMail has developed the quick search for "Move To" and "Copy To" independently from GMail Search in general. Maybe this was an optimization, but it seems like it wouldn't be too slow to call out to GMail Search to find these labels. Then everything would be consistent.

Now, I tried explaining this to the Google Apps support team initially. You know what they told me? That "Gmail Search" doesn't do partial matches, and so it's the expected behavior. Can you believe they actually had the nerve to forward me to a GMail Search page when the real problem is that "Move To" and "Copy To" are in fact acting DIFFERENTLY than GMail Search? IF ONLY the issue was with GMail Search; I could live with that.

Well, Thunderbird gets it right. I guess that's a nice workaround.

pine, mutt, elm, and mousetraps

The web hosting provider for tedpavlic.com recently upgraded their UNIX boxes to a 64-bit platform, and the websites I host with them had to be moved over. There were a few small hiccups (primarily due to 32-bit apps I built that needed to be re-built), but most of the issues afterwards had to deal with apps that I asked them to install on the old machine that I then had to ask them to install again on the new machine. One of those apps was (al)pine, which is the console-based e-mail client that I use. They installed pine for me, but the guy in charge was curious. Here's a response to a question he had about my request. It's my justification for using pine (and throwing away the mouse).

But I must ask, for the few odd requests I get for pine, I am curious as to if you actually use it on a day to day basis or just for testing. I remember using it back in the day (good ol'e ISDN!), but it seems a bit redundant and quaint now that we have webmail and Thunderbird and such.

Gosh – pine is far more powerful than either of those. For example:

*) Does webmail support IMAP tags? Pine does. Thunderbird just started, and it's support is still limited.

*) When managing large folders of mail, it's often much easier to query and process the messages with pine. I can quickly select a batch of messages, invert the selection, view the selection as its own folder, etc. etc. I have much more efficacy in pine.

*) If I'm at a remote computer, it's much more convenient for me to ssh into gemini and run pine than to use webmail (which is slow and clunky) or setup Thunderbird for my one time use.

*) If I'm at a remote computer *with* pine, if I run THAT pine and point it at gemini's IMAP server, pine will use the pine configuration (and address book) that is stored in a special IMAP folder. Hence, pine is much more portable than Thunderbird.

*) With very few exceptions, I'm much happier with console-mode (or near-console-mode) apps. Similarly, I use vim on every machine I have. Not only does it give me a uniform editing environment wherever I am, but with the addons packaged with any standard vim installation, vim will download, edit, and upload networked files automatically for me without much extra work on my part.

*) Oh, and don't forget that once upon a time you could only get pico with pine. Now, IIRC, nano comes separately.

My officemate uses mutt, and I used to be a major elm fan because it integrated better with vim. I shifted to pine because it's just so very powerful.

Have you heard of Vimperator? It's an add-on for Firefox that makes it act like Vim. The same people also brought out Muttator – it's an addon for Thunderbird that makes it act like mutt.

So there are lots of us out there that are dissatisfied with the GUI. Console-mode developers don't put a lot of time into perfecting the shading of the chrome. Instead, they add features, and they make the apps fast.

(note: applications like Quicksilver, Spotlight, and Microsoft's latest knock-off are bringing people back to the keyboard. People would rather *type* the app they want to launch rather than clicking through folders. Eventually, people will realize where the mouse belongs – dead in a trap stuck in the garbage out in the garage)

Thanks. :) –
Ted

Pine, PASSFILE, all-patch, and Thunderbird 2.0 IMAP keywords

Thunderbird 2.0 has been released! It's fast and finally supports an arbitrary number of custom IMAP keywords (IMAP keywords are similar to the labels used in GMail). I'm thrilled about this.

However, regardless of how wonderful Thunderbird gets, I will always keep PINE around (which has supported IMAP keywords for a long time).

When I build PINE for my systems, I usually pick up a few of the most popular patches as well. I never noticed that there was an all of the above patch that packages ALL of the most popular patches, new features, and bug fixes. I think this is pretty exciting too.

To build PINE with PASSFILE support (i.e., support for saving passwords to file), I recommend using the infinite ink instructions:

#!/bin/sh
./build clean
./build 'EXTRACFLAGS=-DPASSFILE=\".pine.pwd\"' osx
#                                              ^^^
#                                              platform

You can find a list of platforms in the doc/pine-ports file. Some common ones include (see the document for any special build instructions):

    BSD (original BSD 4.3 from U.C. Berkeley)
        bsd     BSD 4.3

    BSDi
        bs3     BSDi BSD/386 Version 3 and Version 4
        bs2     BSDi BSD/386 Version 2
        bsi     BSDi BSD/386 Version 1

    Cygwin
        cyg     Cygwin environment under Windows 

    HP-UX
        hpx     HP-UX 10.x
        hxd     HP-UX 10.x w/ DCE
        ghp     HP-UX 10.x using gcc
        hpp     HP-UX 8.x and 9.x
        shp     HP-UX 8.x and 9.x w/ TCB
        gh9     HP-UX 8.x and 9.x using gcc

    Linux
        lnx     Linux using crypt from the C library
        lnp     Linux using PAM
        slx     Linux using -lcrypt for crypt()
        sl4     Linux using -lshadow for crypt()
        sl5     Linux using shadow passwords
        ldb     Debian Linux
        lmd     Mandrakelinux
        lrh     RedHat Enterprise and RedHat 7.2 or later
        lsu     SuSE Linux

    Macintosh
        osx     Macintosh OS X
        ox2     Macintosh OS X 10.2 and earlier

    NetBSD
        neb     NetBSD

    OpenBSD
        bso     OpenBSD w/ shared-lib
    
    QNX
        nto     Neutrino

    SCO
        sc5     SCO Open Server 5.x
        go5     SCO Open Server 5.x using gcc
        sco     SCO Unix
        gsc     SCO Unix using gcc

    Sun Solaris (Solaris 9 is the same as SunOS 5.9)
        gs5     Sun Solaris >= 2.5 using gcc
        soc     Sun Solaris >= 8 using Sun C
        gs4     Sun Solaris <= 2.4 using gcc
        so5     Sun Solaris >= 2.5    (try soc or gs5)
        so4     Sun Solaris <= 2.4

    Sun SunOS (This is pre-Solaris SunOS)
        sun     Sun SunOS 4.1
        ssn     Sun SunOS 4.1 w/ shadow passwords
        gsu     SunOS 4.1 using gcc
        s40     Sun SunOS 4.0

    System V Release 4
        sv4     System V Release 4

    Windows
        wnt     Windows NT 3.51

Happy mailing!