Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Please check the following link for the information of new release:
Thank visimulator, Andreas Jonsson, Giles Payne and Ivan Radic(aka Loreia) for their code contributions.
ps. For those who complain about not working of updater, read (again) in the link above!
Hello Don HO,
Please, can you integrate the function list code for python in the default 'functionList.xml'? You will find it in this thread: http://sourceforge.net/p/notepad-plus/discussion/482781/thread/515001cd/#31ae
Thank you very much!
A fresh install of 6.5.5 does not create the context menu. I experienced this problem on a Windows server 2008 R2 x64 machine. I removed 6.5.5 and installed 6.5.4 and the menu showed up. I then upgraded to 6.5.5 and the menu stayed.
The encoding block of status bar is too small to show complete content and which results in a overlap between characters.
One solution for this would be a simplification of status line.
Leave just one cell that stretches across entire length of window. Then status bar text can be a simple std::string statusLine where fields are separated by say "; ".
If anything changes in status line, just recreate statusLine and display it on the screen. In this way you don't have to bother with the length of each cell.
This is how Scite works. Even better Scite allows users to modify content of statusLine by setting it in preferences.
Hi Don, Loreia2, Andreas and All,
See my post, relative to selection of several files, at the same time, or selection of a directory, for opening in Notepad++, at the address below :
Hello, I would like to know if it is planned to include an horizontal rule. I am not referring a text horizontal rule. I am referring a fixed horizontal rule like UltraEdit or Word for example to know the current column position or to select areas of vertical text.
Thanks in advance,
Could you have a look to the discussion, relative to the Find in Files feature, at the address :
May be, you'll pay attention to one, or several, suggestion(s) !!
Many thanks for your cooperation :)
Automatic encoding detection is not working properly.
Some files (ANSI - Win 1251) he defines as Macintosh or other. And as a result get distortions of the text.
Most likely this is due to when using the Cyrillic.
Fix plz or make a toggle.
If I use the RTL function Arabic text is shown like this.
but it must be like this
Could you please check this issue. I thought it had been fixed in recent releases but 6.5.5 and 6.5.4 show the problem.
To summarize the problem. I do a "Find in files". Having got the results, I minimise (or close) the search results window and do some editing. Then I do another "Find in files" which does not find any matches. At this point there is nothing showing that tells me the search has finished and that there are no results. If I use menu Search => Search Results Window, I see the message 'Search "xyz" (0 hits in 0 files)'.
This bug will be fixed in the next release.
I've some problems with the encoding too. I noticed it, when I edited some BAT files which I wrote in NPP prior version 6.5.5 where everything worked as expected. Version 6.5.5 corrupted some of this files now, so I tested a clean install of both versions.
This is how it looks like in 6.5.5 now: http://i.imgur.com/VpAUHcg.png
It shows korean characters and the main menu does not mark ANSI or any other encoding. The bottom toolbar says "EUC-KR".
When I open that file in NPP 6.5.5 and safe it again as-is, NPP changes the file content, which can corrupt the file in some situations (remember: in my case it previously was a BAT file and the inserted corrupted bytes from NPP are visible in the shell now...). The changes made by NPP can be seen in a hex-editor: http://i.imgur.com/LTwUPAo.png
I made the test with a clean install of NPP 6.5.4 and 6.5.5. Here is the test file I used: http://npp.truckmap.net/test2.zip
Just a hint about encoding process :
When, you choose, for a new document, the preferences : UTF-8 without BOM encoding, with option Apply to opened ANSI files checked, the behaviour of Notepad++, after encoding in ANSI, depends on the contents of the current file :
Start the last 6.5.5 version of Notepad++
Open a new tab ( the proposed encoding is, naturally, the UTF-8 without BOM )
Type in the word "Test", only !
Change to the ANSI encoding with the option Encoding - Encode in ANSI OR the option Convert to ANSI
Save this new file, with the name Test.txt
=> After re-opening the file Test.txt, the encoding is, STILL, the original UTF-8 without BOM encoding !
Select the ANSI encoding, again, with, either, the Encode in ANSI OR the Convert to ANSI option
Open the Character Panel feature ( Edit - Character Panel )
Double-click to ANY character, with code-point > 127 ( \x7F ), to insert it, anywhere in the file Test.txt
Save, for the second time, the file Test.txt
=> After re-opening Notepad++, and Test.txt, this time, the current encoding is, as expected, the ANSI encoding :-)
How to explain this behaviour ? :
Well, if your file contains ONLY, characters, with code-point < 128, as these characters are ALWAYS encoded in ONE byte, WHATEVER the encoding used, Notepad++, applies YOUR preferences and keeps the UTF-8 without BOM* encoding !
But, as soon as your file contains ONE or SEVERAL character(s), with code-point > 127, as these characters are NOT encoded, in the SAME way, for example, in the ANSI and UTF-8 encodings, Notepad++ correctly change for the new ANSI encoding, chosen by the user !!
Encodings and conversions are an interesting, but difficult topic. I began, some months ago, to write something about them, in the N++ wiki, with the help of Christian CUVIER ( cchris ). But, unfortunately, this article is still not complete and I'll have to look about it, very soon :(
thanks for your reply!
I see what you mean. In fact - when the file is not empty, NPP sets the correct encoding as it was defined in the settings. But if the file is empty, it does not do this. And this is not good / wrong, because if you normally write non-ANSI characters (like Cyrillic or chinese or what ever) you would expect that NPP use the encoding which you set in the settings. For example: Keep the default settings for the encoding like in the screenshot and open an empty file. Then try to type in some non-ANSI characters. You'll see only "?" chars. This is not trivial, since this happens only when opening empty files, but I think its a bug.
To your second test with the character panel: I don't see what this has to do with the problem. The test with the character panel works only because that tool inserts characters only up to the value 255, which is still in the extended ASCII character set / covered by ANSI encoding. But I'm talking about non-ANSI characters (characters beyond the extended ASCII) - or, actually, I was talking about an empty file.
Again: If you normally write in a language, which uses characters beyond the extended ASCII character set and you open an empty file, you need set the encoding manually to UTF-8 or UCS again (however, based on the settings, NPP should set it to UTF-8). I still don't see why the encoding for an empty file is set to ANSI if I tell NPP to stay by UTF-8 when opening "ANSI files" (and isn't an empty file also like an "ANSI file"?). This makes no sense.
Now, in France, it's about 8.00am and I must go to work, after breakfast !. Yesterday, I hadn't time, too, to post you anything. I try to get some spare time, this evening, to deeper investigate these encoding problems !
As I commonly don't use UNICODE characters, with code-point > 255, I tried to insert, in an empty file, with the 6.5.5 version of N++, several characters, from various languages ( Hebrew, Arab, Russian, Greek... ) with the help of the Windows tool ( Programs - Accessories - System Tools - Characters Panel )
Programs - Accessories - System Tools - Characters Panel
I'm not sure of the exact path, because, in French, it's Programmes\Accessoires\Outils système\Table des caractères !!
Programmes\Accessoires\Outils système\Table des caractères
As you can see, on the attached picture StanE.png, below, the seven inserted characters, beyond the extended ANSI, are correctly written in the new tab ! I just zoomed text to easily see these characters.
So, I don't understand why you just get some ? characters when you type Unicode characters, in a empty file ?!
My font Courrier New, on my old Win XP computer, is from 05/08/2004 ( dd/mm/yyyy )
After saving this new file, the different Unicode characters, on re-opening N++, were still correctly written
Hi, no problem. I'm at work too and that small problem is not that important. Just something I wanted to mention. ;-) The other problem seems to be a less trivial.
With "empty file" I mean a file, which is already saved somewhere on your drive - not just a new tab.
You will see, that it doesn't work, because the encoding is magically set back to ANSI again (although I told NPP to use UTF-8 when opening ANSI files), so that NPP just prints "?". So if an - let's say russian - wants to open an empty file (not just a new tab) and starts typing his cyrillic chars, it will not work. He would need to change the encoding back to UTF-8 manually everytime he opens an empty file.
However, if the file contains even a single one-byte char, like an "x", NPP opens it in UTF-8 mode again* and everything is fine.
*Now in 6.5.5 there seems to be an exception for that too (see my other problem).
I just updated from Notepad 6.5.4 to 6.5.5 the update process works well but when i start it is impossible to start the FTP windo.
error message is : "Unknown Exception"
I completely uninstalled notepad++ and tried to reinstall but the same error appears... annoing. i was so happy with my 6.5.4. version...
does anybody has an idea?
all the best
Well, I think we must begin to speak of important facts about encodings, that are quite independent from the text editor used !
And, as from your posts, I suppose, you're Russian, I'll use an example with Cyrillic characters. ( Hope I'm not wrong ! )
So, let's choose the two characters Д and й
If you work with an ANSI encoding, you're likely use the Windows-1251 encoding. See the complete list at :
From this table, if you save a file with these two characters, you'll obtain a two bytes file :
On opening this file, as an editor don't detect any indication, regarding the encoding, it'll use the default ANSI encoding !
For the other encodings, different from ANSI, you'll use the UNICODE code-points of these two characters. See the complete list of UNICODE Cyrillic characters at :
So, from that list, the hexadecimal code-points are 0414 for the Д character and 0439 for the й character
If you work with the UCS-2 Big Endian encoding, the contents of the file are :
FE FF 04 14 04 39
04 14 04 39
Note that every character is written in two bytes ant that the two INVISIBLE bytes FE FF represents the BOM ( Byte Order Mark ), which indicates, to any editor, that the contents of this file are written with the UCS-2 Big Endian encoding.
If you work with the UCS-2 Little Endian encoding, the contents of the file are :
FF FE 14 04 39 04
14 04 39 04
This time, every character is written in two bytes, with the least significant byte first, and the two INVISIBLE bytes FF FE represents the BOM, which indicates, to any editor, that the contents of this file are written with the UCS-2 Little Endian encoding.
If you work with the UTF-8 encoding, the contents of the file are :
EF BB BF DO 94 D0 B9
EF BB BF
DO 94 D0 B9
Note that, with the UTF-8 encoding, a character may be written with one, two, three or four bytes, depending of the absolute value of its code-point and that the three INVISIBLE bytes EF BB BF represents the UTF-8 form of the two bytes FEFF of the BOM, which indicates, to any editor, that the contents of this file are written with the UTF-8 encoding.
For further informations about the UTF-8 encoding and the Byte Order Mark feature, see :
Now, let suppose you create a new file, with the Windows Explorer Context menu ( New \ Text Document )
New \ Text Document
It's just an empty text file. So, what is its true encoding ? Well, by default, Windows assume it's an ANSI file and the characters typed, with an editor, will be saved, in this file, with the Windows-12.. encoding, according to your linguistic zone ( the Windows Cyrillic code page Windows-1251 , in your case ! )
So, if you open this empty file with Windows Notepad ( NOT with Notepad++ ! ), type in your two Cyrillic characters Дй and save this file with the Save As... option, you'll see that it's saved, with the ANSI encoding, by default and the contents of the file are, as described, above, at point A.
Therefore, it's obvious that, if you open, afterwards, this file with Notepad++ :
Notepad++ correctly indicate the ANSI encoding, in the status bar
You can't type most of UNICODE characters because they haven't any representation in the Windows-1251 encoding !
BUT, with the Save As... option of Windows Notepad, it's also possible to save a file with an other encoding than ANSI :
For example, if the Cyrillic characters Дй, are saved,
And, this time, after opening this file, with Notepad++ :
Notepad++ correctly indicate the UCS-2 Little Endian encoding, in the status bar
You can type any UNICODE character, with code-point between \x00 and \xFFFF
Finally, if you save your file, with Notepad, using the UTF-8 encoding, then after re-opening this file with N++ :
Notepad++ correctly indicate the UTF-8 encoding, in the status bar
You can type any UNICODE character, with code-point between \x00 and \x1FFFFF !
With my French configuration, if I try to :
Create a new text file with the Windows Explorer Context menu
Open this file with the Windows Notepad editor
Type your two Cyrillic characters Дй
Save this file with the usual CTRL + S shortcut
==> the message, below, appears, with the two buttons OK and Cancel :
"This file contents characters, in the Unicode format, which will be lost, if you save this file as an ANSI text. To save the Unicode informations, click on the Cancel button and select one of the Unicode options of the popup list Encoding. Do you want to continue ?"
This is quite normal, because my ANSI encoding is based on the Windows-1252 code page which doesn't code Cyrillic characters ! So, naturally, Notepad ask me to save these Cyrillic characters in an UNICODE format :-)
This topic isn't closed ! I just answer you, about your three points list. So, feel free to ask me again !
Nope, I'm German ;-)
Ok guy038, I think we are talking past each other. I don't see, what all of this has to do with the changed behaviour of Notepad++ in version 6.5.5. I know about encodings (I'm working as software developers for 12 years now (afaik)) ;-). My initial question was not about encodings directly, but why Notepad++'s behaviour has changed in v6.5.5. The same test with same file on same system and same configuration runs differently in version 6.5.4 and 6.5.5. Did you tested it in both versions too?
So, if you open this empty file with Windows Notepad ( NOT with Notepad++ ! ), type in your two Cyrillic characters [...] Therefore, it's obvious that, if you open, afterwards, this file with Notepad++ [...]
So, if you open this empty file with Windows Notepad ( NOT with Notepad++ ! ), type in your two Cyrillic characters [...] Therefore, it's obvious that, if you open, afterwards, this file with Notepad++ [...]
Sorry, but that's exactly what I was not talking about. I explained the exact steps (for my second question) in: https://sourceforge.net/p/notepad-plus/discussion/331753/thread/62fb720b/#4df0
Thank you very much for your detailed explainations (really ;-). But I guess I need to work through the commits of the repository to find out what was changed.
Hmm, ok, after a quick look it seems that in revision #1189 a new charset detection library (Uchardet) was implemented which became part of version 6.5.5, see here: http://svn.tuxfamily.org/viewvc.cgi/notepadplus_repository/trunk/PowerEditor/src/uchardet/README.TXT?view=markup&pathrev=1189. As I expected, it now makes an additional check of the codepage (see here: http://svn.tuxfamily.org/viewvc.cgi/notepadplus_repository/trunk/PowerEditor/src/ScitillaComponent/Buffer.cpp?r1=1189&r2=1188&pathrev=1189#content (line 856)) and I guess that something goes wrong there but I'm not sure.
Currently I have not much free time to have a deeper look into the new commited files, but I think it would be good, if Notepad++ considers to use the local codepage when detecting the charset. In my case it would be Windows-1252 (Western European) since I live in Berlin, Germany. I removed that changes made by Giles Payne in revision #1189 and compiled the current Notepad++ version again. It now opens my test file (http://npp.truckmap.net/test2.zip) as previously in 6.5.4 again.
@Don: I'm not really familiar with the N++ sources. What do you think?
The detection of encoding is far from accurate.
In the next release auto-detection of encoding will be optional, and disabled by default.
Please let me know if you got a better solution, and you are very welcome if you provide any fixe for this issue.
I really hope that you did not mean UTF-8 and UCS-2 while saying "auto-detection of encoding will be optional, and disabled by default" :) I mean, UTF-8 with BOM and UCS-2 with BOM can be correctly detected by the presence of the corresponding BOM bytes; and UTF-8 without BOM can be detected by the byte sequence, so such auto-detection must be present.
As for ANSI encodings auto-detection - this is the real problem. Probably such encoding auto-detection should be based on current system's (user's) ANSI codepage - e.g. for cp1251 one should use auto-detection Cyrillic tables, for cp1250 - Central/Eastern European languages tables, for cp1252 - Western languages tables; and such auto-detection should be optional indeed.
First of all, I'm sorry not to answer you before, but I was away from home, during one week, for a technical formation, about configuration of CISCO and HP network switches, in Nancy !
OK, I see that your technical competences are greater than mines. Therefore, in my last post, all the part, relative to encodings and BOM should, have been of less interest, to you. Anyway, I hope it had been useful to someone, as encodings are not obvious, at first sight !
So, I tried to carefully re-read your previous past ( 28/03/2014 ) and, as you said, in last post ( 31/03/14 ) I just did some tests with both the 6.5.4 and the 6.5.5 versions of N++.
And, sorry, but I still don't understand ! As for me, I obtained the same results, indicated in my previous posts, with the two versions :-(
Indeed, and I just verified on my Windows XP configuration and on the Windows 7 computer of my son, when you right click, on Windows Explorer, to create a Notepad text file, by default, a new ANSI ZERO length text file is created !
So, if, afterwards, you open this file, in N++, either with the 6.5.4 or the 6.5.5 version, it's displayed with its present ANSI encoding, previously set by Windows, which doesn't depend on the current settings of N++, relative to a new document. Then, most of UNICODE characters can't be typed in that document.
BUT, assuming you chose, for a new document, the settings : UTF-8 without BOM encoding, with the option Apply to opened ANSI files checked, if you type, for example, the simple string "ABCDE" and save this file, the NEXT time you open this ANSI file, in Notepad++, its encoding is, as expected, Encoded as UTF-8 without BOM, with the "ANSI as UTF-8" indication, in the status bar.
In the same way, if you create a new file ( with File\New / CTRL + N ) FROM INSIDE Notepad++, your N++ preferences are used and a new empty text file is created, with the UTF-8 without BOM encoding automatically set to this new file !
Anyway, don't bother to answer me again, about that topic ! I hope that the new option concerning enabling/disabling the encoding auto-detection, promised by Don, will definitively solve your problems :-)
Oh, BTW, although I don't understand German language at all, I often listen an excellent German radio rock station, at the two addresses :
I found out these links, when I download, some months ago, the jN plugin for N++, created by your fellow-country man Engen Kremmer ! See the link below :
Many Thanks to him. Sometimes, a good old piece of rock, while using N++, is quite giant :-)
In version 6.5.5, the incremental search results pane does not use the theme provided by the operating system, instead substituting its own colours, as depicted in the attached screenshot at the page where the bug was reported: https://sourceforge.net/p/notepad-plus/bugs/4795/. This becomes apparent when using an operating system theme with specifications different from what the incremental search pane uses; for instance, a high contrast inverse theme.
This bug is absent from version 5.9.3; I haven't tested the intervening versions and so cannot indicate which version was responsible for the introduction of this bug.