matchText goes 'all sensitive'.

[richmond62]

In the upcoming release of OXT Lite (1.15) matchText can have case sensitivity set to true or false.

[dunbarx]

Richmond.

It used to only be "true". Likely this is helpful given that the source text may be sloppily constructed.

Craig

[richmond62]

Exactly, so . . . err . . . jump ship.

[stam]

Guys....... matchText uses regex as search criterion, and you've always been able to set case sensitivity in the regex expression.
MatchText() purpose in life is to bring regex to LiveCode (and OXT I presume).

If the OXT version of matchText has changed this so it doesn't use regex that's fine, although not sure what the point of it would actually be then - but if you're saying there's an OXT switch for case sensitivity AND a regex switch then that's a recipe for problems.

Instead of faffing around, just learn regex. It's not hard.

[dunbarx]

Stam.

In the dictionary:

The string and regularExpression are always case-sensitive, regardless of the setting of the caseSensitive property. (

That is what Richmond was on about. Do I still misunderstand?

Craig

[richmond62]

Try matchChunk like this:

Code: Select all

put matchChunk("flop", "FLOP")

and LC will return 'true'.

[stam]

The string and regularExpression are always case-sensitive, regardless of the setting of the caseSensitive property. (

That is what Richmond was on about. Do I still misunderstand?

Edited my response as there was an issue with my regex testing stack that meant the flags (?msiU) were always added - good exercise to make me fix this.

Back to your comment:
Case sensitive is always the defaut, because regex is case sensitive by default and the only reason reason for matchText() is to bring regex to LiveCode. It makes little sense to produce a regex tool that uses other scripting languages to modify its regex behind the scenes.

Regex is designed as a pattern matching tool - matching any text that fits a pattern. One would want to define that pattern strictly, but this means part of the pattern is defined in OXT script, and part of it in regex, which is not sane. This move makes me think OXT is adapting it as a string literal search, which is at best weird, when the language has many other tools for exactly this (offset, find, etc).

Example usage: If you have the string:

Code: Select all

Hello World
hello world

the regex

Code: Select all

(hel.+)(?:\R)

will match the second line, "hello world" - ie case sensitive.

To make it case-insensitive, one would use the flag i, in other words to match "Hello World" (remembering that PCRE regex only returns the 1st match), the regex would need to include the case-insensitive flag (?i):

Code: Select all

(?i)(hel.+)(?:\R)

I don't understand why one wouldn't use regex syntax to write regex - which was my point. MatchText() is there to use regex.
Modifying the IDE to add the "(?i)" flag in OXT script via the CaseSensitive property means that using the actual regex anywhere else might fail because the regex itself wouldn't include this when it would be expected to.

Madness from a programming point of view...


-------------------------------------------
Explanation of the regex used above:

• The terminal group (?:\R) is a non-capturing group - terminates the match without including it - (?: ) is a non-capturing group. \R is any kind of line ending (CR, LF, CRLF).
• The capturing group that is returned by MatchText is (hel.+) - ie the letters "hel", wildcard char "." and + denotes "one or more of the previous char", in this case the wildcard). Each capture group is in parentheses (...) without the ? or ?: modifiers.
• Flags are set at the start with (?msixU) - where each letter after the '? is a flag. Flags are in the form (?...). Case Insensitive flag is (?i).

.

My top tip for testing regex is to use https://regex101.com. Always test your regex there first to make sure it works.
The only adaptations to bring whatever works there to livecode:

• There is no 'global' flag in PCRE regex, so ensure you switch of the g (global) flag. Global is nice because it matches all occurrences, sadly LiveCode's choice of PCRE regex only returns the first match, so switch off /g in regex101.com.
• In JS, the flags are appended after the regex in the form /<regex text>/msixU, whereas in PCRE these are prepended and the capture group(s) to return in matchText are in parentheses, in the form (?msixU)(<regex text>), where m, s, i, x, U are the commonest flags can be used alone or in combination.

Regex basics don't take long to learn. I wrote a primer: https://github.com/stam66/regexPrimerForLivecode/wiki
Regex101.com includes an incredibly handy searchable reference as well.

[stam]

Try matchChunk like this:

Code: Select all

put matchChunk("flop", "FLOP")

and LC will return 'true'.

Why are you using a regex method for string literal searching? matchText() and matchChunk() exist purely to bring regex, a pattern matching tool, to xTalk. If you want to search for string literals, use offset, find etc, or even 'contains', 'is in', etc if you just want a boolean TRUE/FALSE.

Regex lets you find texts that fit a pattern, and although can be used for string literals (hence your example), that's not why it's there.

If you're defining a pattern to search for you want this to be strictly controlled to avoid false positives and false negatives. You now have a situation where the pattern is controlled both by OXT and by regex. You don't see the pattern in the regex, and using the regex elsewhere may fail.

There is no logic to this. if you want case-insensitive in your example, just use regex:

Code: Select all

put matchChunk("flop", "(?i)FLOP")

There was never a problem with these functions that required re-writing the IDE. See my comments in the previous post.

[richmond62]

Somebody else, somewhere else, said something else: and they ken it well:

https://www.openxtalk.org/forum/viewtopic.php?t=2036

And I do believe that an awful lot of people who use these forums would profit from also following:

https://hyperxtalk.discourse.group/

and

https://www.openxtalk.org/forum/index.php

a lot of useful cross-fertilisation might result in some new-found hybrid vigour.

[stam]

I'm not even sure where to begin with this.
The point blank refusal of wanting to understand or use regex is jaw-dropping...

I gave your links (well, 1st link) a glance. It seems OXT has gone as far as removing regex from the regex method, the actual reason for the existence of these functions. I don't mean to be insulting, but regex is not a high-IQ thing. It's a few rules to learn with a lot to gain.
You're just dumbing down everything to a level so low that it is no different from Offset(), Find(), etc.


How is using MatchText() this way any different from using Offset()? Do you even understand what the difference between the two is?
Clearly you don't, because if you did we would not be having this discussion.


I'll be steering well clear of anything OXT does and advising others to do the same, because they (and you) clearly have zero understanding and zero willingness to learn. And I'll not respond further to this because clearly there is a chasm that is insurmountable.

[PaulDaMacMan]

It seems OXT has gone as far as removing regex from the regex method, the actual reason for the existence of these functions. I don't mean to be insulting, but regex is not a high-IQ thing. It's a few rules to learn with a lot to gain.

Just a few rules to Pearl RegEx huh?

but also...

it’s eye-watering - because it covers every conceivable permutation of a valid email, including using an IP address as the server part:

(?:[a-z0-9!#$%&'*+/=?^_\`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-9]?[0-9]))\.){3}(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-9]?[0-9])|[a-z0-9-]*[a-z0-9]?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])

I'll be steering well clear of anything OXT does and advising others to do the same, because they (and you) clearly have zero understanding and zero willingness to learn. And I'll not respond further to this because clearly there is a chasm that is insurmountable.

Richmond is no more a representative of OXT, HXT, or the Open Source Community than he is a representative of LC Ltd. but whatever.

This is either misinformatin or DISinformation. I just check in latest OXT Engine (LC CE 9.7 based) and RegEx works same as ever with the MatchText function. Where did you get the idea that RegEx was removed? Also Emily, Brian and the gang working on HyperXTalk, I'm certain would not have removed that either.

[Emily-Elizabeth]

MatchText is still in HyperXTalk.

[ClipArtGuy]

This is either misinformatin or DISinformation. I just check in latest OXT Engine (LC CE 9.7 based) and RegEx works same as ever with the MatchText function. Where did you get the idea that RegEx was removed? Also Emily, Brian and the gang working on HyperXTalk, I'm certain would not have removed that either.

When I was young, I had this utopian view that the internet was going to solve humanity's problems. Once everyone was online, we'd all come together and sing "Kumbaya." Unfortunately, all it has done is give everyone a platform to broadcast whatever ideas they want out into the ether, while the people who WANT to believe them do so blindly. Among a myriad of other horrifying use cases...

Not sure what the solution to that is, but now that we have the LiveCode Community 9.7.0-dp-1 source as LiveCode left it, the last build of their open-source develop branch, combined into a single repo (with the IDE and third-party submodules merged in and their history preserved), LiveCode's own tests hooked back up, and everything building, testing, and packaging automatically on GitHub for Windows, Mac (Apple Silicon and Intel), and Linux, anybody can easily fork from where the mothership left off and add or remove whatever they want. A merge and a click builds the whole thing.

[PaulDaMacMan]

This is either misinformatin or DISinformation.

When I was young, I had this utopian view that the internet was going to solve humanity's problems. Once everyone was online, we'd all come together and sing "Kumbaya." Unfortunately, "

Yup, I bought in to that early optimism about "Information Superhighway" as well, after the Dot Com bubble burst, and then social media became a thing it was all down hill from there.

but now that we have the LiveCode Community 9.7.0-dp-1 source as LiveCode left it, the last build of their open-source develop branch, combined into a single repo (with the IDE and third-party submodules merged in and their history preserved), LiveCode's own tests hooked back up, and everything building, testing, and packaging automatically on GitHub for Windows, Mac (Apple Silicon and Intel), and Linux, anybody can easily fork from where the mothership left off and add or remove whatever they want. A merge and a click builds the whole thing.

829356762_1799353904417749_1639931955597148222_n.jpg

Yes, that's some excellent work updating that huge beast, and an excellent base to fork off of, if anyone wants to try to do any better then what's already being done on a purely altruistic volunteer basis

[PaulDaMacMan]

I think the confusion stemmed from a comment 'over there' from Tom about UNCOMMENTING something related to its default case-sensitivitiy in the C++ code, which actually seems to enable case sensitivity (as it should be?) as the default.

I can think of some uses for this syntax that require no use of RegEx at all, so I'd argue RegEx is not the only reason for that function to exist. It's rather nice that along with a boolean result, you can also have it return the found text chunk in a variable/container that you pass in (it's an 'in and out' parameter, could probably use @symbol to pass as a reference).