LiveCode Forums.

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

Richmond.

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

Craig

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

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.

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

Try matchChunk like this:
and LC will return 'true'.

dunbarx wrote: Tue Jun 09, 2026 2:04 pm

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: the regex 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): 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.

richmond62 wrote: Tue Jun 09, 2026 3:13 pm 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: There was never a problem with these functions that required re-writing the IDE. See my comments in the previous post.

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.

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.