Re: Regexp, ***= and subexpressions
From: Kaitzschu (kaitzschu_at_kaitzschu.cjb.net.nospam.plz.invalid)
Date: 05/29/04
- Next message: Bruce Hartweg: "Re: Regexp, ***= and subexpressions"
- Previous message: marvin: "Re: Rivet 0.4"
- In reply to: Bruce Hartweg: "Re: Regexp, ***= and subexpressions"
- Next in thread: Bruce Hartweg: "Re: Regexp, ***= and subexpressions"
- Reply: Bruce Hartweg: "Re: Regexp, ***= and subexpressions"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 29 May 2004 07:35:21 +0300
It is 4:57 AM and awfully sunny. And when you can't sleep in saturday
morning, what else you can do but read newsgroups, code new things and
save your SUN-mouse from drowning in orange juice.
I really need to get sleeping shades.
On Fri, 28 May 2004, Bruce Hartweg wrote:
> You saw the part about it being ...the rest of the RE... but missed the
> part that says that it is only valid at the start or the RE. (that is
> the start of the entire RE, not a part of it.
True, I was being hasty and missed "-- (or an initial ***= director) has
specified that the user's input be treated as a literal string rather than
as an RE." Input clearly points out that this is not applicable in smaller
partions, but I got carried away by "If an RE of any flavor begins with"
and definition of (re) atom, "(where re is any regular expression)". So,
my bad, but documentation bites some of the bullet, too.
> I see a few solutions, use **= at the beginning and lose your ability to
> use the \m \M to avoid internal word matching
> or skip regexp alltogether and use string first to see if it matches
Unfortunately, no can do. This regexp mess is a part of of a Definition of
Overkill styled stream/buffer highlighter/searcher procedure, using Text
widget to easen things. [string first]ing whole widget as highlight terms
are changed just doesn't sound good enough for me to abandon Texts [search
-regexp].
And don't worry, it wouldn't apply as Overkill if it didn't use [search
-exact] in cases where regexp isn't required :P
> or your regsub solution (which I would do as a [string map ...] )
Am now applying [string map] from Donald's snippet and am facing new
problems as described in the end. I was leaning towards [regsub] because
of it's ease of use, as Kevin already showed up.
> or you could train your users/tester (update your help screen/user
> manual/whatever) that they are providing an RE not a string and they
> need to handle escaping when desired.
If I can't handle regular expressions using Tcls documentation it would be
instant bad karma just to consider forcing poor users to handle regexps
based on my interpretation of manual pages :)
On Sat, 28 May 2004, Donald Arseneau wrote:
> You have to sanitize the user input first.
>
> ... snip from something I did a month ago,,,
>
> # First, escape special characters in title string
> set tpattern [string map \
> {\\ \\\\ . \\. , \\, [ \\[ ] \\] \{ \\\{ \} \\\} * \\* ( \\( ) \\) ^ \\^ \$ \\\$} \
> $title]
This did fix the matching part, but - as usually - a new problem arose.
Seems to be that regexp can't match word boundaries at "non-word"
characters, consider this
regexp {\*} {*}
returning true and this
regexp {\m\*\M} {*}
returning false. That of course means I still can't match \m\[DS\]\M and
that makes me a sad panda. So, what would be next logical step? :)
But now Earth has rotated and I can get back to sleep.
-- -Kaitzschu
- Next message: Bruce Hartweg: "Re: Regexp, ***= and subexpressions"
- Previous message: marvin: "Re: Rivet 0.4"
- In reply to: Bruce Hartweg: "Re: Regexp, ***= and subexpressions"
- Next in thread: Bruce Hartweg: "Re: Regexp, ***= and subexpressions"
- Reply: Bruce Hartweg: "Re: Regexp, ***= and subexpressions"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
