GNOME Bugzilla – Bug 268644
unread mail shortcut collides with gtk-2.6 search feature
Last modified: 2009-10-29 11:43:17 UTC
Distribution: Fedora Core release 2 (Tettnang) Package: Evolution Priority: Normal Version: GNOME2.6. unspecified Gnome-Distributor: Red Hat, Inc Synopsis: Selecting a folder vs selecting next unread message from keyboard Bugzilla-Product: Evolution Bugzilla-Component: Mailer Bugzilla-Version: unspecified Description: Please describe your feature request: If I click on a folder on the left pane, and immediately type "." or "]" to go to the next unread message, an input box opens up. I need to click explicitly on some message in the message list pane before "." or "]" will work (and of course clicking on it means fetching the message, perhaps from a slow server). A "." or "]" in this context is almost never going to mean "look for a folder whose name begins with . or ]" since that case cannot arise with IMAP folders and (I conjecture) it's pretty unlikely even with local folders. So the suggestion is: either special-case the interpretation of "." and "]" in this context, or (more generally) allow an easy keyboard shortcut to switch to the message list pane. Maybe such a shortcut already exists; if so, the online Help is silent on the subject. Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
cannot reproduce this with evolution-2.0.2.0.200411260600-0.snap.ximian.10.1. which evo version are you running? if i click on a folder name in the folder tree and push the "." key, evo displays the next unread message in the folder. can i close this one?
Version is evolution-2.0.2-3 on Fedora Core 3 (now). This bug definitely exists and is 100% reproducible.
I have the same problem and it really is rather annoying. Evolution version is 2.2.2, GTK version is 2.6.8. Andre, are you using a new enough version of GTK? Older versions of GTK wouldn't trap key presses in the treeview to do incremental search, which is what we're seeing here.
The bug is still present in Evo-2.2.2 on a new install of Fedora Core 4 (GTK 2.10 AFAIK).
johannes: i'm running an *old* version here, gtk2-2.4.9-10 on suse9.0. current gtk version is 2.6.8 according to http://gtk.org.
Sorry, I meant to say Gnome 2.10.
Andre: That explains it. The feature that's getting in our way here is lookahead search, which was introduced in gtk 2.6.0. It shouldn't be triggered for .,[] on the folder list.
going to put focus on this at the next team meeting. :-/
changing summary to get more attention, setting target to 2.3 since this question will be definitely asked much more often if gnome 2.12 is out.
ctrl-] is the 'new' key to go to the next unread message.
not zed: please take a look at bug 250873, it's entirely the same here in germany, i have to press "ctrl + altgr + 9" to get "]". it's really annoying, i prefer "." this IS a bug. i presume nobody in europe uses "]", but "." to get to the next mail. so perhaps dobey or anybody should care about a nice shortcut. :-/
*** This bug has been marked as a duplicate of 250873 ***
Reopening per request of the reporter http://mail.gnome.org/archives/evolution-list/2009-May/msg00049.html
I wanted this reopened because my original point still stands. To summarize: when keyboard focus is on the folder list, typing "." and expecting to jump to the Next Unread message instead opens a search box, even when no folder begins with "." (and how often does a folder begin with "."?). This is particularly annoying for those of us who never use keyboard selection to move between folders. A possible solution could be to make the search box progressive, i.e. don't accept the next character if the string entered so far doesn't match any folder prefix, just give some kind of error indication (the current behaviour in this case is to do nothing, even after hitting Return). In the special case of a leading ".", *also* do the Next Unread action (similarly for "," and Previous Unread).
Created attachment 134215 [details] [review] proposed evo patch for evolution; kinda hacky, though. I cannot do as much as you wrote in the previous comment, the auto-search is out in our hands, but I can force to disable it for some circumstances, as shown here. With respect to a leading dot in a folder name, it's not allowed within evolution, as far as I know. The other letters might be, but who does want such folder names?
seems fine to me.
Milan, I was fairly sure that a leading dot couldn't appear, not specifically because of Evo but because IMAP folders use "." as a separator. Given this, it seems even more perverse to read the "." as an attempt at a folder search which is *always* going to fail. I'm glad it's only taken 5 years or so to get this point across (no pun intended).
Created commit 7c8e817 in evo master (2.27.4+)
*** Bug 231991 has been marked as a duplicate of this bug. ***
Created commit 1f455a0 in evo master (2.29.2+) The fix got lost on kill-bonobo merge.