Escaping the Filter command's wildcards

[Jan Schenkel]

There has been an enhancement request in the quality center for a few years now.
<http://quality.runrev.com/show_bug.cgi?id=2805>

But now that it's all open source, we can do these changes ourselves.
It looks like it can be accomplished by modifying just a single file: cmdsf.cpp
<https://github.com/runrev/livecode/blob/master/engine/src/cmdsf.cpp>

Maybe we should have a discussion on the engine forum to see who wants to take this on.
To prevent breaking existing scripts, I'd suggest as syntax: filter <container> matching <regex>
(which means we'd have to add a keyword 'matching' to the language but that shouldn't be too hard either)


Anyway, open up the discussion on the engine forum :-)
<http://forums.runrev.com/viewforum.php?f=66>

Cheers,

Jan Schenkel. 

=====
Quartam Reports & PDF Library for LiveCode
www.quartam.com


=====
"As we grow older, we grow both wiser and more foolish at the same time."  (La Rochefoucauld)


----- Original Message -----
From: Peter Haworth <pete at lcsql.com>
To: How to use LiveCode <use-livecode at lists.runrev.com>
Cc: 
Sent: Thursday, May 23, 2013 3:30 AM
Subject: Re: Escaping the Filter command's wildcards

I do find it strange that filter doesn't support full regexp syntax, seems
like RunRev would have had to write special code instead of using standard
regexp libraries which they use in other commands

Shouldn't be too difficult to write a myFilter function that supports full
regexp syntax using a repeat loop and matchText but we shouldn't really
have to take the time to do that.

Pete
lcSQL Software <http://www.lcsql.com>


On Wed, May 22, 2013 at 6:07 PM, Paul Dupuis <paul at researchware.com> wrote:

> On 5/22/2013 8:32 PM, Mark Schonewille wrote:
> > Hi Paul,
> >
> > I see what you mean. You weren't looking for a solution, just for more
> > trouble :-)
> >
> > I tried several special characters and they can all be used to filter
> > lines with the same workaround. Unfortunately, many of those special
> > characters have no effect, because regex isn't fully supported by the
> > filter command, as Pete mentioned already. Therefore I wonder why we
> > need to escape the question mark. That seems inconsistent to me.
>
> Since ?, *, [, and ] are used as special characters, it is possible,
> thought unlikely, to need to escape any or all of them in the pattern to
> actually filter on those characters.
>
> It turns out you can escape ? and * by using [?] or [*] which treats the
> character in the bracket as a character to me matched rather than a
> wildcard. I have not explored how it may be possible to escape the brackets
>
> Of course, you could do some pre-processing of the source data to
> replace those characters with some token that is guaranteed not to be in
> the source text, then apply the filter and then replace the token(s)
> with the original characters, so there are always a work-around in code.
>
> I was mostly wondering if there was an 'undocumented' escape character
> others on the list had found but no one bothered to add a not to the
> dictionary for. However, I guess that is not the case.
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
use-livecode at lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode