Backward regular expression searching disabled

  • So I thought I’d bring the discussion from HERE and HERE to a new thread to avoid pollution of the RC thread(s) with non-critical issues.

    I’m okay with regex upward searching being fully disabled; truth be told for a long time I thought it was (Backward direction checkbox would grey out when regex mode selected). But I suppose there were “holes” in the UI that are now plugged.

    I’ve got to say that I’m not a “Find Next” or “Replace (Next)” person in general. For me it’s usually “Find All in Current Document” or “Replace All”. So maybe a workaround is to do a FAiCD and then look for a match there that would be to the “upward side” of the current caret position. Don’t know how that would set with our resident regex guru @guy038.

    Anyway, @guy038’s mention in another thread of his “Shift+F3” love got me thinking about a Pythonscript solution to reinstate backward regex find. Stay tuned here as I may post something…

  • @Alan-Kilborn

    I’m sure you already saw this but in case you didn’t.

  • @Ekopalypse

    Ah; hadn’t seen that quite yet – a LOT of new postings this morn before my coffee. Yawn.

    My thoughts (who cares, right? :-) )

    • I suppose it is a good compromise, although one that I don’t need. :-)
    • It might have been better for the devs just to work on a real solution; going forward everyone will just be pointed to the “hacky workaround” solution. :-)
    • I guess it is a way to “take the temperature” of how many people feel they need it, as they’ll have to ask about it (unless it is put in the docs – dunno if that is a good idea or not)
    • Another positive might be that anyone that uses it and then says “hey, searching backward with regex gives odd results” will immediately be shut down from complaining.

    I’m going to continue with my script development on this, mainly because I think there are things to be learned…

  • @Alan-Kilborn said in Backward regular expression searching disabled:

    a LOT of new postings this morn before my coffee. Yawn.

    WHAAT - you start your PC before you get a cup of coffee??
    I don’t know - this never came into my mind - does this even work??
    Can a PC started without having this delicious, brown, hot and magical stuff sitting next to you? :-D

    Beside this, I agree to all of your other points :-)

  • @Ekopalypse

    I pretty much hit the PC wake button and the coffee maker start button simultaneously.
    The PC always wins the race.

    What follows is here to avoid more pollution of an RC thread (which is reserved for critical issue discovery):

    So HERE someone said: Is there any list with listing all such no-UI options? I’m asking because I have seen such hidding settings somewhere but I cannot locate them. It would be good to make and put such a list somewhere. To that I respond by saying to see my 3rd bullet point above.

    And HERE someone said: Maybe this could be an option in Preferences / Misc. under the other find options (Don’t fill… / Monospaced …). My thought on this would be that this would be a Preference setting that isn’t truly necessary (I think an effort should be made to keep the number of settings to a low count) and one that would spur a ton of questions here that would have to be answered, for a feature that would be “meh” in the end to most people.

  • @Alan-Kilborn
    Such hidden settings should simply be documented, that’s enough. If we don’t know about their existence, why introduce them? I opened the bug in the manual

  • @ArkadiuszMichalski

    You miss my point, but that’s okay. Not everybody is going to “get it” and everyone can have their own opinion (there’s a famous quote about that). And I see from recent issues on github that you are quite opinionated. :-)

  • @ArkadiuszMichalski said in Backward regular expression searching disabled:

    Such hidden settings should simply be documented, that’s enough.

    My favorite is:

            <GUIConfig name="commandLineInterpreter">powershell</GUIConfig>

    Which makes the menu File => Open Containing Folder => cmd actually open PowerShell instead of cmd.exe.


  • @Michael-Vincent
    Thx, I add your tip to an open bug in the manual. If anyone knows any other hidden settings, please add them directly in the opened bug, it will be easier to describe them later in the manual.

  • As part of these scripts I’d like to show a “call tip”.
    I can’t seem to make Pythonscript do it, but having never used a call tip before I’m maybe not sure of all I need to do.

    If I try this in the PS console:

    editor.callTipShow(editor.getCurrentPos(), 'blah')

    and do it repeatedly, I think I can sometimes see the call tip pop up briefly, and then vanish.

    What am I doing wrong?
    Is there more that I need to do?
    I looked through all of the calltips functions and didn’t see anything relevant:

    editor.callTipSetHlt(start, end)
    editor.callTipShow(pos, definition)

    Help! @Ekopalypse ?

  • @Alan-Kilborn

    works as long as the editor has the focus but running from console
    puts focus back to textbox control. If you run this within a script you will see it does show blah.

  • @Ekopalypse

    Ah! Okay, thanks. It seems like I did start within a script and had trouble with it, so (usual debug technique) I was trying console operations to isolate. Looks like this is a case where console ops make it worse, not better. I’ll get back to my script now. :-)

  • Well there’s nothing like trying to tackle a problem to show you how difficult it is. :-)

    And I wasn’t even initially trying to do backward regex searching.

    I was trying to do a forward search, while considering the caret position.

    And there were cases that came up that it was just, well, very difficult to handle.

    For instance, if you search the whole file for matches and then try to select the one at or further on from the caret position (this was the base algorithm), you have a problem if your regex match starts before your caret position and due to a greedy expression it blows through and beyond your caret position. Then you have no frame of reference for really where (to the right of your caret) you really should match. (Starting the search at the caret position doesn’t help because I wanted to handle lookbehinds correctly with this).

    This probably doesn’t make much sense; you have to “get close to the problem” to fully understand it, perhaps.

    So, anyway, new respect for those that can write this algorithm correctly!

  • @Alan-Kilborn said in Backward regular expression searching disabled:

    So, anyway, new respect for those that can write this algorithm correctly!

    And, to date, I’m NOT including the Notepad++ developers in this “respect” (sorry!), because most of us have read the complaints about matching that logically seems like it should occur but doesn’t, i.e., this scenario:



    Caret between the a and the b.

    Regex search for (?<=a)b won’t match the b.

  • Hello @alan-kilborn and All,

    Don’t forget that, in addition to the basic algorithms, used in our modern regex engines, they usually perform a lot of internal optimizations. For instance, to avoid backtracking process, dead-end searches and other goodies !

    Such a big task, indeed !

    Regarding your example :

    • if the Wrap around option is not ticked the regex matches the b letter, ONLY IF  the caret location is before the a letter

    • if the Wrap around option is ticked, obviously, the regex matches the b letter, whatever the caret location !

    Not that, with the enhanced regex engine of François-R Boyer, and tested with N++ v6.9, it does match the b letter with :

    • The Wrap around not ticked

    • The caret located between letters a and b

    Best Regards,


  • @guy038 said in Backward regular expression searching disabled:

    with the enhanced regex engine of François-R Boyer

    Too bad we can’t dust off Monsieur Boyer and get him to do some more work on Notepad++ codes! :-)

    Regarding your example

    Right. The example was done because everyone wants it to work like I suggested (via counterexample). Because you can logically see the “a” there before the “b”. Nothing more.

    Nobody wants to do crazy workarounds (or have to keep in mind some special things) to find it. Workarounds are fine, but situations like the one I described are potential time suckers: “Notepad++ said my data was not matched, so I spent an hour or 2 working from the assumption that it was right and did this and that and blahblahblah and in the end it was all for nothing, because of the original “lie” that was told”.

  • Banned


    Follow this step,To Backward regular expression searching disabled

    Step 1:- Start Notepad++ 7.5 (32-bit) from a fresh unzip of the portable install.
    Step 2:- Execute any Find operation with Regular Expression as the search mode (note that when the search mode is changed to Reg Exp the “backward direction” checkbox becomes disabled–correct behavior).
    Step 3:- Quit and restart Notepad++ 7.5.
    Step 4:- Invoke the Find dialog. Note that the search mode is Reg Exp but the “backward direction” checkbox is now incorrectly enabled.

    I hope this information will be useful for you.
    Thank You.

Log in to reply