Custom key binding for " " broken in r2818
Reported by Bill Cole | March 28th, 2012 @ 08:47 PM
I have a small custom key binding file at ~/Library/Application
Support/MailMate/Resources/KeyBindings/Mine.plist with this
content:
{ " " = "scrollPageDownOrNextUnreadMessage:"; "T" =
"nextUnreadThread:"; "t" = "nextUnreadThread:"; }
In "real" IMAP folders sorted by date and grouped by thread the " " binding seems to consistently work in a logical way. However, in some "Smart" folders with idiosyncratic sorting, what happens in response to typing a space is quite confused.
Example: I have a folder called "unread listmail" that includes all messages in the Unread folder with a List-ID header. I typically sort/group this folder by first having it sorted by date and then sorting by Source Mailbox (which equates to which list mail is from, due to server-side filters) with "Organize by thread" turned on. The result is a single listing of all unread list mail, grouped by mailing list with threads sorted by date. If focus is in the message list, the 'space' binding usually works but occasionally switches (under conditions I can't identify) to moving backwards, i.e. as if it is mapped to "scroll down or previous unread message." If focus is in the message pane, it acts as if the mapping is to "scroll down or next message"
I only encountered this today, and because the strangest (backwards) behavior only appears after I've read some messages and maybe clicked back and forth in the list, I can't be sure that this just started with r2818.
Comments and changes to this ticket
-
benny April 3rd, 2012 @ 12:45 PM
- State changed from “new” to “reproduced”
I think there are two issues here. One is new and one is old.
-
When in the message pane it does not jump to next unread message. This is an old issue which I had not considered. The space entered is handled by the message view itself and immediately mapped to the non-unread variant of scrolling page down. Therefore, your alternative mapping of space does not work (it would work with a different key, but that would not be very useful). I'm not yet sure how to fix this, but I have an idea.
-
Some users sort newest message to the top and some to the bottom. The interpretation of “next message” depends on the sorting direction of the messages outline, but I had not considered the case in which date-sorting was the secondary sort criterium. Therefore what happens depends on the sorting direction of the primary criterium (Source Mailbox in your case). This might explain what you see (I'm not 100% sure on that given your description of the problem). I also need to give this some more thought to solve it properly.
I'm not a big fan of newest-at-the-top sorting (at least not when threading) :-)
-
Bill Cole April 3rd, 2012 @ 03:31 PM
I will try to find a way to reliably reproduce the strange behavior. I also use oldest-at-top date sorting, but I had not thought of the primary sort order as a variable, although obviously it would be. More evidence that P != NP :)
And to clarify: when I stumbled across this behavior, the "backwards" effect seemed to be switching the message selection up-screen into a late message of an older thread, expanding the thread, and marking the newly-selected message as read. Part of my weak and unsure analysis of this is due to the visual disorientation of that set of events. I could be mistaken about the starting state of the message being selected, since it has been in a collapsed thread.
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป
Mac OS X email client.
benny