getinfo, newtab, closetab, ...

[jacky]

Quick things:

- Could it be possible to have a new function getinfo, with the same syntax as command getinfo only without the first param (<variable>) ? Well actually I'm sure you know many commands could use functions by the same name, the substr, strpos, replace, etc

- Why are the names (CountSelected, etc) case sensitive for getinfo ? My question being, why are those case-sensitive, yet those for setting(p) are case-insensitive... maybe it'd be better to keep consistent and have all be the same, no?

- I would love to get a new info: SelectedItemsNames (no path)

- I'd love a new command newtab [<location>][, b] to open a new tab, with params for location of the new tab, and maybe an option to open it in the back. I'd also love a command closetab to do just that, close the current tab. This would be really useful to me, because I often need in scripts to go to a place only to gather info or select items to do something with them, and to ensure current location & selection isn't affected I always #340; goto $path; do_stuff; #351; but actual commands would be better, and save me from going to CKS copy those damn IDs each time

- And I just realized that in order to use such a trick in scripts, setting(p) should probably have "MaxTabs", "OpenTabNextToCurrent", "ActivateLeftOnClosingTab" otherwise results can be not the expected ones!

[TheQwerty]

- I'd love a new command newtab [<location>][, b] to open a new tab, with params for location of the new tab, and maybe an option to open it in the back. I'd also love a command closetab to do just that, close the current tab. This would be really useful to me, because I often need in scripts to go to a place only to gather info or select items to do something with them, and to ensure current location & selection isn't affected I always #340; goto $path; do_stuff; #351; but actual commands would be better, and save me from going to CKS copy those damn IDs each time

- And I just realized that in order to use such a trick in scripts, setting(p) should probably have "MaxTabs", "OpenTabNextToCurrent", "ActivateLeftOnClosingTab" otherwise results can be not the expected ones!

I had requested similar commands previously.

Two more I had wanted were:
RenameTab([Name]); this seems pretty obvious.
And a way to retrieve the number of the active tab for later use by SelTab();

I also think CloseTab() may need arguments to allow closing Home and/or Locked tabs without prompt.

[jacky]

Yeah I know, and I'm pretty sure I wished for those in the past myself as well.

renametab could be nice yes, as for a getinfo "CurrentTab" or something, I was actually thinking of that at first, but forgot as I went on to setting(p) additions... But it would be useful as well, yes.

About closetab though, I'm not sure: do we really want a script to have the ability to close a homed/locked tab without any sort of warning ? I'm really not sure. If it's a tab created by the script, and locked using #ID; then the script can unlock it first as well; and if it's not the case but a user-locked tab, I'm not sure a script should be able to close it without confirmation...

[TheQwerty]

About closetab though, I'm not sure: do we really want a script to have the ability to close a homed/locked tab without any sort of warning ? I'm really not sure. If it's a tab created by the script, and locked using #ID; then the script can unlock it first as well; and if it's not the case but a user-locked tab, I'm not sure a script should be able to close it without confirmation...

Yes I considered this, but we already give scripting the ability to delete files without any prompt whatsoever, this isn't more dangerous.

Frankly, if CloseTab() has no arguments, I think it would be wasteful to implement it. I'm sure Don has user created functions just around the corner, so why bloat XY with alias commands that just point to the #ID; at that point? As such SwapNames() should probably be removed or given arguments as well.

EDIT: The same could be said about NewTab(), but I'm imaging NewTab() would at least have a location argument, if not a few others as well.

[serendipity]

I'm sure Don has user created functions just around the corner, so why bloat XY with alias commands that just point to the #ID; at that point? As such SwapNames() should probably be removed or given arguments as well.

Add try() to the list it can be got from #752 too.

[jacky]

Yes I considered this, but we already give scripting the ability to delete files without any prompt whatsoever, this isn't more dangerous.

