On Thu, 3 Oct 2013 15:07:17 +1000 <tpgww@xxxxxxxxxxx> wrote: > The rationale is - you select an item, then delete it, and then > there's nothing left that YOU selected. > > The filelist (treeview) cursor is still there, after the position of > the last-deleted item. An up- or down-arrow keypress will select the > next item in that direction. > > I know that some users prefer to always have something selected. You > may recall the config option to select first item in newly-opened > directories. Maybe we should relate to that, as a general policy for > the post-task state of each filelist. > > On the other hand, we can reasonably argue that renaming should not > remove the selection. Code to implement that is now in svn. > > And, oh joy, on gtk3 it still selects one item too many e.g. select > and rename 2 items, end up with 3 selected. > > I'm inclined to try to prevent that, even at the cost of removing the > post-deletion selection that you favour ! Sorry, but problem is not selected/not selected. Filelist position skips to the top when no item is selected but scrollbar stays on the right place. This is very annoying. Most file managers keeps filelist position when refreshing/deleting etc. And this is good. You can see well known Midnight Commander: 1/after deleting item(s), they removed from filelist and next to last deleted item is selected; 2/when renaming file, next to renamed one is selected and renamed file added to right place (maybe outside of visible items); 3/when creating new directory, filelist scrolls to that directory and select it in the centre of pane; 4/when refreshing, filelist always keeps position. Very useful) Sorry about bad English. -- Claws Mail version 3.8.1 Linux debian 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux -- Users can unsubscribe from the list by sending email to emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or by logging into the web interface.