Shift+F3 no more works

Alan Kilborn

@mkupper said in Shift+F3 no more works:

it’s best to dial up your favorite mysterious music when attempting to discover edge conditions of what happens if you perform regular expressions, backwards.

@PeterJones Maybe the user manual should provide an example?

PeterJones

@Alan-Kilborn said in Shift+F3 no more works:

Maybe the user manual should provide an example?

If someone were to create an issue in the UM repo, and provide an example regex that will not work as expected in backwards mode, I could add it into the manual. (But I don’t know how to craft a simple regex that would have an obvious meaning when searching forward, but mess up when searching backward, so I cannot come up with an example myself.)

Alan Kilborn

@PeterJones

It seems like there should be one when that “power user” mode thing was added to Notepad++. I’ll see if I can find it.

guy038

Hi, @reinhardhofmann, @alan-kilborn, @mkupper and All,

Hi, All, do you know that, even with the regexBackward4PowerUser enabled, there are still some cases where the backward regex search do not work ?

For example, in a new tab, copy this text :

This is à test
This is à second test
This is à third test
This is à final test

Note that, in each line, I replaced the indefinite English article a with the French accentuated letter à !

Move to the beginning of this file
Select the à letter, in line 1
Open the search dialog ( Ctrl + F )
Tick the Wrap around box option
Select the Regular expression search mode
Hit on the Find Next button

=> The à char, in line 2, should be selected

Close the Find dilaog ( Esc )
Hit the F3 key

=> Again, the à char, in line 3, should be selected

Now, use the Shift+ F3 shortcut => Nothing happened ???

( Of course, I suppose that you do have the string regexBackward4PowerUser="yes", in your active config.xml file ! )

This happens ONLY IF :

Your search mode is Regular expression
The searched character is over \x{007F}
The current encoding file is an Unicode one : UTF-8, UTF-8-BOM, UTF-16 BE BOM or UTF-16 lE BOM

Luckily, I’ve found a way around this limitation. The rule is :

When a backward regex do not work as expected, simply add the regex string (?=(?s).) at the end of the present regex !

Thus, if we, now, search for the regex à(?=(?s).), you should be able to search backwards or forwards, at any time !

Best Regards,

guy038

guy038

Hello, @peterjones, and All,

Regarding examples to include in the Official documentation, here are two examples which :

Do not work at all, in backward direction, if the regexBackward4PowerUser is not set
Else, allows the regex backward search but gives right results in the first example only

Let’s consider the following text, where I included, this time, the classical English a article :

This is a test
This is a second test
This is a third test
This is a final test

If the regexBackward4PowerUser option is enabled ( "yes" ) :
- The regex (?-s)i.*te does find the greatest range of characters, between a i letter and the te string in BOTH forward AND backward search
- The regex (?s)i.+ does find the greatest range of chars, beginning with an i letter, in forward search BUT finds multiple wrong occurrences when used in backward direction !
If the regexBackward4PowerUser option is disabled ( "no" ) :
- The two regexes works as expected in forward direction and CANNOT be used in backward direction

BR

guy038

Alan Kilborn

@guy038

even with the regexBackward4PowerUser enabled, there are still some cases where the backward regex search do not work ?

YES! No one ever said all regexes work fine moving backward in this mode. If they did, there’d be no need for the mode to exist at all!

Alan Kilborn

@guy038 said in Shift+F3 no more works:

The regex (?s)i.+ does find the greatest range of chars, beginning with an i letter, in forward search BUT finds multiple wrong occurrences when used in backward direction !

What about (?s)i.+(?=.) for this case?
(I’m away from my Notepad++ PC right now so I can’t try it)

Mark Olson

Nobody has talked about trying to actually solve the issues with backward regex searching, but it seems to me like a potential solution might be along these lines:

when someone regex-searches backwards:
    if need-to-re-search-file:
        regex-search the entire file starting from the beginning
    find the last match before the current position
when someone edits a file or changes the regex to be searched:
    set need-to-re-search-file = true

Obviously I’m not saying this would be easy and I fully expect it would be very hard to implement, but what do people think about that idea?

Coises

@Mark-Olson said in Shift+F3 no more works:

Nobody has talked about trying to actually solve the issues with backward regex searching

Perhaps I have missed it, but I have not yet seen the issues precisely defined. In particular, I haven’t seen it stated whether the problem is that:

the expected result of backward searching with a regular expression is not always well-defined.
the expected result is well-defined, but the implementation — due to Boost, Scintilla, Notepad++ or some combination thereof — is not always correct.

Is it known which applies, and under what specific conditions?

guy038

Hello, @reinhardhofmann, @mkupper, @alan-kilborn, @peterjones, @mark-olson, @coises and All,

Oh…, in my previous post, I did a mistake : I spoke about a second example (?s)i.+. But, I really did tests with the regex (?-s)i.+ !

When the backward regex search is allowed, EACH backward regex (?-s)i.+ finds a string, reduced by a single character

But, unfortunately, Alan, the regex (?-s)i.+(?=(?s).) do not give the expected results, allthough it reduces the number of steps before a CORRECT backward occurrence !

Thus, my general rule should be modified as :

When a backward regex do not work as expected, try adding the regex string (?=(?s).) at the end of the present regex. It may work correctly !

Best Regards,

guy038

Coises

I wrote in Shift+F3 no more works that the problem might be:

the expected result of backward searching with a regular expression is not always well-defined.

Example of how this could be ambiguous:

Given the text:
xabcdefy
and the regular expression:
(a..(d..)?|.e)

when matching normally there is one match — abcdef. When matching backward, is there one match — abcdef — or are there two matches — de and abc?

What about the regular expression:
(a..(d.)?|.f)
matching backward: abcde or ef and abc?