Community
    • Login

    Bad Bracket Highlighter

    Scheduled Pinned Locked Moved Help wanted · · · – – – · · ·
    29 Posts 4 Posters 10.5k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • guy038G
      guy038
      last edited by guy038

      Hello, @salviasage, @scott-sumner and All,

      I forgot an very IMPORTANT point about the free-spacing mode, which is introduced with the (?x) modifier


      A) IF your free-spacing pattern is a SINGLE-line regex, for instance :

      (?x) abc \r \n def \r \n ghi
      

      Then :

      • From your browser, copy the preferred regex, in the clipboard, with Ctrl + C

      • Then, you have the choice between two possibilities :

        • 1) Open the Find dialog with Ctrl + F then paste, with Ctrl + V, the regex in the Find what: zone, which overwrites the present contents of the search zone

        • 2) Paste the regex, anywhere in a document or a new tab, then re-select the regex and open the Find dialog, with Ctrl + F, which, automatically, fill up the Find what: zone, with the MONO-line selection


      B) IF your free-spacing pattern is a MULTI-line regex, for instance :

      (?x)
      abc \r \n
      def \r \n
      ghi
      
      • Like above, from your browser, copy the preferred regex, in the clipboard, with Ctrl + C

      • This time, you cannot paste the regex, directly, in the Find dialog, with Ctrl + V ! You must use the case 2). So :

        • Paste the regex, anywhere in a document or a new tab, then re-select the regex and open the Find dialog, with Ctrl + F, which, automatically, fill up the Find what zone, with the correct MULTI-line selection !

      You may test, the single-line and multi-line regexes, with the sample text, below :

      abc
      def
      ghi
      

      Remark :

      • The \R syntax, standing for any kind of EOL, is forbidden in free-spacing regexes. So, according to the type of your file, you’ll replace any \R pattern with one the syntaxes \r\n , \n or \r !

      Cheers,

      guy038

      1 Reply Last reply Reply Quote 1
      • Scott SumnerS
        Scott Sumner @SalviaSage
        last edited by

        @SalviaSage said:

        if there are mixed line endings, I can change them all in a file to the ending I want using notepad++ replace command.

        Why do this when you could simply use the Edit menu’s EOL Conversion submenu? I’d suggest doing it that way (or via double-clicking on the line-ending area on the status bar)…less error prone…and you don’t have to remember the regex to do the desired conversion.

        1 Reply Last reply Reply Quote 0
        • SalviaSageS
          SalviaSage
          last edited by

          @Scott-Sumner

          The reason why I can not trust that built in function in notepad++ is because it simply does not work… at least it does not work real-time. I tried it.

          That is why, I am loving my regex macro because it does work real time, you can try it yourself by pressing ctrl+m to insert CR line, and then click on that, and the line won’t be converted.

          whereas my regex macro does convert everything properly.
          And yeah, now that I can save my regex as a macro (thanks for telling me how to do that) I don’t have to remember to type anything in the replace window.

          But, I still can not detect the possible mixed line endings, without manually opening up the EOL display and looking through myself (eek… what are computers for!!! )

          Scott SumnerS 1 Reply Last reply Reply Quote 0
          • Scott SumnerS
            Scott Sumner @SalviaSage
            last edited by

            @SalviaSage

            So the EOL Conversion feature only does something right at the time when you execute it. It doesn’t set up any “real-time” or “as you type” monitoring to intercept whatever badness you choose to do and correct it.

            So files basically have a line-ending type as a convenience for the user. You hit Enter and the correct line-ending is inserted. You paste data from another source that has different line-endings and at the paste Scintilla sets the line-endings to match the destination’s EOL configuration. It is basically a set-it-and-forget-it kind of thing. HOWEVER, you can go around it, in a few ways (and probably more than this short list):

            • Pressing ctrl+m when you haven’t remapped ctrl+m to something else (and you aren’t using Mac EOLs)
            • Doing a regex replace where your replacement text uses \n or \r or \r\n and the sequence you use doesn’t match your file’s current EOL choice
            • Pasting data using the Clipboard History panel when an entry there has line-endings that don’t match your file’s current EOL choice

            So I’d think most people just avoid doing these things, and they don’t ever deal with the problem of mixed line-endings in one file…?

            May I ask why you are using ctrl+m in this way…or is this just something that you discovered will cause a mismatch and that is why you gave that as an example?

            I am loving my regex macro because it does work real time

            Rereading your most recent posting, I’m concerned that I am not understanding your “in real time” statement. For example, how does your regex macro work in real time? It is an on-demand thing…nothing happens until you run the macro…very much like the EOL conversion command.

            I still can not detect the possible mixed line endings, without manually opening up the EOL display and looking through myself

            I will try to think of some things that can be done about the mixed line-ending situation…

            1 Reply Last reply Reply Quote 1
            • Scott SumnerS
              Scott Sumner
              last edited by

              BTW, pressing ctrl+j if you remove the default Notepad++ keymapping tying that to the Join Lines feature will insert a \n line-ending in the current file, regardless of the file’s EOL setting. (This can be added to the previous posting’s bullet list)

              1 Reply Last reply Reply Quote 0
              • Scott SumnerS
                Scott Sumner
                last edited by

                So as a prevention from pressing ctrl+m inserting a Mac line-ending into a non-Mac encoded file (as well as possibly ctrl+j inserting a Unix line-ending into a non-Unix encoded file), see the CHARADDED Pythonscript in this thread. This script should be set to be run upon Notepad++ startup.

                More comments to come on this topic…which unfortunately is off-topic for this thread (but I didn’t do that). :-)

                1 Reply Last reply Reply Quote 0
                • guy038G
                  guy038
                  last edited by

                  Hello, @salviasage, @scott-sumner and All,

                  Oh, my God ! there a very simple way to prevent the Ctrl+ M shortcut from inserting the CR character ( \x{000D} ) , which is displayed in reverse video !.. Like me, simply, affect the Ctrl+ M shortcut to the Mark dialog ( Search > Mark… ) :-)))

                  Et voilà !

                  Cheers,

                  guy038

                  Scott SumnerS 1 Reply Last reply Reply Quote 2
                  • Scott SumnerS
                    Scott Sumner @guy038
                    last edited by

                    @guy038

                    very simple way

                    Yes, but ctrl+m is just a special case of ALL of the control-plus-(mostly)letter codes that one hasn’t assigned shortcut functions to. The Pythonscript in that other thread takes care of all of them at once, so fat-fingered users should not see odd black-boxed things again in their editor window (like the picture at the bottom of this posting)…unless they Undo (ctrl+z) the change made by the script. Sadly, I don’t believe there is a way to remove something from the undo buffer without purging the entire thing. :-(

                    It’s a more complete solution: It takes care of the original problem of ctrl+m inserting a \r – without having to assign it a function, and some other things that a user may experience and not like.

                    By the way, the script won’t interfere with things like ctrl+a or ctrl+c or ctrl+v, etc, because those (and your ctrl+m, @guy038) get snared as commands at a higher level and don’t pass through–like unassigned ones–to be added as “text” to the current editor window.

                    Imgur
                    (those are ctrl+w and ctrl+e, respectively, as text)

                    Scott SumnerS 1 Reply Last reply Reply Quote 2
                    • Scott SumnerS
                      Scott Sumner @Scott Sumner
                      last edited by Scott Sumner

                      So one way to avoid having mixed line-endings in your file is to automatically run a check each time the file is saved, and if any inconsistent line-endings are found, correct them at that time. Here’s a Pythonscript that will do that; I call it LineEndingRepairAtSave.py:

                      try:
                      
                          LERAS__bad_eol_regex_via_good_eol_dict
                      
                      except NameError:
                      
                          LERAS__bad_eol_regex_via_good_eol_dict = {
                              '\r\n' : r'\r(?!\n)|(?<!\r)\n',
                              '\n'   : r'\r\n?',
                              '\r'   : r'\r?\n',
                          }
                      
                          def LERAS__callback_npp_FILEBEFORESAVE(args):
                              correct_eol_for_this_file = ['\r\n', '\r', '\n'][notepad.getFormatType()]
                              editor.rereplace(LERAS__bad_eol_regex_via_good_eol_dict[correct_eol_for_this_file], correct_eol_for_this_file)
                      
                          notepad.callback(LERAS__callback_npp_FILEBEFORESAVE, [NOTIFICATION.FILEBEFORESAVE])
                      

                      The idea is that you run it once per Notepad++ session and it will stand guard against the tyranny of mixed line-endings in your saved files. Maybe it takes a noticeable amount of time to run on really large files…dunno…use at your own risk.

                      1 Reply Last reply Reply Quote 4
                      • SalviaSageS
                        SalviaSage
                        last edited by

                        I want to cry with joy at this moment…

                        This is what makes notepad++ great…

                        A special thanks to Scott as usual for his contribution.

                        Scott SumnerS 1 Reply Last reply Reply Quote 2
                        • Scott SumnerS
                          Scott Sumner @SalviaSage
                          last edited by

                          @SalviaSage said:

                          I want to cry with joy at this moment…

                          LOL. …and I thought you’d complain that it isn’t an as-you-type or an as-you-paste solution! I still wonder why mixed line-endings is a real problem for you. I’ve been using Notepad++ for a long time and it rarely is a problem for me…

                          1 Reply Last reply Reply Quote 2
                          • Scott SumnerS
                            Scott Sumner
                            last edited by guy038

                            Slight change to the Pythonscript I posted earlier. I noticed that does not work correctly when the Notepad++ user executes a Save All. Here’s an update to (only) the callback function part that will fix this, just replace the old LERAS__callback_npp_FILEBEFORESAVE function definition with the following:

                            def LERAS__callback_npp_FILEBEFORESAVE(args):
                                notepad.activateBufferID(args['bufferID'])
                                correct_eol_for_this_file = ['\r\n', '\r', '\n'][notepad.getFormatType()]
                                editor.rereplace(LERAS__bad_eol_regex_via_good_eol_dict[correct_eol_for_this_file], correct_eol_for_this_file)
                            
                            1 Reply Last reply Reply Quote 2
                            • SalviaSageS
                              SalviaSage
                              last edited by

                              @Scott-Sumner

                              Dear Scott.

                              I am afraid this script and the broken bracket highlighter is no longer working.

                              I confirmed that the startup script of the PythonScript plugin is working by using some other scripts.

                              But, these 2 which are very similar to each other in nature, are just not working.

                              I don’t know why, I tried fixing it and I could not. So, I have to appeal to you for help.

                              :(

                              1 Reply Last reply Reply Quote 0
                              • SalviaSageS
                                SalviaSage
                                last edited by

                                Ignore above, there were 2 syntax errors in there for some reason,
                                and I fixed it. I must have made a mistake myself.

                                1 Reply Last reply Reply Quote 1
                                • Alan KilbornA Alan Kilborn referenced this topic on
                                • First post
                                  Last post
                                The Community of users of the Notepad++ text editor.
                                Powered by NodeBB | Contributors