Bad Bracket Highlighter

  • @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.

  • @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!!! )

  • @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…

  • 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)

  • 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). :-)

  • 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à !



  • @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.

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

  • 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

    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.

  • 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.

  • @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…

  • 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):
        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)

  • @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.


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

Log in to reply