Lister (w/ plugins) on their own thread?

[Digika]

What are the architecture challenges of TC codebase that prevent this being a reality? Right now, if Lister doing some work whole TC has to wait, presumably because its functionality runs on the same thread. Is there any reason Lister can't be offloaded to a separate one?

[Horst.Epp]

Never had to wait for Lister in the rest of TC.
If needed you can use a separate thread by calling TC lister from the command line.

[petermad]

2Digika
You could make an em_command like this in your usercmd.ini file:

Code: Select all

[em_separatelister]
cmd=%COMMANDER_EXE% /i="%COMMANDER_INI%" /S=L
param=%P%N

And then put this code in the [Shortcuts] section of your wincmd.ini file:

Code: Select all

F3=em_separatelister

Then Lister will open in a separate instance when you press F3 on a file.

Notice that you can then no longer mark multiple files and open them in Lister and cycle between the selected files by pressing N or P or Alt+RightArrow or Alt+LeftArrow.

To work around that, you can change the option in "Configuration" -> "Options..." -> "Edit/View" -> "Viewer for F3" to: "Internal Viewer with file under cursor". Then you can use Shift+F3 to view multiple selected files - but not opened in a separat instance of Lister.

You cannot view files inside archives with F3, but here you can use Shift+F3 - but again not opened in a separat instance of Lister

[Digika]

This will essentially launch a new instance of TC in lister mode which is pretty bad workaround all around to be frank. Not being able to cycle between opened Lister windows is least of the issues.
Image: https://i.imgur.com/Fv8KKWb.png

[petermad]

It is not different from running for example TC's "Find Files" in a separate instance using Alt+Shift+F7 or cm_SearchStandalone.

Maybe Lister is not run in a separate thread, because plugins can not be known to be thread safe.