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:

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

2. 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?