Nice work so far on Proximodo. It's shaping up quite nicely. It's great to see the Proxomitron language continuing. (And hopefully improving.)
I decided to try to import a few filters from my Proxomitron config set the other day.. Unfortunately, I ran into a few problems. (Mostly compatibility issues.) I'll do my best to explain, I'll keep it short tho. As I haven't messed with Prox code in awhile. ;) And my terminology might be off.
--- [ Compatibility ]
The following matching expression works in Proxomitron.
(
test
|
foo$SET(test=1)
)
&
(^$TST(test=*))
In the test field I have... "test foo" Which results in... " foo".
However in Proximodo I have to alter the matching code to...
(
test
|
foo$SET(test=1)
)
(^$TST(test=?*))
Or
(
test
|
foo$SET(test=1)
)
&?
(^$TST(test=?))
A few other adaptations also work, but I think you get the idea. :)
As was pointed out to me, the & is not needed in the original matching expression. However, IMO it's just one of those things that helps make code easier to read. However, I think the $TST issue could be considered a bug.
------ [ GUI ]
Why is "Byte Limit" called "Window Width"? I found that quite odd, and think it might confuse "newbies". When I think of window width. I think of the width of the window I'm viewing.
A "Test" button would be nice. (I prefer a button over a menu item.)
Also, having the filter "Edition Window" focused when double-clicking a filter. :D
------ [ Request ]
An option to cancel changes in the filter edit window would be greatly appreciated. Sometimes I just like to play with a filter. I don't want to have to revert all changes to the config set, just to get back to the original filter.
I have some more questions about priority and $TYPE(htm). But, I'll save those for later. ;)
~JD
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Regarding JD's msg, in the first section, third example:
(
test
|
foo$SET(test=1)
)
&?
(^$TST(test=?))
I think he meant to indicate another, separate compatibility issue with that. For example, given...
[string matched]
&
[matching expression]
...in Proxo, the "matching expression" doesn't actually require ANY bytes be matched! Because of this, many folks (like JD...and well, me too ;) sometimes use an "&" structure for more defined formatting...although, most use "&" without any byte-match simply because they don't know they don't NEED the "&" if only setting vars or inserting a STOP after it. Whatever the reason, it's fairly common for many Proxo users to use an "&" without any bytes matched afterwards.
Proxi, on the other hand, requires at least one byte be matched following an "&"; hence, the "?" before the ^TST expression in JD's third example there. :)
-Mona
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Heya Antony,
Nice work so far on Proximodo. It's shaping up quite nicely. It's great to see the Proxomitron language continuing. (And hopefully improving.)
I decided to try to import a few filters from my Proxomitron config set the other day.. Unfortunately, I ran into a few problems. (Mostly compatibility issues.) I'll do my best to explain, I'll keep it short tho. As I haven't messed with Prox code in awhile. ;) And my terminology might be off.
--- [ Compatibility ]
The following matching expression works in Proxomitron.
(
test
|
foo$SET(test=1)
)
&
(^$TST(test=*))
In the test field I have... "test foo" Which results in... " foo".
However in Proximodo I have to alter the matching code to...
(
test
|
foo$SET(test=1)
)
(^$TST(test=?*))
Or
(
test
|
foo$SET(test=1)
)
&?
(^$TST(test=?))
A few other adaptations also work, but I think you get the idea. :)
As was pointed out to me, the & is not needed in the original matching expression. However, IMO it's just one of those things that helps make code easier to read. However, I think the $TST issue could be considered a bug.
------ [ GUI ]
Why is "Byte Limit" called "Window Width"? I found that quite odd, and think it might confuse "newbies". When I think of window width. I think of the width of the window I'm viewing.
A "Test" button would be nice. (I prefer a button over a menu item.)
Also, having the filter "Edition Window" focused when double-clicking a filter. :D
------ [ Request ]
An option to cancel changes in the filter edit window would be greatly appreciated. Sometimes I just like to play with a filter. I don't want to have to revert all changes to the config set, just to get back to the original filter.
I have some more questions about priority and $TYPE(htm). But, I'll save those for later. ;)
~JD
Compatibility: indeed. Proxo's $TST will never match if variable is empty. I'll do the same in Proximodo.
GUI: it refers to "sliding window width", a term commonly used by developers. I agree it's a bit confusing for users.
Request: Undo is the developers' nightmare. Well, that's a legitimate request anyway ;-)
Hi Antony,
Regarding JD's msg, in the first section, third example:
(
test
|
foo$SET(test=1)
)
&?
(^$TST(test=?))
I think he meant to indicate another, separate compatibility issue with that. For example, given...
[string matched]
&
[matching expression]
...in Proxo, the "matching expression" doesn't actually require ANY bytes be matched! Because of this, many folks (like JD...and well, me too ;) sometimes use an "&" structure for more defined formatting...although, most use "&" without any byte-match simply because they don't know they don't NEED the "&" if only setting vars or inserting a STOP after it. Whatever the reason, it's fairly common for many Proxo users to use an "&" without any bytes matched afterwards.
Proxi, on the other hand, requires at least one byte be matched following an "&"; hence, the "?" before the ^TST expression in JD's third example there. :)
-Mona
Right! I see... Now, that's fixed :)