I can't really say i disagree, cause obviously loosing files and tabs isn't the same, but I "disagree". Because to me there's an important difference : when I run a script, I expect it to copy/move/delete/etc files or whatever I expect from the script, yes affecting files is potentially dangerous, but it's also what we expect from a script.
On the other hand, I don't want a script to change my toolbar or affect my GUI, and if it needs to open tabs and close them afterwards, fine, but I can't see why I'd ever want a script to close a tab I took the time to lock.

As a result, as odd as it may sound, I would say that, yes, giving script the ability to close locked tabs without confirmation is "more dangerous" than allowing to delete files. Because while the later might be the intent of a script, there's no reason the former should be a script's intent, when that would mean find and "destroy" what the user did. Or, you know, that's my opinion on this.

Frankly, if CloseTab() has no arguments, I think it would be wasteful to implement it. I'm sure Don has user created functions just around the corner, so why bloat XY with alias commands that just point to the #ID; at that point?

Well I disagree here, creating an alias isn't necessary bloat. To create aliases for all possible commands of XY would be, yes, but the requirements to create a new command shouldn't be just a need for parameters, but the actual use. If a command could be useful, used "often" and/or by many, why not add it?
If we have opentab (with location and maybe background as params) it'd be "odd" not to have a closetab. Why force people to always have to go look for an #ID when a simple command could do it. Makes scripts easier to write, as well as to read, plus it makes it go to the safe class 0 And there could easily be a parameter closetab [<position>]

[j_c_hallgren]

so why bloat XY with alias commands that just point to the #ID; at that point?

Well I disagree here, creating an alias isn't necessary bloat. To create aliases for all possible commands of XY would be, yes, but the requirements to create a new command shouldn't be just a need for parameters, but the actual use. If a command could be useful, used "often" and/or by many, why not add it?

I'm of a slightly different opinion here...I think that having some short text alias of almost all cmds would not be bloat, as it would greatly increase readability of scripts by new/old users, plus making coding easier! I was under the impression (maybe incorrectly?) that the #ID was an interim step and that at some future point, there would be text aliases.

Right now, if I see a script with these #ID's, unless it's well commented, it's not easy to see what it's doing in some cases, whereas if there were text aliases, even condensed, it would help.

Back in my early days of mainframe, I had to do some on-line programming in assembler...the max length of a symbol/name was 8 chars so we had to be quite creative, as was IBM...the one oddly sounding symbol that stuck with me all these decades was FWACBAR!
(File Work Area - Control Base Address Register)...so if they/IBM could put all those words in 8 chars, I'm sure we can do something similar.

[TheQwerty]

I can't really say i disagree, cause obviously loosing files and tabs isn't the same, but I "disagree". Because to me there's an important difference : when I run a script, I expect it to copy/move/delete/etc files or whatever I expect from the script, yes affecting files is potentially dangerous, but it's also what we expect from a script.
On the other hand, I don't want a script to change my toolbar or affect my GUI, and if it needs to open tabs and close them afterwards, fine, but I can't see why I'd ever want a script to close a tab I took the time to lock.

As a result, as odd as it may sound, I would say that, yes, giving script the ability to close locked tabs without confirmation is "more dangerous" than allowing to delete files. Because while the later might be the intent of a script, there's no reason the former should be a script's intent, when that would mean find and "destroy" what the user did. Or, you know, that's my opinion on this.

And like you I can't say I disagree with your opinion, or that I have a pressing need to Close locked tabs via script. However, if I did, it would be nice to already have the option.

We've concluded multiple times that protection from the dangers of scripting has to be the user's responsibility. When someone offers up a solution that offers all desired functionality and security with minimal effort from Don, we'll be set, but until then we've pretty much agreed Stepping through potentially dangerous or untrusted scripts is the safest we can be right now.

Frankly, if CloseTab() has no arguments, I think it would be wasteful to implement it. I'm sure Don has user created functions just around the corner, so why bloat XY with alias commands that just point to the #ID; at that point?

