What's the easiest way to anchor a search to the beginning of the document?


For example, if the document is this:

-----------------------------------------------
Test A
Test B
Test A
Test B
Test A
Test B
-----------------------------------------------

... and let me temporarily use "^t" to represent the top of the document, I'd like to do a search for "^tTest A", which would only find the "Test A" text at the very beginning, but none of the others.


How would I do this?

That is a really good question!

Usually, this shouldn't be a problem with a Perl regular expression (available since UE V12). However, I've tried both and and none of them work.

At least the last one should work. What it does (should do) is to assert that Test A can be matched at the beginning of a line (^), and that no carriage return/line feed can be matched before that - a condition which should only be true at the beginning of the very first line in the document. Alas, it also matches Test A at the beginning of line 3. Maybe someone else has an idea what could be done to make the regex (which works in other regex tools like RegexBuddy) work in UE? I've already tried using character classes or end-of-line anchors, but no luck so far.

Of course, you could (if that works for you) create a macro that first jumps to the top of the file, inserts some special characters there (like "ÿÿÿ") and then searches for "^ÿÿÿTest A". Depends on what you want to do with the result. And don't forget to remove those characters again when you're done

Best regards,
Tim

Tim
I think it may be a bug in the implementation of the Perl regex by UE. I tried the regex
(?<!\r\n)^Test A
in a couple of other text editors which have the PCRE regex package and they all work as they should - i.e. they will match the very first entry only.

Jane

pietzcker wrote:Of course, you could (if that works for you) create a macro that first jumps to the top of the file, inserts some special characters there (like "ÿÿÿ") and then searches for "^ÿÿÿTest A". Depends on what you want to do with the result. And don't forget to remove those characters again when you're done

Oh, I knew that there were longer and more convoluted ways of going about it. But I figured that this was the most efficient way of doing it, it's just that I didn't know how to go about it.

I contacted IDM support about this issue and they informed me

that the negative look behinds are not currently supported in UltraEdit's Perl Regular Expressions

So a negative lookbehind like
(?<!\r\n)^Test A
will not work until that is rectified.

Jane

Very well, the convoluted scripting approach it is!

In your case, yes. But generally, negative lookaround does work in UE. E. g. (?<!Foo)Bar will match Bar but won't match the Bar in FooBar. Just an issue with line breaks, it seems.

pietzcker wrote:In your case, yes. But generally, negative lookaround does work in UE. E. g. (?<!Foo)Bar will match Bar but won't match the Bar in FooBar. Just an issue with line breaks, it seems.

That about sums it up. I looked into this further (after learning more about RegEx), and both positive and negative lookarounds are supported by UE. However, look *behinds* (both positive as well as negative), return an incorrect result when used with line breaks.

Even worse: Positive lookaround works (with the exception of line breaks, as you wrote) for search actions; however, in a replace action, it fails. UE claims to do something ("45 occurrences replaced") but doesn't do anything. This bug has been known to IDM since version 12.