Bad Bracket Highlighter

[Scott Sumner]

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

[Scott Sumner]

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)

[Scott Sumner]

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

[guy038]

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 Sumner]

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

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

[SalviaSage]

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 Sumner]

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

[Scott Sumner]

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)

[SalviaSage]

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

:(

[SalviaSage]

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