apply foldersort after folderfilter

[lahwaacz]

Hi,
the 'foldersort' option doesn't work, it's completely ignored. Also there's no mention of it in man page.

[shiquanwang]

I also noticed that.
It seems now the input args for the foldersort is of class IMAPfolder and has no method startswith.

[konvpalto]

8b6f10e in the "next" branch should fix that. Please, test.

[lahwaacz]

I was able to achieve what I wanted, foldersort now works as expected. I was just wondering, why foldersort is applied before folderfilter? This way I have to manually check in the compare function if the folder names are filtered out or not.

[konvpalto]

Sorting and excluding should be commutative: filtering before sorting will give you the same results as sorting after filtering if filtering has no side effects on the folders. I agree that sorting after filtering will be faster because one has to sort less, but may be I don't understand some implications of your situation? Why do you need to check filtered folders inside sort comparator?

[lahwaacz]

I construct mapping dictionary for nametrans from two lists of keys and values:

mapping_remote = ['INBOX', '[Gmail]/Drafts', '[Gmail]/Spam', ...]
mapping_local = ['INBOX', 'drafts', 'spam', ...]
mapping_gmail = dict(zip(mapping_remote, mapping_local))

This is used by both nametrans and folderfilter:

def nt_remote(mapping):
    def inner(folder):
        try:
            return mapping[folder]
        except:
            return folder
    return inner

def nt_local(mapping):
    r_mapping = dict(zip(mapping.values(), mapping.keys()))
    def inner(folder):
        try:
            return r_mapping[folder]
        except:
            return folder
    return inner

def exclude(mapping):
    def inner(folder):
        if folder in mapping.keys():
            return True
        return False
    return inner

In config, that's used like this:

nametrans = nt_remote(mapping_gmail)
folderfilter = exclude(mapping_gmail)

If sorting would be done after filtering, I could use sort comparator based simply on mapping_local.index(item), that's simply

def folder_cmp(lst):
    def inner(x, y):
        return cmp(lst.index(x), lst.index(y))
    return inner

and of course in config:

foldersort = folder_cmp(mapping_local)

Instead I use this horrible thing:

def folder_cmp(lst):
    def inner(x, y):
        if x in lst and y in lst:
            return cmp(lst.index(x), lst.index(y))
        elif x in lst:
            return -1
        elif y in lst:
            return 1
        else:
            return 0
    return inner

[konvpalto]

Well, it turns out that it is not that simple to achieve what you want, but I am working on that. Might take a couple weeks, though: EBUSY most of the time.

[nicolas33]

Looked at this and as previously said, it's far from trivial patch. Don't expect changes any time soon.

[nicolas33]

Both compare features are:

• mbnames: https://github.com/nicolas33/offlineimap/blob/ns/mbnames-2/offlineimap/mbnames.py#L191
• foldersort: https://github.com/OfflineIMAP/offlineimap/blob/master/offlineimap/repository/IMAP.py#L427

I guess there's a way to use the same key sorting for both. I'm using none of those features. Could anyone try to make both identical in behaviour?

Also, I think we might stop supporting the "cmp" way of sorting folder names for Python2.

[nicolas33]

Instead of

def folder_cmp(lst):
    def inner(x, y):
        if x in lst and y in lst:
            return cmp(lst.index(x), lst.index(y))
        elif x in lst:
            return -1
        elif y in lst:
            return 1
        else:
            return 0
    return inner

I think the following code would provide the expected behaviour:

def folder_cmp(lst):
    def inner(x, y):
        try:
            return cmp(lst.index(x), lst.index(y))
        except KeyError:
            return 0
    return inner

Anyway, since this was not implemented for years, I'm closing. I guess that the benefit don't worth the trouble.

[lahwaacz]

Your solution does not consider the case when only one of the arguments is not in the list, in which case the result should be either 1 or -1. Hence it is not a correct comparator.

[nicolas33]

Yes.