Bad Bracket Highlighter

Scott Sumner

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.

Imgur
(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.