If there's no critical bug found, v5.4.2 should be the last version of v5.4.x.
Hiere are v5.4.2 fixed bugs (from v5.4.1) :
1. Fix the localization switcher bug while w/o doLocalConf.xml (Menu items translation problem).
2. Fix only one document "Move to other view" close Notepad++ instance issue.
3. Fix plugin menu boolean check box bug.
How to reproduce:
1. Open file from remote machine: \\computer_name\home\alex\tasks.txt (i think maybe file on local machine acceptable)
2. Modify it (replace all text for example).
3. Press Ctrl+S, Ctrl+W
Result: Notepad++ not responding.
It difficult to reproduce this bug.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This sounds like a network problem rather than a NP++ specific issue. This is even more likely when you say "It difficult to reproduce this bug." What is likely happening is that the network connection is being lost when the attempted save occurs. Then if you tab out of NP++ and go back while it is saving, it will then try to check if the file is changed (another network request).
In the end, I bet this problem would occur with more than just NP++. Try doing the same in Word and see if it doesn't choke too.
2C
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the update Don. A few minor bugs that still seem to exist:
1). When loading a file with a '&' character in the filename, it does not show up correctly in the document tab. For example a filename of "S&I Test" shows up as "SI Test" with the letter 'I' underlined.
2). Using the non-installer version of N++ unicode, I cannot get the "File Status Auto Detection" (in the MISC preferences tab) to remember it's settings. If I disable this feature and restart N++, it's enabled again. I tested the unicode version with installer version and it seems to work fine. Not sure if it's a plug-in issue, I'll have to compare and report back.
Best Regards,
FGump
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the release, I know it was a late night for you! Two issues though, one major, one minor.
I'm getting the bug where a new instance is opened and the tab moves to that instance whenever I click on a tab. Windows XP sp3. I'll try and have a look to see if I can nail it down to the last view changes.
Second issue is that it looks like the readonly patch wasn't quite applied properly, and the original location of the notification is still there, so the readonly changed notification happens twice, except the second time it doesn't include the DOCSTATUS_BUFFERDIRTY flag if it's dirty. I can't seem to make this cause an issue, but it should be removed really.
Thanks again,
Dave.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On the tab launching a new instance issue - it's just stopped. Nothing changed, it just started working fine. The only thing I did was build one from source, test that, that worked fine, then went back to the installed version. I'll try it at work shortly.
The readonly thing does cause a minor issue - if a dirty buffer goes readonly, then back to read/write, a plugin incorrectly gets it as a clean buffer (presumably for a split second it knows it's dirty, but then it gets another message that it's clean). This worked in the test version you sent me - maybe that extra bit of old code came back?
Thanks,
Dave.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Another issue that was not seen until testing the most recent installer version is that the fix of the check box bug showed that there was an incorrect setting in the ChangeMarker plugin menu registration code.
Version 1.2.1 ANSI and Unicode have been emailed to you.
almostautomated
BTW - Thanks to whoever contributed the vim dark blue theme, and thanks to you for including it in the installer!
PS - Any real ugly themes submitted yet? I was looking forward to being sickened by some nasty style and it didn't happen. :P
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
is possible to apply the same colors from styles to the background of the plugins, if use black background to the editor it would be nice that rest ot screen (plugin actives) will be on the same color.
thanxs
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That is completely dependent on the plugin and the settings it makes available to the user and how it tracks the styles. If it is an external lexer then it also uses its own styler.xml file.
So, in short, no. There nothing to be done within N++ to make plugins match themes. We could how-ever add a notification that sends a current theme name to plugins, and then they could do with it what they wanted. Perhaps, some inventive plugin writers would write a routine that reads a particular style node directly out of the theme's styler xml and applies the colors found for a particular language to their own plugin's styling.
Perhaps, add an idea to the ideaTorrent ( see the 'hosted apps' drop-down menu near the top of this page )?
almostautomated
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Issue still present in 5.4.2 (Unicode): The option "Don't use %APPDATA%" does not work properly.
Platform: Vista 32.
Symptoms:
NP++ does not remember:
- tabs (opened files);
- settings changes;
- does not make recently opened file entries;
--> unless it is run as administrator (which is undesirable).
This option used to work fine for me until 5.3.x or at least 5.2.x.
The problem is solved by re-installing without using this option.
Maybe it is not necessary to re-install, but enough to remove the file
do.local.Config.xml from the program files/notepad++ folder?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tested v5.4.2 under both xp and vista - checking the option "Don't use %APPDATA%" during installation works fine to me.
You probably means the settings and session files in the previous installation are not kept in the new installation if the option "Don't use %APPDATA%" is checked. If that's what you mean, then it's a normal behaviour : the settings files for Notepad++ localize on the different directories in the 2 mode.
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"You probably means the settings and session files in the previous installation are not kept in the new installation if the option "Don't use %APPDATA%" is checked."
No, I mean that while using 5.4.2 normally, it __does not remember__ open tabs and other settings.
When I close 5.4.2 after using it and then start it again later, all tabs are gone and changed settings also.
Tabs/settings are only remembered in administrator mode.
I'm not talking about session/settings from the previous installation.
I hope this is clear now. I will try on an XP installation to see if the behaviour is the same.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"When I close 5.4.2 after using it and then start it again later, all tabs are gone and changed settings also.
Tabs/settings are only remembered in administrator mode."
I think that happens because Vista writes to some folder called "roaming" or something like that for non-admins. I remember dimly that this has already made itself felt as a problem a while ago, but I can't find anything in this chaotic forum.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also, the searching results (in the Find Results pane) inside UCS-2 and UTF-8 files seem to be shown incorrectly even for pure english text. Try to "Find all in current document" inside some UCS-2 file with any text, and you'll see that the find tokens are highlighted incorrectly (the highlighted string positions are incorrect) in the Find Results pane!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Don, did you read my post regarding case-insensitive searching of non-Latin characters?
Yes, I saw that. I have not solution yet.
All we should do is to report this issue to Neil, so he might get it right.
> Also, the searching results (in the Find Results pane) inside UCS-2 and UTF-8 files seem to be
> shown incorrectly even for pure english text. Try to "Find all in current document" inside some
> UCS-2 file with any text, and you'll see that the find tokens are highlighted incorrectly (the
> highlighted string positions are incorrect) in the Find Results pane!
Tested with UTF8 Traditional Chinese text, UTF8 French and ANSI Ftrench text by using "Find in files" and "fin in all opened files" features. It works perfectly for me.
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem with Find Results pane happens with SciLexer.dll from official Notepad++ 5.3.1 - as I can't use SciLexer.dll from Notepad++ 5.4.1 for case-insensitive searching.
Indeed, SciLexer.dll from Notepad++ 5.4.1 is OK with Unicode text files without cyrillic characters.
Seems the problem with SciLexer.dll from 5.3.1 is caused by the following reason: this patched version of Scintilla performs conversion to UCS-2 string inside Document::FindText() in order to allow case-insensitive searching (::CharUpperW can be called for UCS-2 string). Thus, the position of substring (converted to UCS-2) found in such UCS-2 string, does not match the corresponding position of the same UTF-8 substring found in UTF-8 string. So the value of 'pos' returned by Document::FindText() is incorrect. Anyway, the reason is somewhere here.
Maybe I'll try to implement additional patch of SciLexer.dll from 5.4.1 to allow case-insensitive searching basing on conversion to UCS-2 if you have no other suggestions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
...OK, seems I have success with the patching. I'll provide you the patched SciLexer.dll from 5.4.1 later - BUT IN ANY CASE IT MUST BE TESTED BY SOMEONE ELSE EXCEPT ME to be sure it really works correctly regarding searching for any characters (Latin & non-Latin) in any files (Unicode & non-Unicode). It would be good if it will be tested by someone from Russia and from China, for example.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please submit your patch in Patch tracker.
I'll check it with Neil to see if it's possible to include your patch in future Scintilla release.
(Or you can notice him with your patch if you want).
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The patch has been submitted to the Tracker.
I'm not sure it may be included in official Scintilla's source code because it uses platform-dependent function Platform_MakeUpperW with current implementation for Win32. Anyway, I tried to implement my changes as separate blocks of code, so it must not be complicated to apply this patch to futher versions of Scintilla.
Also - ATTENTION! - I think I've found a bug in implementation of Find Result pane. To reproduce:
1) select several lines of text in current document
2) open the Find dialog - its 'Find what' field now contains the selected text lines
3) press 'Find all in all opened documents' or 'Find all in current document'
4) double-click the line found in the Find Result pane - Notepad++ crashes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If there's no critical bug found, v5.4.2 should be the last version of v5.4.x.
Hiere are v5.4.2 fixed bugs (from v5.4.1) :
1. Fix the localization switcher bug while w/o doLocalConf.xml (Menu items translation problem).
2. Fix only one document "Move to other view" close Notepad++ instance issue.
3. Fix plugin menu boolean check box bug.
Please check :
https://sourceforge.net/forum/forum.php?thread_id=3283129&forum_id=331753
and
https://sourceforge.net/forum/forum.php?thread_id=3285327&forum_id=331753
For all informations of v5.4.x releases.
Don
Notepad++ Takes 100% CPU
How to reproduce:
1. Open file from remote machine: \\computer_name\home\alex\tasks.txt (i think maybe file on local machine acceptable)
2. Modify it (replace all text for example).
3. Press Ctrl+S, Ctrl+W
Result: Notepad++ not responding.
It difficult to reproduce this bug.
This sounds like a network problem rather than a NP++ specific issue. This is even more likely when you say "It difficult to reproduce this bug." What is likely happening is that the network connection is being lost when the attempted save occurs. Then if you tab out of NP++ and go back while it is saving, it will then try to check if the file is changed (another network request).
In the end, I bet this problem would occur with more than just NP++. Try doing the same in Word and see if it doesn't choke too.
2C
Thanks for the update Don. A few minor bugs that still seem to exist:
1). When loading a file with a '&' character in the filename, it does not show up correctly in the document tab. For example a filename of "S&I Test" shows up as "SI Test" with the letter 'I' underlined.
2). Using the non-installer version of N++ unicode, I cannot get the "File Status Auto Detection" (in the MISC preferences tab) to remember it's settings. If I disable this feature and restart N++, it's enabled again. I tested the unicode version with installer version and it seems to work fine. Not sure if it's a plug-in issue, I'll have to compare and report back.
Best Regards,
FGump
It's DocMonitor plugin issue.
Remove this plugin will restore the correct behaviour.
I'll see what can I do about that for the future releases.
Don
Thanks for the release, I know it was a late night for you! Two issues though, one major, one minor.
I'm getting the bug where a new instance is opened and the tab moves to that instance whenever I click on a tab. Windows XP sp3. I'll try and have a look to see if I can nail it down to the last view changes.
Second issue is that it looks like the readonly patch wasn't quite applied properly, and the original location of the notification is still there, so the readonly changed notification happens twice, except the second time it doesn't include the DOCSTATUS_BUFFERDIRTY flag if it's dirty. I can't seem to make this cause an issue, but it should be removed really.
Thanks again,
Dave.
On the tab launching a new instance issue - it's just stopped. Nothing changed, it just started working fine. The only thing I did was build one from source, test that, that worked fine, then went back to the installed version. I'll try it at work shortly.
The readonly thing does cause a minor issue - if a dirty buffer goes readonly, then back to read/write, a plugin incorrectly gets it as a clean buffer (presumably for a split second it knows it's dirty, but then it gets another message that it's clean). This worked in the test version you sent me - maybe that extra bit of old code came back?
Thanks,
Dave.
Just to mention, the tabs work fine on work pc. Same OS, and followed the same steps for upgrade (using the installer version).
Dave.
Fixed... will be in 5.4.3. And the fix works on Win7 to. :)
While testing this fix though I did notice that on Win7 multiple instances don't work with the ANSI build, and not just in the latest version...
Another issue that was not seen until testing the most recent installer version is that the fix of the check box bug showed that there was an incorrect setting in the ChangeMarker plugin menu registration code.
Version 1.2.1 ANSI and Unicode have been emailed to you.
almostautomated
BTW - Thanks to whoever contributed the vim dark blue theme, and thanks to you for including it in the installer!
PS - Any real ugly themes submitted yet? I was looking forward to being sickened by some nasty style and it didn't happen. :P
very nice vim dark blue, very usefull !!!
is possible to apply the same colors from styles to the background of the plugins, if use black background to the editor it would be nice that rest ot screen (plugin actives) will be on the same color.
thanxs
That is completely dependent on the plugin and the settings it makes available to the user and how it tracks the styles. If it is an external lexer then it also uses its own styler.xml file.
So, in short, no. There nothing to be done within N++ to make plugins match themes. We could how-ever add a notification that sends a current theme name to plugins, and then they could do with it what they wanted. Perhaps, some inventive plugin writers would write a routine that reads a particular style node directly out of the theme's styler xml and applies the colors found for a particular language to their own plugin's styling.
Perhaps, add an idea to the ideaTorrent ( see the 'hosted apps' drop-down menu near the top of this page )?
almostautomated
Thanks for the new release.
Issue still present in 5.4.2 (Unicode): The option "Don't use %APPDATA%" does not work properly.
Platform: Vista 32.
Symptoms:
NP++ does not remember:
- tabs (opened files);
- settings changes;
- does not make recently opened file entries;
--> unless it is run as administrator (which is undesirable).
This option used to work fine for me until 5.3.x or at least 5.2.x.
The problem is solved by re-installing without using this option.
Maybe it is not necessary to re-install, but enough to remove the file
do.local.Config.xml from the program files/notepad++ folder?
Tested v5.4.2 under both xp and vista - checking the option "Don't use %APPDATA%" during installation works fine to me.
You probably means the settings and session files in the previous installation are not kept in the new installation if the option "Don't use %APPDATA%" is checked. If that's what you mean, then it's a normal behaviour : the settings files for Notepad++ localize on the different directories in the 2 mode.
Don
"You probably means the settings and session files in the previous installation are not kept in the new installation if the option "Don't use %APPDATA%" is checked."
No, I mean that while using 5.4.2 normally, it __does not remember__ open tabs and other settings.
When I close 5.4.2 after using it and then start it again later, all tabs are gone and changed settings also.
Tabs/settings are only remembered in administrator mode.
I'm not talking about session/settings from the previous installation.
I hope this is clear now. I will try on an XP installation to see if the behaviour is the same.
"When I close 5.4.2 after using it and then start it again later, all tabs are gone and changed settings also.
Tabs/settings are only remembered in administrator mode."
I think that happens because Vista writes to some folder called "roaming" or something like that for non-admins. I remember dimly that this has already made itself felt as a problem a while ago, but I can't find anything in this chaotic forum.
janschreiber: It's right here: http://sourceforge.net/forum/message.php?msg_id=6636117
Don, did you read my post regarding case-insensitive searching of non-Latin characters?
https://sourceforge.net/forum/message.php?msg_id=7419009
Also, the searching results (in the Find Results pane) inside UCS-2 and UTF-8 files seem to be shown incorrectly even for pure english text. Try to "Find all in current document" inside some UCS-2 file with any text, and you'll see that the find tokens are highlighted incorrectly (the highlighted string positions are incorrect) in the Find Results pane!
> Don, did you read my post regarding case-insensitive searching of non-Latin characters?
Yes, I saw that. I have not solution yet.
All we should do is to report this issue to Neil, so he might get it right.
> Also, the searching results (in the Find Results pane) inside UCS-2 and UTF-8 files seem to be
> shown incorrectly even for pure english text. Try to "Find all in current document" inside some
> UCS-2 file with any text, and you'll see that the find tokens are highlighted incorrectly (the
> highlighted string positions are incorrect) in the Find Results pane!
Tested with UTF8 Traditional Chinese text, UTF8 French and ANSI Ftrench text by using "Find in files" and "fin in all opened files" features. It works perfectly for me.
Don
Are you using the latest (official) SciLexer.dll, or did you just manually replace notepad++.exe?
The problem with Find Results pane happens with SciLexer.dll from official Notepad++ 5.3.1 - as I can't use SciLexer.dll from Notepad++ 5.4.1 for case-insensitive searching.
Indeed, SciLexer.dll from Notepad++ 5.4.1 is OK with Unicode text files without cyrillic characters.
Seems the problem with SciLexer.dll from 5.3.1 is caused by the following reason: this patched version of Scintilla performs conversion to UCS-2 string inside Document::FindText() in order to allow case-insensitive searching (::CharUpperW can be called for UCS-2 string). Thus, the position of substring (converted to UCS-2) found in such UCS-2 string, does not match the corresponding position of the same UTF-8 substring found in UTF-8 string. So the value of 'pos' returned by Document::FindText() is incorrect. Anyway, the reason is somewhere here.
Maybe I'll try to implement additional patch of SciLexer.dll from 5.4.1 to allow case-insensitive searching basing on conversion to UCS-2 if you have no other suggestions.
...OK, seems I have success with the patching. I'll provide you the patched SciLexer.dll from 5.4.1 later - BUT IN ANY CASE IT MUST BE TESTED BY SOMEONE ELSE EXCEPT ME to be sure it really works correctly regarding searching for any characters (Latin & non-Latin) in any files (Unicode & non-Unicode). It would be good if it will be tested by someone from Russia and from China, for example.
Vitaliy,
Please submit your patch in Patch tracker.
I'll check it with Neil to see if it's possible to include your patch in future Scintilla release.
(Or you can notice him with your patch if you want).
Don
The patch has been submitted to the Tracker.
I'm not sure it may be included in official Scintilla's source code because it uses platform-dependent function Platform_MakeUpperW with current implementation for Win32. Anyway, I tried to implement my changes as separate blocks of code, so it must not be complicated to apply this patch to futher versions of Scintilla.
Also - ATTENTION! - I think I've found a bug in implementation of Find Result pane. To reproduce:
1) select several lines of text in current document
2) open the Find dialog - its 'Find what' field now contains the selected text lines
3) press 'Find all in all opened documents' or 'Find all in current document'
4) double-click the line found in the Find Result pane - Notepad++ crashes.