There's a new emelfm2 pre-release for your evaluation at http://emelfm2.net/DownLoads Some user-visible changes, some infrastructure changes, and bugfixes. Changelog at http://emelfm2.net/ChangeLog. The biggest single change is to make all operations on selected items (so-called "file operations") happen in a separate thread, asynchronously. Most of those operations (except info, view(again), edit(again), open(with)) are actually placed into a queue, and executed from there. This is another step towards future support for "slow" operations like ftp. This change also provides the main risk of bad behaviour - not a risk to your files (the backend functionality is essentially the same) but risk of UI freeze. I'm particularly interested to hear from those of you with multi-CPU/core hardware, which conceivably might handle some things in a different order, causing such freezes. Now that we have a queue, we also have actions and bindings to list history and waiting items. These complement the (running) children list. Our valiant tester Liviu has recently reported some poor behaviour, which I cannot replicate nor track down, so any advice on the following will also be most welcome: 1. Sometimes screen freezes when unrecognised filetype dialog is shown. 2. Editing an item with the internal editor as super(root) user causes a freeze. 3. Sometimes selecting text in the internal viewer freezes temporarily. 4. Running the disk-usage plugin (file.du action) on a symlink can cause a freeze. 5. Sometimes opening an item (file.open action) does not work. 6. When in a re-visited directory, pressing an arrow key to move the focus in a filelist can move to the wrong line. Regards Tom -- 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.