• There are terrible problems with the automatic saving feature, if you rely on it I strongly advise you to make a copy of your “backup” folder and session.xml in %APPPATH%\Notepad++ before every closing of either Notepad++ individually or the entire computer, and keep several copies of them.
    It’s better to copy also the N++RECOV folder if you have one, although I’m not seeing problems with that lately.

    For me it’s not an unbearable problem because I always use the Windows’s hibernation, so I restart Notepad++ only once every couple weeks.

    Recently I haven’t experienced problems when closing explicitly Notepad++, but every time that I let it be closed by the Windows’s shutdown procedure I lose all the contents of the backup folder, and thus all the so-to-say unsaved files if I’m not careful.

    What usually (maybe always) happens is that the “backup” folder gets nuked, and after that at the first next start of Notepad++ the session.xml gets cleaned of all the now unreachable unsaved files, without any warning.
    At that point you’ll better have a backup of session.xml besides the backup folder, because although all the files’ contents are in the folder there are easily old leftover files in there too and it will be hard to find out what you were working with if you don’t have the session.xml references.

    As I’m at it, beware that there are frequently problems after a system crash or especially a Notepad++ one: it has a feature that supposedly attempts to save your work, but it actually often (every time in the last couple years, to me) does the exact opposite by zapping the entire backup folder!!!
    So as soon as you see a message from Notepad++ that it is about to crash before clicking the message go to %APPPATH%\Notepad++ and copy your backup folder and session.xml, preferably once after every Notepad++ message (I don’t recall well but there are two or three, and I seem to recall that the latest state gets attempted to be saved only after the first).

    BTW yes, it is an horrific problem, it even got me to learn vim in search of a more reliable alternative, but it turned out that even vim is not really as great as they say so I’m still using NPP.
    After the next loss I’ll spend some months learning emacs, then probably something else and in a couple years maybe I’ll have freed myself from this editor.

  • I really like Notepad++… for me to poop on!

  • What I guess I found out so far is the following

    First npp tries to detect if the file is a BOM file, if it is,
    it gets rid of the BOM signature and continues reading the file in converted utf-8.

    If it isn’t a BOM file it’s calling chardet library to see what codepage to use.
    If chardet returns, it is checked if it is reported to be utf-8 -> go on reading the file …
    if not, convert it to utf-8.

    But this, of course, happens only “virtual” for scintilla control.


  • good idea! I’ve never thought about this possibility ;-)
    some seconds later. it doesn’t work.
    copy *.xml *.ttt
    notepad++ interpretes the 1(?)st line:
    “<?xml version=“1.0” encoding=“UTF-8”?>”

    and gives his own interpretation, as an xml-file.
    great idea!

    but if we do THIS:
    kill 1st line: “<?xml version=“1.0” encoding=“UTF-8”?>”
    and than edit with notepad++, than it will works!

    if there’s not another solution, than would this works. ok.
    I’m sure, there must exist something, in settings? in commandline? to ignore xml-function… it would be very lovely!

    thanks a lot for Your ideas
    yours Klaus

  • @Giancarlo-Riccio

    Are you by any chance talking about the capability provided by Notepad++'s Incremental Search feature?

    See the Search menu -> “Incremental Search”.

    If not, please clarify your inquiry…

  • @Juan-Manuel-Pedrosa

    Hi Juan-Manuel,
    an update shouldn’t change this but if you did a new installation
    than it could be the case.


  • @Tal-Tene

    I didn’t mean to imply that…there are some that are 64-bit. But, obviously the ones you are trying are not.

  • You could try to construct tags file for that and use a tag lookup plugin.
    But you probably will have to do create a tags file by yourself since ctags will not know how to parse your txt file.
    I am the author of TagLEET so I will recommend it.

    If your errors codes are in the format Exxxx then all you need is create a file with a line for every error code that refers to your errors.txt file.
    E0001<tab>\full path\errors.txt
    E0002<tab>\full path\errors.txt

    Note that full tags file has many more options, I describe the minimal thing that works.

    The file should be sorted and saved under the name ‘tags’ without extension in the directory of the log file or one of its parents.
    In the log file perform a tag lookup for E0001, the plugin will consult the tags file, realize that the tag is defined in errors.txt, open it and find the 1st occurrence of E0001.

  • Thanks for your reply.
    I can see that this error occurs when the encoding is set to ANSI.
    When I type something in UTF-8 and then switch to ANSI, I can see that single “ó” in UTF-8 is encoded as two bytes in ANSI, but only first byte is counted in “Sel:”.
    Similar case is when a file is created as ANSI and there are only legal (correct) ANSI characters - diacritic characters (ą, ę, ł, ó, …) in the file - then they are not counted in “Sel:”.
    Can you duplicate the bug now?

  • @NN
    64 bit version was added.
    You could download it here - https://github.com/young-developer/nppNavigateTo/releases/tag/1.4.2

  • About UDL3 status is there any ETA ?? Will be any UDL3 Beta ?

    Many Thanks for the doc and info !!

  • okay thanks

  • @Alan-Kilborn

    Hi Alan,

    currently I only have a solution for each eol.

    (?-s).*$(?!\r\n) (lines not ending in win eol format \r\n) (?-s).*$(?!\n) (lines not ending in unix eol format \n) (?-s).*$(?=\n|\r\n) (lines not ending in old mac eol format \r)


  • Good time, Claudi!
    1 My inattention-“AAA-opsss”- sorry - not see that- now it’s WORK! THX!!!
    2 I read, as you suggested.
    In practice, this problem found after placing the server editable files in NP ++ (6.x). Prior to that, they also edited NP ++, but no problems. I thought that changed the default settings and just need to set it up. That’s the story)

    Grateful for tips
    and assistance!!!

    With respect

  • Hello @cmeriaux,

    Thank you for this useful addition.

    Best regards.

  • Hungarian translation is updated for Notepad++ 7.3.1.
    Pull request is created in same request as previous here
    (Previous PR was not included in 7.3.1 release unfortunately!)

  • It’s a bit distracting that 7.3 Hungarian (and possibly others too) translation update was still not included in 7.3.1 release! There was a PR created for 7.3 with a lot items updated. Even if some few items from 7.3.1 new feature was not yet done, it should be included ! Thanks! György

  • Thank you very much, I will get done what the boss wants and then com back and figure out how and why it worked. Always good to understand something better. Thanks again!

  • @Grégory-Roche

    I’m not aware of a native builtin function so I would
    use a pdf printer driver and use the print function.


Internal error.

Oops! Looks like something went wrong!