I want to replace the first column containing a number in a tab separated file.
I use the following regular expression in the Find field to accomplish this:
^[0-9]+\t
I replace this with nothing. The Replace field is empty.
The result of this is not what I expected. What happens is that every consecutive column containing a number is also deleted. This is because, after deleting the first, the next column has become the new first column on the same line.
I expected the ^ start-of-line marker to be active only once per line.
So I can't use CTRL+H Replace Dialog for this.
If I use the CTRL+R advanced Find/Replace Dialog and have only Regular Expr checked, I have the same problem.
Fortunately, there is the 1 per line checkbox in this Dialog, which allows me to achieve what I want.
There is also the Incremental checkbox in this Dialog. Checking it in this case has no use, because what would be expected behavior then, is the same as the default behavior.
Wouldn't it make more sense to automatically treat the ^ start-of-line as "1 per line" feature, allowing users to do this repeatedly (on the changed line) by checking the Incremental checkbox?
Is or will there be a solution for my problem using the CTRL+H Replace Dialog?
Similarly, when using $ end-of-line marker things work as expected. This is because the cursor is positioned _at_ the end of the line, after replacing, so no more match will be found for any characters _before_ the new cursor position. Clearly, this is what I logically also would expect when using the ^ start-of-line marker.
Additionally, checking Incremental when using $ might be implemented as "Check again the end of the line (until no longer matched)". I would very much welcome ^ and $ to be treated "equally" in this way, that is, with the same options checked both ^ and $ work either _only once per line_ or _repeatedly_.
Are there any advocates for this?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I deed. This is a solution for your problem, with no need in adding any new useless features :)
Your problem is that you ignore the fact that search/replace continues just after the previews search/replace match. This regex will match whole the line, so it will not continue searching in the same line after removing 1-st column. That's all you needed, isn't it? :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now, if you DID read my message, you would understand that both your replies do not make any sense.
The only thing that's new is that I could use your regex in the CTRL+H Find/Replace Dialog.
Now, why would I want to do that?
I also mentioned my work-around in CTRL+R Replace Dialog. So I really don't need to have any other solution, especially none which is only more time consuming, because it replaces each whole line with almost the same content.
You talk about useless features, which my request is not, but certainly your replies are.
The regular expressions for start and end of line are special cases. Because ^ and $ refer to an absolute position in the line, it is not strange to expect these to be treated as special, that is as absolute markers. Because there is only one start and one end in a line, it would be quite straightforward to also replace only one occurrence if there is a match. The regex algorithm could or should mark or remember that it has already processed the start of the line. Also, it should be made possible to recursively match the end of the line as it currently "does" for the start. My request is to always treat ^ and $ the same way, that is either recursive or not recursive. This could be made dependent on the "incremental" setting.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>>Now, if you DID read my message, you would understand that both your replies do not make any sense.
Relax, man :) Your topic starts with "HOW TO" and ends with question mark. I assuming it's a question. That i answered to. If you don't like the answer - it's your problem, not mine :)
>>The only thing that's new is that I could use your regex in the CTRL+H Find/Replace Dialog.
>>Now, why would I want to do that?
Why would Don want to change the "incremental" behaviour when it really work as intended and you simply don't understand how regexes works and what "incremental" option should really do (and doing well)? :)
>>I also mentioned my work-around in CTRL+R Replace Dialog. So I really don't need to have any other solution, especially none which is only more time consuming, because it replaces each whole line with almost the same content.
If you don't need something - simply don't ask for it ;)
>>You talk about useless features, which my request is not, but certainly your replies are.
>>The regular expressions for start and end of line are special cases. Because ^ and $ refer to an absolute position in the line, it is not strange to expect these to be treated as special, that is as absolute markers. Because there is only one start and one end in a line, it would be quite straightforward to also replace only one occurrence if there is a match.
^ and $ symbols are ANCHORS. This means that they don't match beginning of the line or EOL. ^ means only that matched string MUST be at the beginnig of the line. Current position after your replacement is the 1-st column in the line. And if after replacement there is a new string, that matching entire regex after the ^ symbol here - it should and will be also matched. That is how anchors work. Noone will change anchors behaviuor just becouse you don't like it :)
>>The regex algorithm could or should mark or remember that it has already processed the start of the line. Also, it should be made possible to recursively match the end of the line as it currently "does" for the start. My request is to always treat ^ and $ the same way, that is either recursive or not recursive. This could be made dependent on the "incremental" setting.
Instead of all the sniping (not there's always necessarily anything wrong with that) -
why not just say that it is implemented properly according to the "rules" (if it is)
give a solution whether asked for or not (and don't bitch about it)
since we all like to do that
furthermore, if you know everything about regular expressions, you must be a ________
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's not a snipping but the 1-st link google show me on request "regular expressions".
I don't know EVERYTHING, but i do know in this situation it works as intended. And this is what i (and not only i) said few times in this topic. And if you look in the 1-st reply in this thread - you'll see the solution. But he don't need it, so who cares :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The solution is in my own message, at the start of this thread.
So don't try to be the smarter guy pointing out that what you do does the work, too.
There are even better solutions than yours.
The best direct solution probably is the one looking for the searched string and _only_ the one possible character following it and replacing this by this _only_ one possible character. There is absolutely no need to replace anything behind it. How smart is that?
The pain in the ass here is that, by removing only the beginning of the line, the cursor is not recognized to have in fact moved. It should have, though, because also the current implementation for counting the number of starts-of-line doesn't return a result at all.
Funny you have nothing to say about that, wise man.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>>The solution is in my own message, at the start of this thread.
So, you're talking to yourself? %) Asking for solutions and giving it in the same message? %)
>>So don't try to be the smarter guy pointing out that what you do does the work, too.
I don't try to be someone :) I simply answered your question. You ask - i answer. Clean and clear %) All beside this is a flood :)
>>There are even better solutions than yours.
Yes! A lot of! %)
>>The best direct solution probably is the one looking for the searched string and _only_ the one possible character following it and replacing this by this _only_ one possible character. There is absolutely no need to replace anything behind it. How smart is that?
Very, very smart! :) Why did you ctreate this thread? :)
>>The pain in the ass here is that, by removing only the beginning of the line, the cursor is not recognized to have in fact moved. It should have, though, because also the current implementation for counting the number of starts-of-line doesn't return a result at all.
>>Funny you have nothing to say about that, wise man.
Why should i say something about it? %) It has nothing connected with discussion topic and i have nothing to say about it, so don't say - it's simple %)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You seem to be really doing your best to make a dumb impression. Well, you do!
>>The solution is in my own message, at the start of this thread.
So, you're talking to yourself? %) Asking for solutions and giving it in the same message? %)
Wow, you must be missing a number of connections in what others have as brain.
Nowhere in my message I ask for a solution. So why persist you stupid interpretation?
> I don't try to be someone :) I simply answered your question. You ask - i answer.
Once again: nothing asked.
>>There are even better solutions than yours.
> Yes! A lot of! %)
So you seem to recognize that you really didn't think your first reply through. I guess you were all too greedy thinking you could make a good impression. You even didn't write a message, just posted a single line.
>>The best direct solution probably is the one looking for the searched string and _only_ the one possible character following it and replacing this by this _only_ one possible character. There is absolutely no need to replace anything behind it. How smart is that?
> Very, very smart! :) Why did you ctreate this thread? :)
You don't know why? Oh, that doesn't even surprise me anymore. You really don't read.
And yes, I am smart. At least I show progression and am not stuck at repeating the same nonsense over and over again.
>>The pain in the ass here is that, by removing only the beginning of the line, the cursor is not recognized to have in fact moved. It should have, though, because also the current implementation for counting the number of starts-of-line doesn't return a result at all.
>>Funny you have nothing to say about that, wise man.
> Why should i say something about it? %)
At least you show that you are not consistent. Didn't you say "you ask - I answer"? Well, why don't you now, then?
> It has nothing connected with discussion topic and i have nothing to say about it, so don't say - it's simple %)
Oh, this is supposed to answer that question? It shows again you totally missed my point.
Think about this, then: how come a count of ^ doesn't work, while a count of $ does? There should be really NO difference between the two, since both characters are only ANCHORS, as you like to point out.
No movement shoud be made, but it seems there is, and this i what also a guy like you should consider to be wrong.
Because searching for the end of line by using $ and replacing this by any character string, what happens is that the line is extended by this string, thus creating a new end of line behind it. This also shows that there really should be no movement either when searching for $ only, because the text is inserted before the newline character(s).
Now, how do you want to explain this newly created end of line position is NOT found, while the same beginning of the line when using ^(...) is?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, i'll skip the topmost part of your message as it funny, but very long and pointless dialog :)
Only few replies:
>>Didn't you say "you ask - I answer"? Well, why don't you now, then?
I did. You asked:
>How to: 1 ^ start-of-line per line in regexp?
and
>Is or will there be a solution for my problem using the CTRL+H Replace Dialog?
I answered:
>^[0-9]+\t(.*)$
>replace with
>\1
That was becouse i had an answer to that your questions. Now i don't have an answer to your other question - so i don't answer. Is it hard to understand? :)
>>Oh, this is supposed to answer that question? It shows again you totally missed my point.
It was a reply to
>Funny you have nothing to say about that, wise man.
If you'll start reading not only my messages but your own ones, which my messages are replies to - things could become more clear to you ;)
>>Think about this, then: how come a count of ^ doesn't work, while a count of $ does? There should be really NO difference between the two, since both characters are only ANCHORS, as you like to point out.
No movement shoud be made, but it seems there is, and this i what also a guy like you should consider to be wrong.
Because searching for the end of line by using $ and replacing this by any character string, what happens is that the line is extended by this string, thus creating a new end of line behind it. This also shows that there really should be no movement either when searching for $ only, because the text is inserted before the newline character(s).
>>Now, how do you want to explain this newly created end of line position is NOT found, while the same beginning of the line when using ^(...) is?
Well. How do you explain that Count button says that regular expression formed badly for regex "^.*" if there are emty lines in the text, but Find button will find'em all, one by one, even empty lines? I DO NOT have explanation for this. I can only assume that Count algorithm is broken.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It seems to me that the argument going on here is about the original intention of the thread. As English is not the native language of a large number of users of this forum, I wonder if hair splitting about precise meanings is a good idea. It usually isn't anyway.
It would also help if some of you people registered and logged in before posting - it's hard to work out who said what when everyone is called "nobody".
He had a problem, caused by ^ not being treated as once per line. He found a workaround, but is suggesting that this behaviour be changed. That's what should be being discussed.
His question:
"Wouldn't it make more sense to automatically treat the ^ start-of-line as "1 per line" feature, allowing users to do this repeatedly (on the changed line) by checking the Incremental checkbox?
Additionally, checking Incremental when using $ might be implemented as "Check again the end of the line (until no longer matched)". I would very much welcome ^ and $ to be treated "equally" in this way, that is, with the same options checked both ^ and $ work either _only once per line_ or _repeatedly_.
Are there any advocates for this?"
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Of course, I was pointing at the Recursive option, which I called Incremental. I knew there was such an option, but I didn't look ahead when I found a name that seemed suit my purpose.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There's no need to, as I am not looking for any solutions. I just ask IF there is or will be a solution. I am not asking HOW to accomplish my goal, since I have been able to do so. Is that SO very hard to understand???
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I want to replace the first column containing a number in a tab separated file.
I use the following regular expression in the Find field to accomplish this:
^[0-9]+\t
I replace this with nothing. The Replace field is empty.
The result of this is not what I expected. What happens is that every consecutive column containing a number is also deleted. This is because, after deleting the first, the next column has become the new first column on the same line.
I expected the ^ start-of-line marker to be active only once per line.
So I can't use CTRL+H Replace Dialog for this.
If I use the CTRL+R advanced Find/Replace Dialog and have only Regular Expr checked, I have the same problem.
Fortunately, there is the 1 per line checkbox in this Dialog, which allows me to achieve what I want.
There is also the Incremental checkbox in this Dialog. Checking it in this case has no use, because what would be expected behavior then, is the same as the default behavior.
Wouldn't it make more sense to automatically treat the ^ start-of-line as "1 per line" feature, allowing users to do this repeatedly (on the changed line) by checking the Incremental checkbox?
Is or will there be a solution for my problem using the CTRL+H Replace Dialog?
Similarly, when using $ end-of-line marker things work as expected. This is because the cursor is positioned _at_ the end of the line, after replacing, so no more match will be found for any characters _before_ the new cursor position. Clearly, this is what I logically also would expect when using the ^ start-of-line marker.
Additionally, checking Incremental when using $ might be implemented as "Check again the end of the line (until no longer matched)". I would very much welcome ^ and $ to be treated "equally" in this way, that is, with the same options checked both ^ and $ work either _only once per line_ or _repeatedly_.
Are there any advocates for this?
Yep - agree on that. ROFLMAO
^[0-9]+\t(.*)$
replace with
\1
What do you mean to say?
Didn't you read?
I deed. This is a solution for your problem, with no need in adding any new useless features :)
Your problem is that you ignore the fact that search/replace continues just after the previews search/replace match. This regex will match whole the line, so it will not continue searching in the same line after removing 1-st column. That's all you needed, isn't it? :)
Now, if you DID read my message, you would understand that both your replies do not make any sense.
The only thing that's new is that I could use your regex in the CTRL+H Find/Replace Dialog.
Now, why would I want to do that?
I also mentioned my work-around in CTRL+R Replace Dialog. So I really don't need to have any other solution, especially none which is only more time consuming, because it replaces each whole line with almost the same content.
You talk about useless features, which my request is not, but certainly your replies are.
The regular expressions for start and end of line are special cases. Because ^ and $ refer to an absolute position in the line, it is not strange to expect these to be treated as special, that is as absolute markers. Because there is only one start and one end in a line, it would be quite straightforward to also replace only one occurrence if there is a match. The regex algorithm could or should mark or remember that it has already processed the start of the line. Also, it should be made possible to recursively match the end of the line as it currently "does" for the start. My request is to always treat ^ and $ the same way, that is either recursive or not recursive. This could be made dependent on the "incremental" setting.
>>Now, if you DID read my message, you would understand that both your replies do not make any sense.
Relax, man :) Your topic starts with "HOW TO" and ends with question mark. I assuming it's a question. That i answered to. If you don't like the answer - it's your problem, not mine :)
>>The only thing that's new is that I could use your regex in the CTRL+H Find/Replace Dialog.
>>Now, why would I want to do that?
Why would Don want to change the "incremental" behaviour when it really work as intended and you simply don't understand how regexes works and what "incremental" option should really do (and doing well)? :)
>>I also mentioned my work-around in CTRL+R Replace Dialog. So I really don't need to have any other solution, especially none which is only more time consuming, because it replaces each whole line with almost the same content.
If you don't need something - simply don't ask for it ;)
>>You talk about useless features, which my request is not, but certainly your replies are.
>>The regular expressions for start and end of line are special cases. Because ^ and $ refer to an absolute position in the line, it is not strange to expect these to be treated as special, that is as absolute markers. Because there is only one start and one end in a line, it would be quite straightforward to also replace only one occurrence if there is a match.
^ and $ symbols are ANCHORS. This means that they don't match beginning of the line or EOL. ^ means only that matched string MUST be at the beginnig of the line. Current position after your replacement is the 1-st column in the line. And if after replacement there is a new string, that matching entire regex after the ^ symbol here - it should and will be also matched. That is how anchors work. Noone will change anchors behaviuor just becouse you don't like it :)
>>The regex algorithm could or should mark or remember that it has already processed the start of the line. Also, it should be made possible to recursively match the end of the line as it currently "does" for the start. My request is to always treat ^ and $ the same way, that is either recursive or not recursive. This could be made dependent on the "incremental" setting.
Priceless advice :) Go and read something about regexes. http://www.regular-expressions.info for example.
I suggest you read my message over and over again until you get the point.
Similarly, if you mind me calling you stupid, that sure is your problem (besides the fact that you are stupid), not mine.
>>I suggest you read my message over and over again until you get the point.
Should I find something new there? :)
>>Similarly, if you mind me calling you stupid, that sure is your problem (besides the fact that you are stupid), not mine.
Bad try ;)
Well, if you're so clever man, than go on waiting for implementation of your very usefull feature :) Good luck in your doing %)
> Should I find something new there? :)
Isn't this a demonstration that you yourself don't know how to perform a regex search in a thread?
>>Isn't this a demonstration
Nope. %)
So you think it is reasonable to perform a Count with the following regular expression using the CTRL+R Replace Dialog?
regex=
^
Press Count button.
What do you get?
Instead of all the sniping (not there's always necessarily anything wrong with that) -
why not just say that it is implemented properly according to the "rules" (if it is)
give a solution whether asked for or not (and don't bitch about it)
since we all like to do that
furthermore, if you know everything about regular expressions, you must be a ________
It's not a snipping but the 1-st link google show me on request "regular expressions".
I don't know EVERYTHING, but i do know in this situation it works as intended. And this is what i (and not only i) said few times in this topic. And if you look in the 1-st reply in this thread - you'll see the solution. But he don't need it, so who cares :)
You must be REALLY BLIND.
The solution is in my own message, at the start of this thread.
So don't try to be the smarter guy pointing out that what you do does the work, too.
There are even better solutions than yours.
The best direct solution probably is the one looking for the searched string and _only_ the one possible character following it and replacing this by this _only_ one possible character. There is absolutely no need to replace anything behind it. How smart is that?
The pain in the ass here is that, by removing only the beginning of the line, the cursor is not recognized to have in fact moved. It should have, though, because also the current implementation for counting the number of starts-of-line doesn't return a result at all.
Funny you have nothing to say about that, wise man.
>>You must be REALLY BLIND.
I like this guy :) Do you already hate me? :)
>>The solution is in my own message, at the start of this thread.
So, you're talking to yourself? %) Asking for solutions and giving it in the same message? %)
>>So don't try to be the smarter guy pointing out that what you do does the work, too.
I don't try to be someone :) I simply answered your question. You ask - i answer. Clean and clear %) All beside this is a flood :)
>>There are even better solutions than yours.
Yes! A lot of! %)
>>The best direct solution probably is the one looking for the searched string and _only_ the one possible character following it and replacing this by this _only_ one possible character. There is absolutely no need to replace anything behind it. How smart is that?
Very, very smart! :) Why did you ctreate this thread? :)
>>The pain in the ass here is that, by removing only the beginning of the line, the cursor is not recognized to have in fact moved. It should have, though, because also the current implementation for counting the number of starts-of-line doesn't return a result at all.
>>Funny you have nothing to say about that, wise man.
Why should i say something about it? %) It has nothing connected with discussion topic and i have nothing to say about it, so don't say - it's simple %)
You seem to be really doing your best to make a dumb impression. Well, you do!
>>The solution is in my own message, at the start of this thread.
So, you're talking to yourself? %) Asking for solutions and giving it in the same message? %)
Wow, you must be missing a number of connections in what others have as brain.
Nowhere in my message I ask for a solution. So why persist you stupid interpretation?
> I don't try to be someone :) I simply answered your question. You ask - i answer.
Once again: nothing asked.
>>There are even better solutions than yours.
> Yes! A lot of! %)
So you seem to recognize that you really didn't think your first reply through. I guess you were all too greedy thinking you could make a good impression. You even didn't write a message, just posted a single line.
>>The best direct solution probably is the one looking for the searched string and _only_ the one possible character following it and replacing this by this _only_ one possible character. There is absolutely no need to replace anything behind it. How smart is that?
> Very, very smart! :) Why did you ctreate this thread? :)
You don't know why? Oh, that doesn't even surprise me anymore. You really don't read.
And yes, I am smart. At least I show progression and am not stuck at repeating the same nonsense over and over again.
>>The pain in the ass here is that, by removing only the beginning of the line, the cursor is not recognized to have in fact moved. It should have, though, because also the current implementation for counting the number of starts-of-line doesn't return a result at all.
>>Funny you have nothing to say about that, wise man.
> Why should i say something about it? %)
At least you show that you are not consistent. Didn't you say "you ask - I answer"? Well, why don't you now, then?
> It has nothing connected with discussion topic and i have nothing to say about it, so don't say - it's simple %)
Oh, this is supposed to answer that question? It shows again you totally missed my point.
Think about this, then: how come a count of ^ doesn't work, while a count of $ does? There should be really NO difference between the two, since both characters are only ANCHORS, as you like to point out.
No movement shoud be made, but it seems there is, and this i what also a guy like you should consider to be wrong.
Because searching for the end of line by using $ and replacing this by any character string, what happens is that the line is extended by this string, thus creating a new end of line behind it. This also shows that there really should be no movement either when searching for $ only, because the text is inserted before the newline character(s).
Now, how do you want to explain this newly created end of line position is NOT found, while the same beginning of the line when using ^(...) is?
Well, i'll skip the topmost part of your message as it funny, but very long and pointless dialog :)
Only few replies:
>>Didn't you say "you ask - I answer"? Well, why don't you now, then?
I did. You asked:
>How to: 1 ^ start-of-line per line in regexp?
and
>Is or will there be a solution for my problem using the CTRL+H Replace Dialog?
I answered:
>^[0-9]+\t(.*)$
>replace with
>\1
That was becouse i had an answer to that your questions. Now i don't have an answer to your other question - so i don't answer. Is it hard to understand? :)
>>Oh, this is supposed to answer that question? It shows again you totally missed my point.
It was a reply to
>Funny you have nothing to say about that, wise man.
If you'll start reading not only my messages but your own ones, which my messages are replies to - things could become more clear to you ;)
>>Think about this, then: how come a count of ^ doesn't work, while a count of $ does? There should be really NO difference between the two, since both characters are only ANCHORS, as you like to point out.
No movement shoud be made, but it seems there is, and this i what also a guy like you should consider to be wrong.
Because searching for the end of line by using $ and replacing this by any character string, what happens is that the line is extended by this string, thus creating a new end of line behind it. This also shows that there really should be no movement either when searching for $ only, because the text is inserted before the newline character(s).
>>Now, how do you want to explain this newly created end of line position is NOT found, while the same beginning of the line when using ^(...) is?
Well. How do you explain that Count button says that regular expression formed badly for regex "^.*" if there are emty lines in the text, but Find button will find'em all, one by one, even empty lines? I DO NOT have explanation for this. I can only assume that Count algorithm is broken.
The thread starter boy should learn how regex work first.
> I expected the ^ start-of-line marker to be active only once per line.
NO.
Learn RegEx and use the RegEx feature as it is implemented.
This solution:
^[0-9]+\t(.*)$
replace with
\1
is nearly correct but greedy.
This
^[0-9]+?\t(.*)$
replace with
\1
should work better.
Or:
^\d+?\t(.*)$
replace with
\1
All repliers should read and think before they post.
I am NOT looking for any solutions.
"I am NOT looking for any solutions."
"Is or will there be a solution for my problem using the CTRL+H Replace Dialog?"
Maybe you should go and read your post over and over yourself?
It seems to me that the argument going on here is about the original intention of the thread. As English is not the native language of a large number of users of this forum, I wonder if hair splitting about precise meanings is a good idea. It usually isn't anyway.
It would also help if some of you people registered and logged in before posting - it's hard to work out who said what when everyone is called "nobody".
He had a problem, caused by ^ not being treated as once per line. He found a workaround, but is suggesting that this behaviour be changed. That's what should be being discussed.
His question:
"Wouldn't it make more sense to automatically treat the ^ start-of-line as "1 per line" feature, allowing users to do this repeatedly (on the changed line) by checking the Incremental checkbox?
Additionally, checking Incremental when using $ might be implemented as "Check again the end of the line (until no longer matched)". I would very much welcome ^ and $ to be treated "equally" in this way, that is, with the same options checked both ^ and $ work either _only once per line_ or _repeatedly_.
Are there any advocates for this?"
This is very much all there is to say about it.
Of course, I was pointing at the Recursive option, which I called Incremental. I knew there was such an option, but I didn't look ahead when I found a name that seemed suit my purpose.
There's no need to, as I am not looking for any solutions. I just ask IF there is or will be a solution. I am not asking HOW to accomplish my goal, since I have been able to do so. Is that SO very hard to understand???
Good point, but Scintilla's regex engine don't have lazy quatifiers and \x character classes :(