Notepad++ v5.3 new feature and fixed bugs (from v5.2) :
1. Add Line change state vertical bar.
2. Drop (or open in dos command line) a directory in Notepad++ to open all files in the directory recursively.
3. Add "Find all in current file" feature.
4. (Most of) Find/replace dialog settings are remembered.
5. Add a hidden setting (dlgAlwaysVisible in config.xml) to allow user set it manually to not hide the Find/Replace dialog if any result found.
6. Fix uncomment block erasing first character bug.
7. Enlarge some strings displayed zone for the translation.
8. Fix ESC key for column mode behaviour.
9. Fix read only file SaveAs bug.
10. Change behaviour : no popup dialog while closing an unsaved empty untitled document.
11. Changing "Search result" stylers via Styler Configurator takes visual effect on the fly now.
12. Fix for L_EXTERNAL in loadSession.
13. Variable $(CURRENT_WORD) is enlarged to 2039 charraters.
Please post your bug reports here.
The v5.3 OR will be ready in one week if there are no critical bug found.
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thanks for the really nice improvements! One thing I've found (and I don't know if it is deliberately or not), is that the Line change state doesn't follow Undo-Redo actions accurately, ie. if I write something and save it, then make Undo and then Redo, the vertical bar remains "orange" (while the file is in its saved state). Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> ... is that the Line change state doesn't follow Undo-Redo actions accurately, ...
Yes I know it. This feature is experimental, and still buggy - I wonder if it's worth to include it in the release. But since I spent time to implement it, I would like to know what people think about it.
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But I would recommend to use SC_MARK_FULLRECT as symbol for it and make it a little smaller.
The problem of the Undo is that you can only check if you reached a savepoint. There is no way to find out if the line is modified or restored, at least without modifying Scintilla.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>But I would recommend to use SC_MARK_FULLRECT as symbol for it and make it a little smaller.
>
>The problem of the Undo is that you can only check if you reached a savepoint. There is no way to find >out if the line is modified or restored, at least without modifying Scintilla.
Jonas,
Having a modifiable marker would be best IMO, and there is no need to modify Scintilla to achieve the capability of determining a lines state when undo/redo goes farther back than the savepoint. What is needed is reimplementing the currAction counter outside of Scintilla; and if one was to modify Scintilla, perhaps providing get access to pDoc->cb->uh.currAction would be the way to go, then the container would be able to synch up without needing to parse notifications for counting. Although, for that to really work effectively for a plugin it would even be better if Notepad++ provided access to bufferID to pdoc mapping through the getBufferFromDocument or some such...
In the change marker plugin I have been working on (which seems like a duplication of effort now ( Sorry Don) ) the action counter is tracking ideally. Just five more pieces of the puzzle to finish and I'll post/submit the plugin.
almostautomated
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>> But I would recommend to use SC_MARK_FULLRECT as symbol for it
>> and make it a little smaller.
> Having a modifiable marker would be best IMO
Using SC_MARK_FULLRECT allows users to change markers' colours.
In v5.3 OR the colours of both saved change marker and unsaved change marker can be changed in Stylers Configurator.
> there is no need to modify Scintilla to achieve the capability of determining a lines state
> when undo/redo goes farther back than the savepoint.
Then I'm interested by your implementation.
Be careful if you monitor SCN_MODIFIED in your plugin.
In v5.3 RC, find in files performance is reduced considerably because of that (it will be fixed in the OR).
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've sent you an email with a zipped file of what I am working on. IT IS NOT DONE! Sorry it is taking so long but finding work-arounds to have the info needed when it is needed can be (as you know) tricky.
The parts you may be interested in looking at regarding the SCN_MODIFIED may be helpful to you now though so I thought I had better get it to you.
They are in NppPluginIface_DocTabMap and NppPluginIface_ActionIndex.
The NppPluginIface_ActionHistory and NppPlugin_ChangeMarker are the two parts that are in limbo right now with the rest of the files in pretty much there finished state for an alpha release.
There are some pretty cool things, like plugin xml config file control, command enum vlaues to Npp cmdID mapping, ability to load external XPM files for markers, and SciMarkerSymbol to allow plugins to co-ordinate on selecting available marker ids and releasing them when done. And a bunch of other stuff.
almostautomated
If anyone else might be interested in taking a alpha preview look at this let me know. It'd be great if we could get some people together on IRC to work together on some of this and other things. ( Freenode anyone? )
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Nice to know that it is possible. I haven't digged that far and thought that it ain't possible, but if you have it working, it is nice :)
Would you mind handing the code over to donho, so that he can use your implementation? Since this is a nice feature and it would be awesome to have it full functional in N++
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you again for this new version, expecially for the feature #1.
I don't know if is bug or not but the "Find in files.." is more slow than the previous version (let's say about 4-5 times) (ANSI version)
BR
Mauro
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think this is could be a bug:
When in column select mode, alternately executing to Uppercase and to Lowercase works only the first time.
This happens with both 5.2 and 5.3 RC (unicode), with and without plugins loaded. (Never tried with ansi).
Repro steps:
1. Select a column of text (any width/height) using Alt-Shift-Arrow keys/left click
2. Press Ctrl-Shift-U to make it uppercase. This should work
3. Without changing the text selection, press Ctrl-U to make it lowercase. This should now fail
It doesn't matter whether upper or lowercase is executed first. As long as the column selection is not modified, the subsequent case change will fail. It works fine with regular text selection though.
Executing case change via Edit menu or context menu will deselect the text afterwards, so the problem doesn't arise, but using shortcut keys is more productive IMO :-)
Thank you and regards
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First I want to thank you for the great effort you are making in this project.
I'm having a problem in this version. Every time I perform search in files it takes MUCH longer than in previous versions for example i'm searching for a string in files to find 286 hits in 14 files
in version 5.2 it takes 2 seconds
in version 5.3 it takes 55 seconds...
Avner
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Would it be possible for you to post the document (pastebin) and the find/replace args you're using. I'd like to test the speed of my implementation of change markers.
almostautomated.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please do not fill a thread about a Release Candidate with (new) feature requests, or even messages about "what I asked before isn't implemented in this version".
You should not be surprised to never get a reply to them (other than like this one), because that's not what this thread is for.
Please, only report about release specific unwanted changes or bugs, helping in the most efficient way to get the release candidate to become an official release.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here you can download Notepad++ v5.3 Release Candidate :
http://notepad-plus.sourceforge.net/commun/misc/npp.v5.3.RC.zip
Notepad++ v5.3 new feature and fixed bugs (from v5.2) :
1. Add Line change state vertical bar.
2. Drop (or open in dos command line) a directory in Notepad++ to open all files in the directory recursively.
3. Add "Find all in current file" feature.
4. (Most of) Find/replace dialog settings are remembered.
5. Add a hidden setting (dlgAlwaysVisible in config.xml) to allow user set it manually to not hide the Find/Replace dialog if any result found.
6. Fix uncomment block erasing first character bug.
7. Enlarge some strings displayed zone for the translation.
8. Fix ESC key for column mode behaviour.
9. Fix read only file SaveAs bug.
10. Change behaviour : no popup dialog while closing an unsaved empty untitled document.
11. Changing "Search result" stylers via Styler Configurator takes visual effect on the fly now.
12. Fix for L_EXTERNAL in loadSession.
13. Variable $(CURRENT_WORD) is enlarged to 2039 charraters.
Please post your bug reports here.
The v5.3 OR will be ready in one week if there are no critical bug found.
Don
Hi Don,
What about the problem with updating stylers.xml for the new searchResults styles?
Yuval,
I have not yet a solution about it.
I'll work on xml updater as soon as I have the time.
Don
Hi Don,
thanks for the really nice improvements! One thing I've found (and I don't know if it is deliberately or not), is that the Line change state doesn't follow Undo-Redo actions accurately, ie. if I write something and save it, then make Undo and then Redo, the vertical bar remains "orange" (while the file is in its saved state). Thanks!
> ... is that the Line change state doesn't follow Undo-Redo actions accurately, ...
Yes I know it. This feature is experimental, and still buggy - I wonder if it's worth to include it in the release. But since I spent time to implement it, I would like to know what people think about it.
Don
It's a very nice feature that was implemented in Multi edit, if it will work good it would be awesome
It is worth to include in OR.
But I would recommend to use SC_MARK_FULLRECT as symbol for it and make it a little smaller.
The problem of the Undo is that you can only check if you reached a savepoint. There is no way to find out if the line is modified or restored, at least without modifying Scintilla.
>But I would recommend to use SC_MARK_FULLRECT as symbol for it and make it a little smaller.
>
>The problem of the Undo is that you can only check if you reached a savepoint. There is no way to find >out if the line is modified or restored, at least without modifying Scintilla.
Jonas,
Having a modifiable marker would be best IMO, and there is no need to modify Scintilla to achieve the capability of determining a lines state when undo/redo goes farther back than the savepoint. What is needed is reimplementing the currAction counter outside of Scintilla; and if one was to modify Scintilla, perhaps providing get access to pDoc->cb->uh.currAction would be the way to go, then the container would be able to synch up without needing to parse notifications for counting. Although, for that to really work effectively for a plugin it would even be better if Notepad++ provided access to bufferID to pdoc mapping through the getBufferFromDocument or some such...
In the change marker plugin I have been working on (which seems like a duplication of effort now ( Sorry Don) ) the action counter is tracking ideally. Just five more pieces of the puzzle to finish and I'll post/submit the plugin.
almostautomated
>> But I would recommend to use SC_MARK_FULLRECT as symbol for it
>> and make it a little smaller.
> Having a modifiable marker would be best IMO
Using SC_MARK_FULLRECT allows users to change markers' colours.
In v5.3 OR the colours of both saved change marker and unsaved change marker can be changed in Stylers Configurator.
> there is no need to modify Scintilla to achieve the capability of determining a lines state
> when undo/redo goes farther back than the savepoint.
Then I'm interested by your implementation.
Be careful if you monitor SCN_MODIFIED in your plugin.
In v5.3 RC, find in files performance is reduced considerably because of that (it will be fixed in the OR).
Don
Don,
I've sent you an email with a zipped file of what I am working on. IT IS NOT DONE! Sorry it is taking so long but finding work-arounds to have the info needed when it is needed can be (as you know) tricky.
The parts you may be interested in looking at regarding the SCN_MODIFIED may be helpful to you now though so I thought I had better get it to you.
They are in NppPluginIface_DocTabMap and NppPluginIface_ActionIndex.
The NppPluginIface_ActionHistory and NppPlugin_ChangeMarker are the two parts that are in limbo right now with the rest of the files in pretty much there finished state for an alpha release.
There are some pretty cool things, like plugin xml config file control, command enum vlaues to Npp cmdID mapping, ability to load external XPM files for markers, and SciMarkerSymbol to allow plugins to co-ordinate on selecting available marker ids and releasing them when done. And a bunch of other stuff.
almostautomated
If anyone else might be interested in taking a alpha preview look at this let me know. It'd be great if we could get some people together on IRC to work together on some of this and other things. ( Freenode anyone? )
Nice to know that it is possible. I haven't digged that far and thought that it ain't possible, but if you have it working, it is nice :)
Would you mind handing the code over to donho, so that he can use your implementation? Since this is a nice feature and it would be awesome to have it full functional in N++
Congrats on the 5.3! Especially points #1, #11, and #12; very helpful.
Just tried it out and very nice.
almostautomated
Thank you again for this new version, expecially for the feature #1.
I don't know if is bug or not but the "Find in files.." is more slow than the previous version (let's say about 4-5 times) (ANSI version)
BR
Mauro
I think this is could be a bug:
When in column select mode, alternately executing to Uppercase and to Lowercase works only the first time.
This happens with both 5.2 and 5.3 RC (unicode), with and without plugins loaded. (Never tried with ansi).
Repro steps:
1. Select a column of text (any width/height) using Alt-Shift-Arrow keys/left click
2. Press Ctrl-Shift-U to make it uppercase. This should work
3. Without changing the text selection, press Ctrl-U to make it lowercase. This should now fail
It doesn't matter whether upper or lowercase is executed first. As long as the column selection is not modified, the subsequent case change will fail. It works fine with regular text selection though.
Executing case change via Edit menu or context menu will deselect the text afterwards, so the problem doesn't arise, but using shortcut keys is more productive IMO :-)
Thank you and regards
Hi,
First I want to thank you for the great effort you are making in this project.
I'm having a problem in this version. Every time I perform search in files it takes MUCH longer than in previous versions for example i'm searching for a string in files to find 286 hits in 14 files
in version 5.2 it takes 2 seconds
in version 5.3 it takes 55 seconds...
Avner
Avner,
Would it be possible for you to post the document (pastebin) and the find/replace args you're using. I'd like to test the speed of my implementation of change markers.
almostautomated.
I've noticed that too. It's really much slower.
> I've noticed that too. It's really much slower.
Does it is the same to you between v5.2 and v5.3 ?
Don
in 5.2 it takes 2 seconds
in 5.3 it takes 55 seconds
I confirm Avner's observation. 5.3 is much slower than 5.2 when searching in files.
The problem is identified, thanks to Yuval.
This regression will be fixed in v5.3 OR.
Don
Can you please add synthax highligtning for DigitalMars D programming language?
Please, add an opportunity of the Synchronized Scrolling (gor. & ver.), without the second window.
Please do not fill a thread about a Release Candidate with (new) feature requests, or even messages about "what I asked before isn't implemented in this version".
You should not be surprised to never get a reply to them (other than like this one), because that's not what this thread is for.
Please, only report about release specific unwanted changes or bugs, helping in the most efficient way to get the release candidate to become an official release.
fantastic for the #1 and #3
I am very sad to curently work in a compgny which works on linux, and in which it is not possible to use wine...