XYplorer Beta Club

Since I don't work that often with textfiles, I didn't wanna spend the money for UltraEdit or EditPadPro, but still liked the idea of syntax coloring when writing scripts for XY, that's when I remembered that I had downloaded a free code editor some time ago called Proton. Then I dug into it to figure out, how to create a syntax highlighting scheme for it, and finally did it. (Needed the Phase5 HTML editor to do it, but that one's for free as well, if you're only using it to create a private webpage)

You can download Proton from various sources, and the nice thing about it is, it's portable and doesn't need an installation. (version 3.3 is suspected to be buggy, so better opt for 3.2; the only downside for some of you might be the German menu)

Then all you need is the following syntax scheme: Get rid of the xys extension (I wasn't allowed to attach a .sch file)
Place the file in the subfolder syntaxschemes of your Proton folder
Start Proton and edit the syntax binding in menu "Ansicht" / "Bindungen: Dateiendung->Parser"
Add the following line there "xys=XYplorer Script" and save it.

Now you're ready to go, you might even add a POM to open your "xys>X:/.../Proton", which will open Proton with the correct syntax scheme whenever you dblclick a script file.

Great, thanks for digging into it!

Just out of curiosity, the syntax scheme for Proton was downloaded 14 times, so I was wondering, whether anybody is actually using it.
If yes I might dig into it again and incorporate all the new script functions that were added since it was first published.
Otherwise I might as well drop that project and do more important things...

No response is an answer as well!
I think it's safe to assume, nobody is actually using Proton (anymore).
Since Proton doesn't support unicode and a couple of the newer scripts posted in Script Exchange were UTF-16, I was looking for an alternative myself...

...and I am quite happy so far with PSPad.

Now, the syntax files for PSPad in LL (initially created by JustinF, who btw seems to have disappeared from this forum) were a bit outdated.
I started to incorporate all the changes in scripting commands since Oct 2008 (quite an impressive changelog btw) and will send the new files to Don once I'm done with it.

I was wondering, whether Don or anybody else got a list of scripting commands that are still supported but not anymore documented in help (like the pre-function version of getkey) or do I have to - even further back in time - check the changelogs to find the ones, that haven't been deprecated?

It would just make sense to have these commands highlited as well when editing script files...

RalphM wrote:No response is an answer as well!
I think it's safe to assume, nobody is actually using Proton (anymore).
Since Proton doesn't support unicode and a couple of the newer scripts posted in Script Exchange were UTF-16, I was looking for an alternative myself...

...and I am quite happy so far with PSPad.

Now, the syntax files for PSPad in LL (initially created by JustinF, who btw seems to have disappeared from this forum) were a bit outdated.
I started to incorporate all the changes in scripting commands since Oct 2008 (quite an impressive changelog btw) and will send the new files to Don once I'm done with it.

I was wondering, whether Don or anybody else got a list of scripting commands that are still supported but not anymore documented in help (like the pre-function version of getkey) or do I have to - even further back in time - check the changelogs to find the ones, that haven't been deprecated?

It would just make sense to have these commands highlited as well when editing script files...

I would not hightlight deprecated stuff.

I initially thought so as well, but now I think it makes life easier when all valid commands are treated the same way, don't you think?
That way you get a visual confirmation that sth is wrong with the command you thought was still valid, but isn't anymore...

RalphM wrote:I initially thought so as well, but now I think it makes life easier when all valid commands are treated the same way, don't you think?
That way you get a visual confirmation that sth is wrong with the command you thought was still valid, but isn't anymore...

Deprecated stuff can be removed without warning at any point...

Without warning?! That's not really fair towards your "co-programmers" coding scripts to complement or enhance XY.

I'm not scripting that much myself but if I do, I don't use deprecated commands, but some of the scripting gurus still prefer the old ways sometimes...
So trying to make sense out of those scripts gets really hard without visual support, me thinks.

RalphM wrote:Without warning?! That's not really fair towards your "co-programmers" coding scripts to complement or enhance XY.

I'm not scripting that much myself but if I do, I don't use deprecated commands, but some of the scripting gurus still prefer the old ways sometimes...
So trying to make sense out of those scripts gets really hard without visual support, me thinks.

In theory without warning. But of course I will warn.

RalphM wrote:Now, the syntax files for PSPad in LL (initially created by JustinF, who btw seems to have disappeared from this forum) were a bit outdated.

Oh, I'm still here...I lurk the forums pretty much every morning. I just don't have anything interesting to say.

Regarding the PSPad syntax files...I just couldn't (or more realistically, didn't want to make time to) keep them updated with all the changes that were(are) happening. Thanks for taking this on!

RalphM wrote:Without warning?! That's not really fair towards your "co-programmers" coding scripts to complement or enhance XY.

But being marked as deprecated is the warning!

RalphM wrote:So trying to make sense out of those scripts gets really hard without visual support, me thinks.

The best approach would be to use one grouping of valid keywords and another grouping for deprecated ones, and then ideally the users would be using really annoying colors on the deprecated ones as a reminder to quit using them.

I don't know how feasible that is in other editors but it's something I have on my to do list for whenever I get around to updating the TextPad syntax files.

TheQwerty wrote:The best approach would be to use one grouping of valid keywords and another grouping for deprecated ones, and then ideally the users would be using really annoying colors on the deprecated ones as a reminder to quit using them.

Sounds great to me...and it could even help identifying the commands that would need to be replaced with the next update of the script.

TheQwerty wrote:I don't know how feasible that is in other editors but it's something I have on my to do list for whenever I get around to updating the TextPad syntax files.

No idea whether I actually could do this in PSPad. Since I'm pretty new to it - and I couldn't find a good description of the syntax files syntax so far.
So if anybody got a description I would appreciate it.

Which still leaves the initial question: Does anybody have a list of "deprecated but still valid" script commands?

RalphM wrote:Which still leaves the initial question: Does anybody have a list of "deprecated but still valid" script commands?

I don't. But simply scan History.txt for the word "deprecated" and test whether it still works. I don't think it's a lot of cases. And I can tell you arleady now that the recently turned function getKey() and the like are all still working.

RalphM wrote:No idea whether I actually could do this in PSPad.
So if anybody got a description I would appreciate it.

PSPad > F1 > Working with PSPad > Context Files > Clips > Clip file format

The clip definition format is very simple: [name |x description]*shortcut
X - This (optional) character sets the colour that the clip entry will appear as in the list.
Choose one of:
M - Maroon
R - Red
N - Navy
...
...

Thanks Stefan for that tip - I really read the help file forward and back, or at least I thought so, but I completely missed that section
And a google search did lead nowhere either - I was close to give up finding any info on that topic anywhere.