This release should be the final release of v4.7.X.
The differences between the v4.7.2 and v.4.7.3 are :
1. The installer is enhanced.
2. Fix horizontal scroll bug regarding the folding issue.
3. Add a new behaviour that click on active tab of inactive view will make the inactive view as current view.
4. FTP_synchronize is updated.
Please report here if you find any critical problem.
If there's no critical problem found, I'll make updater point to this version,
so that the update will be applied automatically.
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This isn't a critical bug, but an annoyance that just started happening with this latest version: When the word wrap is selected, every new line you either click or move up/down with the arrow keys makes the horizontal scrollbar briefly appear then disappear.
So, it flickers like this when you scroll through a document.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Because of performance reasons. If oyu want the scrollbar as long as the longest line, you have to style the _entire_ document to know how long each line exactly is, and then loop through all the lines requesting line size, keeping track of the longest. Also, when something changes you have to make sure the scrollbar keeps the correct length. What if he longest line were to become shorter, or worse, what if the styler changes? This can be a matter of seconds, the current implementation is barely noticable, even with really large files with over 1000 lines.
Also, (this may be more of a personal pref.) I dont like it when I have a few short lines in the view and some very long one way up or down and still have to be pixel precice when I want to scroll something in the view. I'd rather have a small scrollbar only when actually necessary.
The wrap thing is a bug, Don uncommented some line that was kind of dangerous, recommenting should fix it back to the old behaviour ;).
-Harry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> ... the current implementation is barely noticable...
A scrollbar that keep dis- and re-appearing surely is noticeable. It is _annoying_.
> I dont like it when I have a few short lines in the view and some very long one way up
> or down and still have to be pixel precice when I want to scroll something in the view.
This is like saying: if my file only contains a few lines, I want my font to be bigger, because it will fit on one screen.
If you have short lines, I guess it won't matter much to you, because you won't have a long way to scroll. You don't have to be pixel precise. Just click next to the scroll bar itself in its space.
What really _is_ annoying, is that when I scroll through my file using PageUp and PageDown, I end up at a different horizontal position than where I started from.
If updating the scroll bar size is causing a performance problem then I suggest to set it to fit the longest line as soon as a file is loaded and update it when the file is scrolled vertically, or even only when the file is scrolled horizontally or even only when the user double clicks the scroll bar or something like that.
I don't think there is any good reason to change behavior to something worse (like now), because in _some_ cases this might be convenient.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> The wrap thing is a bug, Don uncommented some line that was kind of dangerous,
> recommenting should fix it back to the old behaviour ;).
For me, the horizontal scroll bar is displayed even in wrap mode, but no flicker when I scroll.
However, it's a bug.
Could you point me out where I uncommented ?
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Why the wrap mode need a horizontal scroll bar? In the previous, the wrap mode got no horizontal scroll bar.
Why don't just show horizontal scroll bar for non wrap mode?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Why don't make the horizontal sroll bar empty (I mean the part in the middle of the scroll bar) when it is not needed, but making it as long as the files length?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>Why don't make the horizontal sroll bar empty (I mean the part in the middle of the scroll bar) when it is not needed, but making it as long as the files length?
That was intially my intention but it didnt work out, it means Scintilla has to be altered, I havent touched that part much (only the part to fix scrolling ridiculously large lines :).
>Could you point me out where I uncommented ?
Right at the end of the recalcHorizontalScrollbar() function, its the ::ShowScrollBar(_hSelf, SB_HORZ); call
Maybe the patch didnt have the comment, I changed some things manually so it may have flipped over that.
>A scrollbar that keep dis- and re-appearing surely is noticeable. It is _annoying_.
I was pointing at performance, not visibility. And its not supposed to happen btw.
>Just click next to the scroll bar itself in its space.
I like to drag it, clicking shifts a page. I guess here it gets to the point where someone has to start making concessions (in general, not specifically you) since you cant have it all.
>What really _is_ annoying, is that when I scroll through my file using PageUp and PageDown, I end up at a different horizontal position than where I started from.
Thats because the caret gets moved so the view adjusts to it. it seems the scrollbar seems to be adjusted too early so scintilla adjusts to it, however its not supposed to scroll unless the caret moves out of the view which the direct page up/down would result it, its worth taking a look at.
>I suggest to set it to fit the longest line as soon as a file is loaded
Thats the old behaviour, and I removed it because of that performance impact it generates, since more and more stuff gets loaded at startup chipping off loadtimes seems like a plus to me.
The actual update is no problem as it is now, the initial precalculations were (for mostly because they were incorrect, but large files made it slow aswell, Notepad++ also targets to be somewhat fast if I get it correctly). If you were to use update where you keep track of the longest line, at each change you would have to run through the entire file to see if the longest line has become something else. You can keep a list of all linenumbers and how long they are, but I dont think that will work very smoothly, not to mention if you start inserting or deleting them (or fold).
Also, since Notepad++ doesnt have a virtual space function (or w/e it was called), I cant see any real advantage of working on a mostly white sheet with some end of lines at the left, IF your not going to move back to a longer line (the scrollbar is not supposed to push the view to the left, only prevent it from being pushed to the right too far, even if it already is). Also, if you keep the right arrow depressed Scintilla will scroll it as far as you want.
I think every editor does it in its own way and theres probably not a 'best' scrollbar algorithm, still I think this one works better than the previous, in a technical way (usability is something else).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I prefer usability over technique. What kind of bull shit is this?
You don't even reply to my suggestions.
Well, if loading is such a problem, then I suggest to have a small scroll bar based on what is visible to start with and then update it, so it will fit long(er) lines as well.
> The actual update is no problem as it is now...
Well, it IS. It makes the scroll bar dis- and re-appear over and over again and having it sized to only the visible part is more ridicolous than having one that may result in viewing some white space. If viewing white space is an issue, I guess you had better set your font to a small size, so always anything on a line will be visible and there will be no empty lines in your view.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> I prefer usability over technique. What kind of bull shit is this?
The old implementation had the performance issue, it's the technique that he was talking about.
The direction of the project is those who contributed decides.
If you don't like the new behaviour, you can always use the old version, or modify the code source to make it meet your need.
> You don't even reply to my suggestions.
He is not payed for replying any question/suggestion.
So I don't think he has any obligation to do so.
> It makes the scroll bar dis- and re-appear over and over again and having it sized
> to only the visible part is more ridicolous than having one that may result in
> viewing some white space.
Then it'll be fixed in next version.
BTW, I don't think your attitude is acceptable.
Everyone who works on this project is volunteer, you may not want to contribute your time on this project, but at least, you could be more cordial.
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hi there,
just a suggestion...
it seems that if you enable notepad++ auto-updater it tries to update backwards to v4.6 on each start.
i think it would be better for auto-updater to ignore updates if they are smaller than actually installed versions.
regards lual
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> it seems that if you enable notepad++ auto-updater it tries to update backwards to v4.6 on each start.
I can figure out now why your updater has such behaviour.
You have updated only Notepad++, but not gup.exe (updater).
Downloading the newest version of gup.exe from here then replacing the old one will remedy your problem : https://sourceforge.net/projects/gup-w32/
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not yet, because I want to make sure that release is stable and no regression.
Once I'm certain that it's stable, I'll make the update url point to this release, to update the old version (from v4.6 to v4.7.2)
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This release should be the final release of v4.7.X.
The differences between the v4.7.2 and v.4.7.3 are :
1. The installer is enhanced.
2. Fix horizontal scroll bug regarding the folding issue.
3. Add a new behaviour that click on active tab of inactive view will make the inactive view as current view.
4. FTP_synchronize is updated.
Please report here if you find any critical problem.
If there's no critical problem found, I'll make updater point to this version,
so that the update will be applied automatically.
Don
Ah, okay, sorry. Will wait :)
This isn't a critical bug, but an annoyance that just started happening with this latest version: When the word wrap is selected, every new line you either click or move up/down with the arrow keys makes the horizontal scrollbar briefly appear then disappear.
So, it flickers like this when you scroll through a document.
Why not just make the horizontal scrollbar as long as the longest line in the document, instead of recalculating it every time visible text changes?
Because of performance reasons. If oyu want the scrollbar as long as the longest line, you have to style the _entire_ document to know how long each line exactly is, and then loop through all the lines requesting line size, keeping track of the longest. Also, when something changes you have to make sure the scrollbar keeps the correct length. What if he longest line were to become shorter, or worse, what if the styler changes? This can be a matter of seconds, the current implementation is barely noticable, even with really large files with over 1000 lines.
Also, (this may be more of a personal pref.) I dont like it when I have a few short lines in the view and some very long one way up or down and still have to be pixel precice when I want to scroll something in the view. I'd rather have a small scrollbar only when actually necessary.
The wrap thing is a bug, Don uncommented some line that was kind of dangerous, recommenting should fix it back to the old behaviour ;).
-Harry
> ... the current implementation is barely noticable...
A scrollbar that keep dis- and re-appearing surely is noticeable. It is _annoying_.
> I dont like it when I have a few short lines in the view and some very long one way up
> or down and still have to be pixel precice when I want to scroll something in the view.
This is like saying: if my file only contains a few lines, I want my font to be bigger, because it will fit on one screen.
If you have short lines, I guess it won't matter much to you, because you won't have a long way to scroll. You don't have to be pixel precise. Just click next to the scroll bar itself in its space.
What really _is_ annoying, is that when I scroll through my file using PageUp and PageDown, I end up at a different horizontal position than where I started from.
If updating the scroll bar size is causing a performance problem then I suggest to set it to fit the longest line as soon as a file is loaded and update it when the file is scrolled vertically, or even only when the file is scrolled horizontally or even only when the user double clicks the scroll bar or something like that.
I don't think there is any good reason to change behavior to something worse (like now), because in _some_ cases this might be convenient.
> The wrap thing is a bug, Don uncommented some line that was kind of dangerous,
> recommenting should fix it back to the old behaviour ;).
For me, the horizontal scroll bar is displayed even in wrap mode, but no flicker when I scroll.
However, it's a bug.
Could you point me out where I uncommented ?
Don
I agree to this. There is no need to recalculate the size of the horizontal scroll bar, as long as the longest line isn't changed.
Why the wrap mode need a horizontal scroll bar? In the previous, the wrap mode got no horizontal scroll bar.
Why don't just show horizontal scroll bar for non wrap mode?
Why don't make the horizontal sroll bar empty (I mean the part in the middle of the scroll bar) when it is not needed, but making it as long as the files length?
>Why don't make the horizontal sroll bar empty (I mean the part in the middle of the scroll bar) when it is not needed, but making it as long as the files length?
That was intially my intention but it didnt work out, it means Scintilla has to be altered, I havent touched that part much (only the part to fix scrolling ridiculously large lines :).
>Could you point me out where I uncommented ?
Right at the end of the recalcHorizontalScrollbar() function, its the ::ShowScrollBar(_hSelf, SB_HORZ); call
Maybe the patch didnt have the comment, I changed some things manually so it may have flipped over that.
>A scrollbar that keep dis- and re-appearing surely is noticeable. It is _annoying_.
I was pointing at performance, not visibility. And its not supposed to happen btw.
>Just click next to the scroll bar itself in its space.
I like to drag it, clicking shifts a page. I guess here it gets to the point where someone has to start making concessions (in general, not specifically you) since you cant have it all.
>What really _is_ annoying, is that when I scroll through my file using PageUp and PageDown, I end up at a different horizontal position than where I started from.
Thats because the caret gets moved so the view adjusts to it. it seems the scrollbar seems to be adjusted too early so scintilla adjusts to it, however its not supposed to scroll unless the caret moves out of the view which the direct page up/down would result it, its worth taking a look at.
>I suggest to set it to fit the longest line as soon as a file is loaded
Thats the old behaviour, and I removed it because of that performance impact it generates, since more and more stuff gets loaded at startup chipping off loadtimes seems like a plus to me.
The actual update is no problem as it is now, the initial precalculations were (for mostly because they were incorrect, but large files made it slow aswell, Notepad++ also targets to be somewhat fast if I get it correctly). If you were to use update where you keep track of the longest line, at each change you would have to run through the entire file to see if the longest line has become something else. You can keep a list of all linenumbers and how long they are, but I dont think that will work very smoothly, not to mention if you start inserting or deleting them (or fold).
Also, since Notepad++ doesnt have a virtual space function (or w/e it was called), I cant see any real advantage of working on a mostly white sheet with some end of lines at the left, IF your not going to move back to a longer line (the scrollbar is not supposed to push the view to the left, only prevent it from being pushed to the right too far, even if it already is). Also, if you keep the right arrow depressed Scintilla will scroll it as far as you want.
Poke around the internet for messages about the scrollbar i.c.w. Scintilla, SciTe FAQ gives:
http://scintilla.sourceforge.net/SciTEFAQ.html#HorizontalScrollBar
Some thread:
http://ml.osdir.com/lib.scintilla.devel/2004-02/msg00003.html
I think every editor does it in its own way and theres probably not a 'best' scrollbar algorithm, still I think this one works better than the previous, in a technical way (usability is something else).
I prefer usability over technique. What kind of bull shit is this?
You don't even reply to my suggestions.
Well, if loading is such a problem, then I suggest to have a small scroll bar based on what is visible to start with and then update it, so it will fit long(er) lines as well.
> The actual update is no problem as it is now...
Well, it IS. It makes the scroll bar dis- and re-appear over and over again and having it sized to only the visible part is more ridicolous than having one that may result in viewing some white space. If viewing white space is an issue, I guess you had better set your font to a small size, so always anything on a line will be visible and there will be no empty lines in your view.
> I prefer usability over technique. What kind of bull shit is this?
The old implementation had the performance issue, it's the technique that he was talking about.
The direction of the project is those who contributed decides.
If you don't like the new behaviour, you can always use the old version, or modify the code source to make it meet your need.
> You don't even reply to my suggestions.
He is not payed for replying any question/suggestion.
So I don't think he has any obligation to do so.
> It makes the scroll bar dis- and re-appear over and over again and having it sized
> to only the visible part is more ridicolous than having one that may result in
> viewing some white space.
Then it'll be fixed in next version.
BTW, I don't think your attitude is acceptable.
Everyone who works on this project is volunteer, you may not want to contribute your time on this project, but at least, you could be more cordial.
Don
"BTW, I don't think your attitude is acceptable."
For sure, it's not. Whether the people working on this project are volunteers or getting payed, you never use such "grammar" on fora.
It's a matter of maturity and dignity...
Best rgds,
--Geert
hi there,
just a suggestion...
it seems that if you enable notepad++ auto-updater it tries to update backwards to v4.6 on each start.
i think it would be better for auto-updater to ignore updates if they are smaller than actually installed versions.
regards lual
> it seems that if you enable notepad++ auto-updater it tries to update backwards to v4.6 on each start.
No, it's not true.
> i think it would be better for auto-updater to ignore updates if they are smaller than actually installed versions.
Indeed, it's the actual implementation.
Don
> it seems that if you enable notepad++ auto-updater it tries to update backwards to v4.6 on each start.
I can figure out now why your updater has such behaviour.
You have updated only Notepad++, but not gup.exe (updater).
Downloading the newest version of gup.exe from here then replacing the old one will remedy your problem :
https://sourceforge.net/projects/gup-w32/
Don
how do I get the auto updater to run? It is not running for me? I have the auto update option checked...
Why is the function list plugin no longer available in the installer? I love this plugin!!
Take care
Tobi
It is not auto updating for me at all...
Not yet, because I want to make sure that release is stable and no regression.
Once I'm certain that it's stable, I'll make the update url point to this release, to update the old version (from v4.6 to v4.7.2)
Don
Straight crash triggering dwwin32 for v4.73, no way to work aroud, v4.72 was ok!!!
Just found out the crash is caused by NppExport_v0.2.6 (January 5, 2008), sorry for the wrong blame
Could you give us more description to reproduce the crash, so we can remove the crash problem?
Thank you.
Don
Could you please tell when this crash happens?