Well I disagree here, creating an alias isn't necessary bloat. To create aliases for all possible commands of XY would be, yes, but the requirements to create a new command shouldn't be just a need for parameters, but the actual use. If a command could be useful, used "often" and/or by many, why not add it?
If we have opentab (with location and maybe background as params) it'd be "odd" not to have a closetab. Why force people to always have to go look for an #ID when a simple command could do it. Makes scripts easier to write, as well as to read, plus it makes it go to the safe class 0 And there could easily be a parameter closetab [<position>]

And again I can't argue the convenience of having such commands, or the awkwardness of having NewTab() without a CloseTab(). But one of the problems with such alias commands is that they open the door to people requesting more for other #IDs; that they use commonly, and then each case would have to be evaluated.

I think a good compromise would be a way to include a header/common script for functions that would be used when a script references a function or command that XY doesn't recognize or can't find. Don could include a default sample, which would provide aliases for a number of the #ID; commands (I've been meaning to write such a thing already, so I'd volunteer to help). Now while this may not remove the bloat from an install of XY, it does allow a user to remove it (and modify it) as they desire. Although it would be a separate file that Don would have to maintain I believe it would be easier than including such things in the source of XY.


To be honest, I'm not opposed to a CloseTab() command with no arguments. I would just prefer if there were a better and more flexible solution available for naming any #ID command, and I'm sure you will agree with that.

[jacky]

I'm of a slightly different opinion here...I think that having some short text alias of almost all cmds would not be bloat, as it would greatly increase readability of scripts by new/old users, plus making coding easier!

Well, I guess I wouldn't be against it, but I'm not for it either. I'm sure many commands are barely used and don't need an alias. For instance, I'm not sure we need an alias for all commands to change List Style & Tree Style, etc because that's not really something you do often, or that would be very useful/required by a script. For such things, I think #IDs; are just fine, but for commands likely to be used or that do serves a purpose, like I believe would be the case for opentab & closetab, then aliases are good.

We've concluded multiple times that protection from the dangers of scripting has to be the user's responsibility. When someone offers up a solution that offers all desired functionality and security with minimal effort from Don, we'll be set, but until then we've pretty much agreed Stepping through potentially dangerous or untrusted scripts is the safest we can be right now.

Yes, but that's not what I'm talking about here. Or, to me, it feels a different thing. Because for a script to do file operations makes total sense in my mind, that's kinda the whole point : I start the script, it does the work.
But closing a tab a manually locked isn't a script doing work, but interfering with my UI, because I can't see why a script would need to close a tab I locked in order to do anything, it's not like deleting a file without confirmation, at least to me it's really different.

I think a good compromise would be a way to include a header/common script for functions that would be used when a script references a function or command that XY doesn't recognize or can't find.

Well, truth be told, if/when Don adds support for functions I'll be happy to make my own opentab function and simply use an include command. Oh yeah, we'll definitely need a command include <file> to include user functions, obviously. Then anyone can create his own aliases easily...

As for such a file, I'm not sure, because then you can't share scripts easily, you'd need to make sure your and the other person's file are in sync. Better wait for user functions & include I'd say...

[TheQwerty]

Yes, but that's not what I'm talking about here. Or, to me, it feels a different thing. Because for a script to do file operations makes total sense in my mind, that's kinda the whole point : I start the script, it does the work.
But closing a tab a manually locked isn't a script doing work, but interfering with my UI, because I can't see why a script would need to close a tab I locked in order to do anything, it's not like deleting a file without confirmation, at least to me it's really different.

And that's the problem: you're taking a short-sighted view of scripting being limited to file operations. For instance, I have some scripts that do nothing more than change the layout of XY for specific tasks (Picture viewing mode -> Maximize XY, Enable thumbnails and Maximized Preview Pane). I had a script that changes the opens tabs between a few different projects (before the Catalog had such functionality). I filled a request for one to do cycling of the Tree & Catalog via CKS. There's the script in the forums for changing the Catalogs, or even your own script for easily changing INI tweaks. Scripting is useful for so much more than just file operations, and to quibble that closing locked tabs is worse than deleting files sans prompt just boggles my mind.

