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.

Why GMail's show-if-unread is NOW useless with nested labels

Once upon a time, when they were both in "GMail Labs", the show-if-unread feature and nested labels features worked together seamlessly.

• nested labels: You could create a nested label (like a subfolder) by adding slashes in folder names. You would create two folders called "Parent/ChildA" and "Parent/ChildB", and they would be displayed as "ChildA" and "ChildB" underneath a single "Parent" that you could collapse and expand.
• show-if-unread: Only labels that had unread messages in them would show up in the left bar. To see all of your labels, you could use the "more" link which would show you a full list.

In the case where a nested label had unread messages in it, it would show up in its flat form (if I recall correctly) in the list. So you'd see "Parent/ChildA" but "ChildB" would still be nested under "Parent" in the "more". That was fantastic.

However, eventually both labs features became integrated into production GMail, and they messed it all up. Now, ostensibly to avoid revealing the slash form and to avoid having parent labels repeated in both the unread and read lists, they've made it impossible to apply show-if-unread to nested labels. Consequently, if any nested labels have unread messages in it, the parent and all of its nested labels show up in the unread list. So you get things like this (click for larger):

Obviously, that defeats the whole purpose of show-if-unread. I'm forced to look at all of those read nested labels just because some of their "sublings" are unread.

So Google has gone from taking two nice features and combining them into one terrible and useless and awful thing.

When the deli says "surprise" on the menu, they mean it

Now that's one helpful nutrition label...

Blogger Labels: No more than 20, unless there are more than 20.

I think it's dumb that the "Labels for this post:" line at the bottom of this bottom of this editor only lets me enter in 20 labels, but if I go into the "Edit Posts" and check this post, I can add as many existing labels as I want one by one.

So I have posts that have more than 20 labels. When I EDIT them, I have to DELETE labels in order to SAVE, and then I have to re-add them using the "Edit Posts" manager.

It's also dumb that Blogger prompts me for label completion and then picks the first one in this list when I hit "," regardless of whether I actually entered the list. So when I type "tex," in the "Labels for this post", it changes it to "AUC TeX," because that label is higher in the list but appears to match. (yes, I can scroll down to "tex" and select it... but what if it DIDN'T EXIST? What if I wanted a new label? In that case I have to let it complete and then go back and modify what it entered WITHOUT hitting comma again and causing another auto-completion.

I wonder when web development started going so far down hill. I'm sure "certification" has something to do with it. You can promote people based on their "certification" and not on their merit... I guess. I suppose that's a subject for another post.

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!