My guess is that you need to re-read the qualifiers part in the main post.
Do you really want a path to be removed from the list and the counter to go down when it reopens? It's doable to implement, but I don't see how usefulness could be improved with that, tbh. Those of you using the script, leave me your opinions below.
FWIW, that script was a bit old, and I've updated it in a version I haven't released yet (as I was waiting for a response about showing system icons, hopefully this will be possible in a new Opus beta). This new version has real-time updates and the ability to open multiple paths without closing the dialog.
Well, yeah, i thought i close one tab, which gives me that count, and if i reopen it, it's done (thus removed), except i want to open that exact tab once more, sometime later. Depending on the usecase both could make sense.
Another thing, i often change tab groups, and that will increase the closed tab count a lot, so i'll end up with two figure numbers easily. Maybe changing tab groups should be disregarded for this reason (only "imo"). Anyway, i keep the script in Opus, and also will follow the updates. I believe in the swiss knife powers of Opus and the scripting thing.
A bit technical, but AFAIK there's no way to detect whether a tab was closed because you’re loading a Tabs Group or because you manually closed it. You can try changing how you load the group (using the NOSCRIPT flag, although I’m not sure it works). I noticed the same issue, so what I do is “pause” the script whenever I’m about to load a group, then unpause it afterward. But if that’s too much hassle, you could file a feature request with Jon/Leo to add a way to differentiate them via scripting.
The only other thing I could do is add a timer to auto-pause the script for a few moments to log tab closings so only the most recently closed tab is remembered. Of course, that would also be affected if you manually close tabs quickly.
On the other hand i only use tab groups in certain situations, so it's not a big deal. But yes, maybe i will ask them if there's a way to handle this special situation.
So last night I was updating the script for modern times, and the more I added, the more needed features appeared
New features/changes:
Real-time updates. If a tab closes while the dialog is open, the dialog will reflect that change immediately.
New options available from the dialog (as buttons, in the lower right corner, from left to right): Toggle pause, remove paths after reopening, remove invalid paths, keep dialog open. All act as toggles and respond in real time to external changes when necessary (e.g., if pause state is changed outside the dialog).
The dialog now follows the active Lister! This is truly useful since you only need one window to manage multiple Listers.
Fixed the issue with "shell" path types being counted as invalid when using LIST=checkifexist.
Maximum number of remembered tabs is capped at 50 to avoid potential problems from saving very large variables.
Added a workaround to avoid capturing tabs closed non-manually (e.g., as a side effect of a command that closes multiple tabs at once). By default, there's a small delay (100 ms) after a tab closes before it's registered. This delay can be disabled in the script configuration under delayed tab closing detection.
Script Config now has an option to suppress the invalid-path warning.
Now, by default—if no modifier keys are used—the path opens in a new tab, since the previous value seemed to confuse some users. You don't need to reconfigure this if you've already changed it.
The script now cleans up after itself when uninstalled (I forgot that this possibility existed).
There seems to be a problem with clearing the list in this version.
This is the button code I am using.
@eval:closed_tabs=IsSet("$lst:TabRescue_count") ? Val("$lst:TabRescue_count"):0;
@disableif:=closed_tabs==0
@label:closed_tabs
TabRescue LIST
This gives me a count of closed tabs in the label.
When the count is zero, the button is disabled and the default label of 0 is displayed.
When I clear the list, the button should become disabled and the label should be 0 .
This doesn't seem to be working in this version, but it did work in the previous versions.
After clearing the list, pressing the button again results in an error even though the button should be disabled.
2025-05-22 9:35:00 AM TabRescue: INFO => ===== TabRescue v2.0b1 =====
2025-05-22 9:35:00 AM TabRescue: DEBUG => TabRescue LIST
2025-05-22 9:35:01 AM TabRescue: DEBUG => check invalid : false
2025-05-22 9:35:01 AM TabRescue: DEBUG => keep status : false
2025-05-22 9:35:01 AM TabRescue: DEBUG => remove status : false
2025-05-22 9:35:01 AM TabRescue: DEBUG => Loading closed tabs list for 788440
2025-05-22 9:35:01 AM TabRescue: DEBUG => Max tabs : 15
2025-05-22 9:35:01 AM TabRescue: DEBUG => Saved tabs : 1
2025-05-22 9:35:01 AM TabRescue: DEBUG => event=selchange ; name=listview ; data=0 ; value=HP48 Libraries ; index=0
2025-05-22 9:35:09 AM TabRescue: DEBUG => event=focus ; name=filter ; data=false ; value= ; index=-1
2025-05-22 9:35:10 AM TabRescue: DEBUG => event=click ; name=clear_btn ; data=0 ; value=link ; index=-1
2025-05-22 9:35:10 AM TabRescue: INFO => ===== COMMAND FINISHED =====
2025-05-22 9:41:17 AM TabRescue: INFO => ===== TabRescue v2.0b1 =====
2025-05-22 9:41:17 AM TabRescue: DEBUG => TabRescue LIST
2025-05-22 9:41:17 AM TabRescue: ERROR => No saved tabs for this lister yet!
2025-05-22 9:41:17 AM TabRescue: INFO => ===== COMMAND FINISHED =====
That variable is written after the dialog is closed, as far as I remember. Previously, clearing the list would close the dialog. Now, there are several options that can keep the dialog open after the clearing.
I guess I can change that.
Looking more closely at your log, it seems that the dialog was no longer open at that time, but for some reason that variable isn't updating. I'll keep an eye on that later. Thanks for the log and the feedback!
Ok. I was reviewing this and it seems like a real slippery slope.
@David forget about the dialog entirely for a moment and try this:
Open a tab with a path you know isn't in TabRescue's list for that Lister.
Close the tab — you'll notice the counter doesn't change.
Now try editing your button, but don't change anything — just open and close the edit dialog.
You should now see the counter update correctly.
It looks like the way I handle Lister variables isn't playing well with the Evaluator, and it's not able to update its data automatically.
And since making a proper bug report about this (if it is a bug) would mean isolating the issue in a smaller reproducible example, etc, for now all I can do is to drop the workaround that avoids capturing tabs closed non-manually (in here is inevitable), as well as make some changes where I was doing something similar (like clearing the list). Is that or just drop support for the counter var . Sorry for the inconvenience!
Maybe I'll upload an update later with a version where the counter works properly for the Evaluator, though that'll mean losing the ability to avoid capturing non-manually closed tabs and a few other things.
Is there a way to reopen a tab in the original file display (left or right)? So it would be open on the left side, when it was closed there, even if the active side is on the right now.
Thanks!
Please try this version, I've added some workarounds to show the correct icon for at least some paths. It won't work in 100% of cases, but IMHO it's better than nothing!
. Sorry for the inconvenience!
