will scripting work on different configs?

[jacky]

I disagree when it comes to normal conditions. If XY automatically resets anything changed in a script then I can't write a script that just changes settings, and I as a script writer will become very frustrated with that.

I wouldn't call that "normal conditions", as I think such conditions would have a script to only change settings temporarly to ensure it can be what must be done, but then restore whatever config the user had set.
Anyways, that's why I originally thought that the function to change a setting could also, optionally, be "permanent".

Okay, I agree with everything (minus the confusion and the rubbish -- kidding). What about this: I add a variant command to "setting" called "setting_temp" or "settingT" or "settingR" (for restore). All settings set using this variant will be auto-reset when the script ends (or is cancelled at any point).

Or simply you add an additional parameter: [, |p]
- empty : it's a temporary thing, ie. reset when script execution is over (no matter how)
- p : it's "permanent", ie. not reset after script execution

[TheQwerty]

I wouldn't call that "normal conditions", as I think such conditions would have a script to only change settings temporarly to ensure it can be what must be done, but then restore whatever config the user had set.
Anyways, that's why I originally thought that the function to change a setting could also, optionally, be "permanent".

Normal conditions to me are, it completed the script successfully and did what the script told it to.

As a user and script writer, if I wrote a script "::ShowSystemItems 0::ShowHiddenItems 0", I'd expect to not see System and Hidden items regardless of how they were before I executed the script.

Okay, I agree with everything (minus the confusion and the rubbish -- kidding). What about this: I add a variant command to "setting" called "setting_temp" or "settingT" or "settingR" (for restore). All settings set using this variant will be auto-reset when the script ends (or is cancelled at any point).

Or simply you add an additional parameter: [, |p]
- empty : it's a temporary thing, ie. reset when script execution is over (no matter how)
- p : it's "permanent", ie. not reset after script execution

Don do you mean we'll have "::AutoRefresh" and "::AutoRefreshT/R/whatever?"

Or do you mean we'll have a generic, "::SettingsT" which makes all following settings temporary?

[jacky]

Normal conditions to me are, it completed the script successfully and did what the script told it to.

Ok, but "normal conditions" doesn't mean the command ::setting should have settings to stick, or to be restored. That behavior depends on the command itself, its definition.
What I meant by "normal conditions" was more of a "most of the time" thing, and I think most of the time, scripts might need to set settings to ensure they can do what they need to, but once done the user expects the altered settings to be restored. One may have a script to change some settings, and have them stick that way, but that would be the "exceptional conditions", so then an extra parameter to force that behavior seems normal. (All that is acc. to me, of course.)

Don do you mean we'll have "::AutoRefresh" and "::AutoRefreshT/R/whatever?"

Or do you mean we'll have a generic, "::SettingsT" which makes all following settings temporary?

No he means the later, one command to set settings temporary, and another one for them to stick. Settings name are parameters, of course.

[TheQwerty]

but once done the user expects the altered settings to be restored.

And that's where we need to agree to disagree.

Or at least agree to disagree on the default methodology. I agree a user running a random script would expect their settings to remain unchanged, but I believe that should be the script writer's problem.

No he means the later, one command to set settings temporary, and another one for them to stick. Settings name are parameters, of course.

Ah ha! So they are! Guess I needed to read today's beta post a little closer.

[PeterH]

If I understand you right, I'm with jacky: if I have a script, that doesn't change settings explicit for me, it should *never* leave changed settings - not matter, how it ends. And if it ends due to an error, script-logic might have no chance to restore kind of "saved settings".
So if a script changes any settings just for internal function, I think XY should restore these settings after end of script.
If a scipt has to do settings "for the outside" - I think it should "declare" this by any way, like a modifyer etc.

At least for scripts designed on different systems, but maybe for all scripts it *might* be quite good to start in kind of "default settings"? (Too bad, if in 6 months you change a long used setting - and some scripts will stop to function?) Here at least I think it would be normal, that settings in the script are only internal, by default, and would only be made external by request?

[admin]

Or simply you add an additional parameter: [, |p]
- empty : it's a temporary thing, ie. reset when script execution is over (no matter how)
- p : it's "permanent", ie. not reset after script execution

Yes, that's cleaner. I was tempted to do "settingT" because it gives a shorter line, but since the temporary version is for probably most users/cases the likely one, an additional parameter [, |p] is clearly better (and less ugly).

I think that's a good solution now. Each script should care for its necessary preconditions and how it leaves the place when done. Are there any open points?

[serendipity]

Or simply you add an additional parameter: [, |p]
- empty : it's a temporary thing, ie. reset when script execution is over (no matter how)
- p : it's "permanent", ie. not reset after script execution

Yes, that's cleaner. I was tempted to do "settingT" because it gives a shorter line, but since the temporary version is for probably most users/cases the likely one, an additional parameter [, |p] is clearly better (and less ugly).

I think that's a good solution now. Each script should care for its necessary preconditions and how it leaves the place when done. Are there any open points?

Sounds good to me. By the way, this means one can switch ON/OFF some config settings with one one key. Thats quite something . Do you plan to extend this to all configs or just the ones that affect script?

