XYplorer Beta Club

Since I've been playing around with scripts, there are a few things that I wish XY did (or did differently), so I thought I'd mention them here for what it's worth.


1. Native support for looping through a list of selected items.

I know that Jacky created a workaround script, and it's works nicely. I'm just saying that this is a basic need that XY should support natively.


2. Remove indendation as an identifier.

I strongly dislike the fact that XY uses indentation to determine what belongs to what in a script. It's easy to mess up by mistake, and it gets in the way of people who have their own system of indenting to organize their code. XY should follow the standard that many programming languages use, and follow a brace delimited format. For example:


3. Full support for conditionals.

This refers to supporting If/Else, For, While, etc... This is somewhat related to Item 2, because support for these items requires the ability to parse brace delimited sections of code.



Anyway, that's my list of major scripting requests for the moment. I don't know how much of this was already on Don's To Do list - all I could see was "Scripting 2.0", Scripting 3.0", etc...

1 and 3 will come in time.

2, I'm torn. I use to prefer the brace way as well, and still do to an extent. But after learning some Python using whitespace is starting to grow on me.

TheQwerty wrote:
1 and 3 will come in time.

2, I'm torn. I use to prefer the brace way as well, and still do to an extent. But after learning some Python using whitespace is starting to grow on me.

I've always liked managing my own whitespace. I use it to differentiate different levels and sections of code, but that becomes a lot more complicated as soon as it's parsed. Something as simple as loading source code in a different app might cause the whitespace to change, but no text editor is going to insert or remove braces on its own.

Mesh wrote:

TheQwerty wrote:
1 and 3 will come in time.

2, I'm torn. I use to prefer the brace way as well, and still do to an extent. But after learning some Python using whitespace is starting to grow on me.

I've always liked managing my own whitespace. I use it to differentiate different levels and sections of code, but that becomes a lot more complicated as soon as it's parsed. Something as simple as loading source code in a different app might cause the whitespace to change, but no text editor is going to insert or remove braces on its own.

I agree. But the function blah (args) {body;} syntax depends on the keyword function which I currently don't have in XY scripting. So there is no clearly defined beginning of a section.

admin wrote:
I agree. But the function blah (args) {body;} syntax depends on the keyword function which I currently don't have in XY scripting. So there is no clearly defined beginning of a section.

I understand, but for what it's worth, I think it would be an improvement to XY's scripting to incorporate that. The keyword / brace delineation structure is necessary for XY's scripting to evolve beyond the basics. You can't have proper support for conditionals without it, and once it's in, you might as well use it everywhere it would be a benefit to.

Conditional scripting would be great addition to XY's scripting and that would not be possible without { }

Don't worry. There will be Conditional Statements and Looping Statements and there will be curly braces. It's on my list since long.

admin wrote:
Don't worry. There will be Conditional Statements and Looping Statements and there will be curly braces. It's on my list since long.

Excellent! Thank you, Don.

I was wondering if there had been any progress in regards to this wishlist. Working with XY's scripting, I found myself wishing for the exact same list of items. But I've been inactive for scripting for a little while, so I don't know if any of this has been addressed or not.

Demset wrote:I was wondering if there had been any progress in regards to this wishlist. Working with XY's scripting, I found myself wishing for the exact same list of items. But I've been inactive for scripting for a little while, so I don't know if any of this has been addressed or not.

It's all there now.

admin wrote:
It's all there now.

Really? The help file still lists the following:

----------
One script can run over multiple lines. Simply indent the lines after the first line using any number of space or tab characters.
----------


That would imply that whitespace is still not freeform.

In addition, I just went through the entire command reference, and didn't find any command that allowed you to loop through a list of selected items.


Obviously, I'm missing something.

Mesh wrote:

admin wrote:
It's all there now.

Really? The help file still lists the following:

----------
One script can run over multiple lines. Simply indent the lines after the first line using any number of space or tab characters.
----------


That would imply that whitespace is still not freeform.

In addition, I just went through the entire command reference, and didn't find any command that allowed you to loop through a list of selected items.


Obviously, I'm missing something.

I referred to "There will be Conditional Statements and Looping Statements and there will be curly braces. "

admin wrote:
I referred to "There will be Conditional Statements and Looping Statements and there will be curly braces. "

Actually, that wasn't clear from your post. Demset was asking about the whole list of items, and you replied by saying "it's all there now". I'm sure you can understand my confusion.

Since this thread is being discussed again, I wanted to point out that I think it makes it unnecessarily complicated that a script file can be a library of scripts.

I think each script file should be a single script, which executes as a whole. This becomes more feasable once XY supports creating your own functions. But once that's in place, I think we should get rid of the whole "script library" idea. Not only won't there be a need for it anymore, but it also makes it easy to get rid of the parsed whitespace issue.


I wonder whether it would be easier to have XY's scripting use Javascript as it's core language. That would address most of these issues, and take issues of language syntax out of Don's need to recalculate, now and then. UltraEdit's scripting works that way, and it makes things tidy, yet flexible.

Mesh wrote:
I wonder whether it would be easier to have XY's scripting use Javascript as it's core language. That would address most of these issues, and take issues of language syntax out of Don's need to recalculate, now and then. UltraEdit's scripting works that way, and it makes things tidy, yet flexible.

Oh, that would be sweet! I second this!