In the end, it's exactly the same as the security debate we've had over and over, and as I said, the end result for now is if you don't trust the script, step through it.

As for such a file, I'm not sure, because then you can't share scripts easily, you'd need to make sure your and the other person's file are in sync. Better wait for user functions & include I'd say...

It wouldn't need to be any more difficult than it would be now. There's no difference in having an old version of such a file and having a version of XY that doesn't yet have support for CloseTab(). The only problem would be if you decided to change that file, and really at that point I feel it's the user's error.

[j_c_hallgren]

Been reading this back/forth and thinking some more...

There are a number of #ID's which may well be rarely used and which could easily also lend themselves as opt/param on another command instead of a unique cmd, so adding those as unique could be called bloat, but as I wrote, having some short text alias should not be that much memory/space and thus bloat, IMO.

This could be optimized at a later date, but for now, maybe there could be a way to have a combination of both #ID and alias such as #frenuc instead of #128 (File>Rename>Upper Case)?

The cross reference between the #text and #ID could be in an external table that could be loaded via some existing method.

[jacky]

Okay, so bumping this after this nice little chat cause there were some nice ideas/wishes here methinks

Also, I'd like to add one : a new option for inputfile to allow for multiple file selection (returned as a |-separated list). I have a "Copy Here From" script and I'd love to be able to copy more than one file in a row

[admin]

Okay, so bumping this after this nice little chat cause there were some nice ideas/wishes here methinks

Also, I'd like to add one : a new option for inputfile to allow for multiple file selection (returned as a |-separated list). I have a "Copy Here From" script and I'd love to be able to copy more than one file in a row

No time. Save it for later.

[jacky]

No time. Save it for later.

Adding to the list : I'd love this getinfo supports a new one, "template" or "report" or something like that. The second parameter would then be a template which could contain variables: the usual <curname>, <curbase>, <curver>, <datec>, <datem>, etc
The idea being that this "template" would be processed for each of the selected items and then returned (so with "file <curname>;" as tpl we would get e.g. "file name.ext;file another-one.ext;"). A very easy way to get a group of info about many files at once. Right now to do so I have to either loop through selected items which is a PITA, or rely on "To Clipboard|Selected List Row(s)" which is also not good, because it uses the clipboard, needs regexp to "extract"/format info, and also if I ever change to use another Report meanwhile it becomes a mess.
Here each script could use its own template, no clipboard, much much better!

I would also ask for a few more variable, specifically <cursize> for each item's size. Should probably be like date variables, a default format but another one could be specified (e.g. <cursize> (raw), <cursize b> (bytes), <cursize fr> (Flexible Rounded), etc) Would be pretty useful (to me).

[admin]

No time. Save it for later.

Adding to the list : I'd love this getinfo supports a new one, "template" or "report" or something like that. The second parameter would then be a template which could contain variables: the usual <curname>, <curbase>, <curver>, <datec>, <datem>, etc
The idea being that this "template" would be processed for each of the selected items and then returned (so with "file <curname>;" as tpl we would get e.g. "file name.ext;file another-one.ext;"). A very easy way to get a group of info about many files at once. Right now to do so I have to either loop through selected items which is a PITA, or rely on "To Clipboard|Selected List Row(s)" which is also not good, because it uses the clipboard, needs regexp to "extract"/format info, and also if I ever change to use another Report meanwhile it becomes a mess.
Here each script could use its own template, no clipboard, much much better!

I would also ask for a few more variable, specifically <cursize> for each item's size. Should probably be like date variables, a default format but another one could be specified (e.g. <cursize> (raw), <cursize b> (bytes), <cursize fr> (Flexible Rounded), etc) Would be pretty useful (to me).

Great idea!! Bump me later.