[admin]

Or simply you add an additional parameter: [, |p]
- empty : it's a temporary thing, ie. reset when script execution is over (no matter how)
- p : it's "permanent", ie. not reset after script execution

Yes, that's cleaner. I was tempted to do "settingT" because it gives a shorter line, but since the temporary version is for probably most users/cases the likely one, an additional parameter [, |p] is clearly better (and less ugly).

I think that's a good solution now. Each script should care for its necessary preconditions and how it leaves the place when done. Are there any open points?

Sounds good to me. By the way, this means one can switch ON/OFF some config settings with one one key. Thats quite something . Do you plan to extend this to all configs or just the ones that affect script?

No.

[admin]

Or simply you add an additional parameter: [, |p]
- empty : it's a temporary thing, ie. reset when script execution is over (no matter how)
- p : it's "permanent", ie. not reset after script execution

Yes, that's cleaner. I was tempted to do "settingT" because it gives a shorter line, but since the temporary version is for probably most users/cases the likely one, an additional parameter [, |p] is clearly better (and less ugly).

I've implemented this now. And seeing it I think my first idea of having a variant command was not so bad. The additional p argument makes scripts harder to write and read. A new command "settingp" for permanent settings does look good to me. Compare:

::setting HideFoldersInList, , p::msg Look!
::setting HideFoldersInList, 0, p::msg Look!

versus

::settingp HideFoldersInList::msg Look!
::settingp HideFoldersInList, 0::msg Look!

Hm?

[jacky]

I've implemented this now. And seeing it I think my first idea of having a variant command was not so bad. The additional p argument makes scripts harder to write and read. A new command "settingp" for permanent settings does look good to me. Compare:

::setting HideFoldersInList, , p::msg Look!
::setting HideFoldersInList, 0, p::msg Look!

versus

::settingp HideFoldersInList::msg Look!
::settingp HideFoldersInList, 0::msg Look!

Hm?

You know what, I don't know. I get that with the first paramater is omitted it may look "better" with a different command, but I'm not sure. I think I like the first one better, which doesn't seem any harder to read/write to me, but that's me
Besides, why would anyone not have that first parameter ? It's safer/better/easier to read with it!

Plus, all I can really see here is that there seem to be a command msg !

[admin]

I've implemented this now. And seeing it I think my first idea of having a variant command was not so bad. The additional p argument makes scripts harder to write and read. A new command "settingp" for permanent settings does look good to me. Compare:

::setting HideFoldersInList, , p::msg Look!
::setting HideFoldersInList, 0, p::msg Look!

versus

::settingp HideFoldersInList::msg Look!
::settingp HideFoldersInList, 0::msg Look!

Hm?

You know what, I don't know. I get that with the first paramater is omitted it may look "better" with a different command, but I'm not sure. I think I like the first one better, which doesn't seem any harder to read/write to me, but that's me
Besides, why would anyone not have that first parameter ? It's safer/better/easier to read with it!

Plus, all I can really see here is that there seem to be a command msg !

Okay, I opted for the "Cologne solution" anyway: not either-or but both!

[TheQwerty]

Well if you're going this route then, I think a separate command that defines how to treat all following ::Settings would be the cleanest.

::SettingMode [Temp|Perm]

//These settings are temporary
::SettingMode
::Setting HideFoldersInList 1
::Setting ShowFloppies 0

//These settings are permanent
::SettingMode Perm
::Setting ShowHiddenDrives 1
::Setting ShowNethood 0

//These settings are also temporary
::SettingMode Temp
::Setting SortNatural


Few additions:
I think having a command (::RestoreTempSettings) to force a restore of the temporary settings would still be useful.

And I'd like to see an additional parameter in ::Setting that toggles it the state of that setting.

EDIT: Meh too late to clean up the mess you two are making.

[PeterH]

I like the mess...

I like settingp
and even more I like both
and most of all I like the automatic reset.

In most cases I expect that setting will be used - only in special situations settingp?

Another thing: is there yet a peace of documentation for scripting? Especially a problem ist names of operands for commands, their defaults, etc? I see that's there much change in that area, but just a little table would help a lot.

[admin]

I like the mess...

I like settingp
and even more I like both
and most of all I like the automatic reset.

In most cases I expect that setting will be used - only in special situations settingp?

Another thing: is there yet a peace of documentation for scripting? Especially a problem ist names of operands for commands, their defaults, etc? I see that's there much change in that area, but just a little table would help a lot.

Of course, the Pan Galactic Gargle Blasting XYwiki is your best friend:
http://88.191.26.34/XYwiki/index.php/Category:Scripting

Thanks to jacky, the fearless wiki master!


PS: a nice thing about the p-argument variant is that you can put a variable in the place of the "p":

::setting blah, 1, $perm

Somebody will find a real use for this...

[admin]

Well if you're going this route then, I think a separate command that defines how to treat all following ::Settings would be the cleanest.

::SettingMode [Temp|Perm]
...

Okay, looks clean. But what (else) is won by it? I don't see a realistic situation where one would want to switch the setting mode for all settings of a particular script.