Hi,
Wouter is right:
> It is indeed elegant, but a condition check is necessary here as it
> will remove the first word + the space(s) if there is no space at the
> start of the line.
>
> > "The cat sat on the mat. "
> But if no space in front the result is
>
> "cat sat on
Yuk!!!
If the programmers have to check up regular expressions anyway, can I
suggest they make the matchtext consider the full text and not just
match ***within*** a line of text. Okay for "^" and "$" to correspond
to the start and end of a line of text, this is what happens in all
progra
On 23 Oct 2005, at 11:03, Thomas Fischer wrote:
Hi,
Wouter is right:
It is indeed elegant, but a condition check is necessary here as it
will remove the first word + the space(s) if there is no space at the
start of the line.
"The cat sat on the mat. "
But if no spac
On 23 Oct 2005, at 11:23, Dave Cragg wrote:
I assumed that Revolution would do what it promised and didn't
check this.
Try
answer replaceText("A C","^ *","")
I get "C", which obviously is not correct.
If I remove the "*", I get "A C"
This may be a bug. (I'm not sure.)
To expand on why
On 10/24/05 4:51 PM, "Marielle Lange" <[EMAIL PROTECTED]> wrote:
> Yuk!!!
>
> If the programmers have to check up regular expressions anyway, can I
> suggest they make the matchtext consider the full text and not just
> match ***within*** a line of text. Okay for "^" and "$" to correspond
> to th
Hi Dave and all the others in this thread,
> ... I guess the engine is confused about where the replacement
> should be made. As far as I know, replaceText always works when the
> above construction is used in combination with another expression
> (e.g yx*, x*y, yx*z), so if it is a bug, I d
So AFAICT we have a full and complete PCRE implementation here,
with no
'real' bugs associated with it.
I fully agree on the full and complete PCRE. Now I know it is there,
I tested it and all the syntactic variations I know about are there.
But how do I need to call this if not a bug?
pu
On 10/25/05 5:15 PM, "Marielle Lange" <[EMAIL PROTECTED]> wrote:
>> So AFAICT we have a full and complete PCRE implementation here,
>> with no
>> 'real' bugs associated with it.
What I meant was that no bugs were associated with it in Bugzilla.
> I fully agree on the full and complete PCRE. Now
Ken,
Many thanks for the information. As you probably realized, the
problem is not that I am unfamiliar with PCRE (I have used it for a
long times, in PHP), the problem is more that I never realized that
revolution was now correctly implementing PCRE.
Sure, there is this mention at the ve
On 10/25/05 6:05 AM, "Marielle Lange" <[EMAIL PROTECTED]> wrote:
> Many thanks for the information. As you probably realized, the
> problem is not that I am unfamiliar with PCRE (I have used it for a
> long times, in PHP), the problem is more that I never realized that
> revolution was now correct
Marielle-
Tuesday, October 25, 2005, 4:05:38 AM, you wrote:
> Sure, there is this mention at the very bottom of the matchtext
> function. "Changes to Transcript: The regular expression format
> changed in version 2.0 to use PCRE compatible syntax". But when I
> tried the PCRE syntax in versio
On 10/25/05 11:48 AM, "Mark Wieder" <[EMAIL PROTECTED]> wrote:
> Marielle-
>
> Tuesday, October 25, 2005, 4:05:38 AM, you wrote:
>
>> Sure, there is this mention at the very bottom of the matchtext
>> function. "Changes to Transcript: The regular expression format
>> changed in version 2.0 to us
Ken-
Tuesday, October 25, 2005, 10:28:36 AM, you wrote:
> Actually, it *should* support the full form of PCRE, since that is the
> library that was used when the put it into the engine. The bugs you identify
> above are all enhancement requests, so they are not representative of actual
> bugs wit
On 25 Oct 2005, at 20:19, Mark Wieder wrote:
Ken-
Tuesday, October 25, 2005, 10:28:36 AM, you wrote:
Actually, it *should* support the full form of PCRE, since that is
the
library that was used when the put it into the engine. The bugs
you identify
above are all enhancement requests, so t
>> Well, my BZ #2805 was filed as an enhancement because I realize that
>> runrev implements *some* of the regular expression characters in the
>> filter command, but not all. I realize the matchText function handles
>> more of them, but whether this inconsistency is a bug or an
>> enhancement requ
On 25 Oct 2005, at 22:39, Thomas Fischer wrote:
2. I didn't want to sound too harsh, sorry.
And if my reply sounded harsh, sorry too.
3. It seems that regular expressions are to be avoided in time
sensitive parts of the script anyway. Playing around a little bit I
found that the RegExp
Dave-
Tuesday, October 25, 2005, 12:52:09 PM, you wrote:
> The "filter" command doesn't claim to use regualr expressions. (only
> matchText, matchChunk, and replaceText do) The docs for "filter" use
> the term "wilcard expression", and in fact, a much richer set of
> wildcards are allowed in fi
All,
What about using something like this as an interim solution to filter +
regex?
I'm sure this could be improved, but basically it just runs through the
text one line at a time and uses matchText to filter in/out the matching
lines.
on regexFilter @t,expr
local tmp,l,outLine
repeat for ea
On 25 Oct 2005, at 23:39, Thomas Fischer wrote:
-snip-
3. It seems that regular expressions are to be avoided in time
sensitive parts of the script anyway. Playing around a little bit I
found that the RegExp solution I suggested took far more time than
any other solution (by about a factor
briany-
Tuesday, October 25, 2005, 4:40:55 PM, you wrote:
> put "AC"&cr&"BD"&"CC" into tText
> regexFilter tText,"[AB][BC]"
// tText =>> "AC"
Something like that would probably work out, but you'd lose the speed
of the filter command.
--
-Mark Wieder
[EMAIL PROTECTED]
___
Hi Wouter,
you wrote
> These timing tests are not completely fair because:
>
>while char 1 of testString is space -> removes only space from
> front if any
> delete char 1 of testString
>end repeat
>
> word 1 to -1 of testString -> removes tabs, spaces and returns from
> fr
This would make sense that the quote is considered non-white space.
If you were parsing a quoted string and considered the quotation mark a
valuable character and part of the "word" component.
now try these in the msg box. I said 'huh?' and probably a bug.
put word 1 to -1 of "My test with l
This would make sense that the quote is considered non-white space.
If you were parsing a quoted string and considered the quotation mark a
valuable character and part of the "word" component.
now try these in the msg box. I said 'huh?' and probably a bug.
put word 1 to -1 of "My test with l
23 matches
Mail list logo
