In this version brace matched broken issue is fixed. A lot of encodings are added as well.
I take the chance to thank Thell Fowler and Vitaliy Dovgan.
The "Mark Jumper" feature idea come from Thell. Without him this feature won't be in v5.6.x. Vitaliy has fixed the searching case insensitive for non ascii characters.
Thanks to Chris, the NppHelp is updated.
Here are Notepad++ v5.6.1 new features and fixed bugs (from v5.6) :
1. Fix brace highlighting breaking issue and related performance problem.
2. Add new encodings in the shortcuts map.
3. Remove annoying encoding issue warning dialogs.
4. Enhance Html encoding auto-detection.
5. Fix case-insensitive searching bug for non-ascii characters (for example some characters in French and Cyrillic letters).
6. Add find result commands in the menu.
7. Add DOS CodePage : CP437, CP737, CP850, CP852, CP855, CP857, CP858, CP860, CP861, CP863, CP865, CP866 and CP869.
8. Fix localization combo box unselected in preference dialog bug after startup (when a localization file is in use).
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Small bug concerning localization: If a localization file is loaded via GUI (Preferences dialog), the menu items "Go to …" and "Jump to matching brace" in the Find menu are replaced with "Mark All" and "Unmark All".
Perhaps related to #4 above: After restarting, the captions on the tabs of the Find/Replace/Find in files dialog appear in English, although immediately after changing localization via GUI the translated strings appear as expected.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Kudos on the new Encoding menu, looks very professional. 5.61 Unicode here.
There are two weird bugs at this moment:
1. converting anything from NPP default ANSI (have windows-1250 environment here) or other encodings to CE ISO-8859-16 results in an empty line. Especially works with a single line file every time. Tried under various conditions at least 20 times, I only succeeded twice, not even sure now if it did right - perhaps. The empty line file can't be saved right after 'conversion' (if I don't change it somehow) but when opening the converted file, it is not encoded in ISO-8859-16, it is plain ANSI, nothing changed.
2. When I create a new file (in NPP), put there some default ascii content (ascii only characters) and save as UTF-8, the file is saved as ANSI. It also open as ANSI. There is no way to convert this file to UTF-8. I have to put special characters (ščíľášýľčíášýčéľšťžč) there, convert to UTF-8 and then save, then it works. But with ascii characters only it doesn't work. Weird.
Perhaps then you could also change the Encoding menu further so it makes more sense:
"Encode in…" would be "View as.." so for example Encode in UTF-8 would become View as UTF-8. This way it's clear that the file is not coverted in any way.
Then the Character Sets submenu would become "Convert encoding" submenu with the same content.
Then also the "Convert to.." menu items would have to have their own submenu, perhaps "Convert to.. " or "Convert format to..". Or for the sake of simplicity just add them to "Convert encoding" menu above. This makes sense especially for non-technical users.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Bug in repainting the shortcut mapper:
Open shortcut mapper, scroll down somewhat, Alt-tab to another opened application, alt-tab back: the position you were viewing is lost.
Must have been there from day one.
CChris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The workaround is to select some visible row before switching, as this will keep thecurrent view when switching back. The hardest part is to remember to do so.
CChris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
small bug still exists, not a showstopper, but i'm still getting weirdness in matching tag highlighting in html language. when cusros is inside a tag that is matched, the first angle bracket of the opening tag is styled/matched against the last angle bracket of the closing tag.
**<**p>test</p**>**
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I confirm that "Encoding feature" does only re-interpreting of the current document with the expected code page, but not conversion. I believe "Encode in…" is the exact term to be used, even "View as…" might be less confusion.
In the future version, users will be able to convert from a code page to Unicode and vice versa. That is not case in the current version.
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
don, i'm not sure you understand what i'm saying. i disabled the indent guides and it still occurs. i dont know what indent guides have to do with this behavior. here's a screenie (with guides disabled):
> i disabled the indent guides and it still occurs. i dont know what indent guides have to do with this behavior. here's a screenie (with guides disabled):
Indeed, disabling indent guide lines make it still happen.
This bug will be fixed in the next release.
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
don, can you please explain the reasoning behind having this happen intentionally and what it has to do with indent guide functionality?
when would matching parts of separate tags be useful or desired?
the SynWeb editing component actually has the most useful behavior for tag and brace matching - it match-highlights only the opening/closing tag names, and when the cursor is adjacent to a tag angle bracket, it matches the corresponding closing angle bracket on that tag (> or />)
To make xml/html indent guide lines highlighting work with tag, 2 positions ("<" and ">") have to be highlighted. It's scintilla component which imposes it.
If you know the way to not highlight them, please let me know.
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
just wondering, since this was not required in previous versions with all the same settings enabled. not sure what changed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2009-12-06
I've seen this bug since version 5.4 or so and it is still present in 5.6.1.
Open any file. Click next to line no. A blue dot marker appears. Press Ctrl+f to search for a string. A window pops up. Hit 'clear' to clear all your previous 'styled' search and this would clear all markers as well.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In this version brace matched broken issue is fixed. A lot of encodings are added as well.
I take the chance to thank Thell Fowler and Vitaliy Dovgan.
The "Mark Jumper" feature idea come from Thell. Without him this feature won't be in v5.6.x. Vitaliy has fixed the searching case insensitive for non ascii characters.
Thanks to Chris, the NppHelp is updated.
Here are Notepad++ v5.6.1 new features and fixed bugs (from v5.6) :
1. Fix brace highlighting breaking issue and related performance problem.
2. Add new encodings in the shortcuts map.
3. Remove annoying encoding issue warning dialogs.
4. Enhance Html encoding auto-detection.
5. Fix case-insensitive searching bug for non-ascii characters (for example some characters in French and Cyrillic letters).
6. Add find result commands in the menu.
7. Add DOS CodePage : CP437, CP737, CP850, CP852, CP855, CP857, CP858, CP860, CP861, CP863, CP865, CP866 and CP869.
8. Fix localization combo box unselected in preference dialog bug after startup (when a localization file is in use).
Don
good news
thanks for fastly update
i'm sorry for my previous reaction and thanks for the fix, good work
Small bug concerning localization: If a localization file is loaded via GUI (Preferences dialog), the menu items "Go to …" and "Jump to matching brace" in the Find menu are replaced with "Mark All" and "Unmark All".
Screenshot: http://img682.imageshack.us/img682/655/nbug.png
Restarting N++ and reading the localization from nativeLang.xml fixes this.
Applies to: 5.6.1 Unicode, portable version.
The localization bug is confirmed here too… A simple restart of N++ makes thing works ok! :)
Perhaps related to #4 above: After restarting, the captions on the tabs of the Find/Replace/Find in files dialog appear in English, although immediately after changing localization via GUI the translated strings appear as expected.
Kudos on the new Encoding menu, looks very professional. 5.61 Unicode here.
There are two weird bugs at this moment:
1. converting anything from NPP default ANSI (have windows-1250 environment here) or other encodings to CE ISO-8859-16 results in an empty line. Especially works with a single line file every time. Tried under various conditions at least 20 times, I only succeeded twice, not even sure now if it did right - perhaps. The empty line file can't be saved right after 'conversion' (if I don't change it somehow) but when opening the converted file, it is not encoded in ISO-8859-16, it is plain ANSI, nothing changed.
2. When I create a new file (in NPP), put there some default ascii content (ascii only characters) and save as UTF-8, the file is saved as ANSI. It also open as ANSI. There is no way to convert this file to UTF-8. I have to put special characters (ščíľášýľčíášýčéľšťžč) there, convert to UTF-8 and then save, then it works. But with ascii characters only it doesn't work. Weird.
Perhaps then you could also change the Encoding menu further so it makes more sense:
"Encode in…" would be "View as.." so for example Encode in UTF-8 would become View as UTF-8. This way it's clear that the file is not coverted in any way.
Then the Character Sets submenu would become "Convert encoding" submenu with the same content.
Then also the "Convert to.." menu items would have to have their own submenu, perhaps "Convert to.. " or "Convert format to..". Or for the sake of simplicity just add them to "Convert encoding" menu above. This makes sense especially for non-technical users.
Oh, I forgot to write above, that whenever I refer to UTF-8, I mean UTF-8 without BOM. This is very important to distinguish.
AFAIK, there is no way to distinguish an UTF-8 file without BOM from an ANSI file unless there are some non-ASCII characters in it.
Bug in repainting the shortcut mapper:
Open shortcut mapper, scroll down somewhat, Alt-tab to another opened application, alt-tab back: the position you were viewing is lost.
Must have been there from day one.
CChris
The workaround is to select some visible row before switching, as this will keep thecurrent view when switching back. The hardest part is to remember to do so.
CChris
nice, bracket matching fixed.
small bug still exists, not a showstopper, but i'm still getting weirdness in matching tag highlighting in html language. when cusros is inside a tag that is matched, the first angle bracket of the opening tag is styled/matched against the last angle bracket of the closing tag.
**<**p>test</p**>**
above issue seems to only occur when opening and closing tags are on separate lines.
> the first angle bracket of the opening tag is styled/matched against the last angle bracket of the closing tag.
I confirm that It's the expected behaviour.
To do w/o it, the indent guide line should be disabled.
Don
beholder4096,
I confirm that "Encoding feature" does only re-interpreting of the current document with the expected code page, but not conversion. I believe "Encode in…" is the exact term to be used, even "View as…" might be less confusion.
In the future version, users will be able to convert from a code page to Unicode and vice versa. That is not case in the current version.
Don
don, i'm not sure you understand what i'm saying. i disabled the indent guides and it still occurs. i dont know what indent guides have to do with this behavior. here's a screenie (with guides disabled):
http://i.imgur.com/LVmj0.png
Leon
the version update so fast as the new features added.
> i disabled the indent guides and it still occurs. i dont know what indent guides have to do with this behavior. here's a screenie (with guides disabled):
Indeed, disabling indent guide lines make it still happen.
This bug will be fixed in the next release.
Don
don, can you please explain the reasoning behind having this happen intentionally and what it has to do with indent guide functionality?
when would matching parts of separate tags be useful or desired?
the SynWeb editing component actually has the most useful behavior for tag and brace matching - it match-highlights only the opening/closing tag names, and when the cursor is adjacent to a tag angle bracket, it matches the corresponding closing angle bracket on that tag (> or />)
self-closed:
http://i.imgur.com/gajT0.png
tag brackets:
http://i.imgur.com/AF5gh.png
tag-names only:
http://i.imgur.com/DSZNB.png
To make xml/html indent guide lines highlighting work with tag, 2 positions ("<" and ">") have to be highlighted. It's scintilla component which imposes it.
If you know the way to not highlight them, please let me know.
Don
just wondering, since this was not required in previous versions with all the same settings enabled. not sure what changed.
I've seen this bug since version 5.4 or so and it is still present in 5.6.1.
Open any file. Click next to line no. A blue dot marker appears. Press Ctrl+f to search for a string. A window pops up. Hit 'clear' to clear all your previous 'styled' search and this would clear all markers as well.
I confirm that clar bug. I guess it's because of the set marker option in the search dialog.
McLoo
the double click to select word function seems broken after notepad++ opened a while.
for example:
foreach ($this->getArray("report") as $key=> $info)
double clicking "this" will result in "($this" selected,
double clicking "getArray" will result in ">getArray("report")" selected, and etc…..
after restarted notepad++, this issue seems solved, but after a while, it came back again.
P.S. I am using PHP syntax highlight.
"the double click to select word function seems broken after notepad++ opened a while."
The Ctrl+Shift+right arrow/left arrow also got this bug…..