Notepad++ v8.4.7 Release Candidate
-
Notepad++ v8.4.7 Release Candidate:
http://download.notepad-plus-plus.org/repository/8.x/8.4.7.RC/Change log:
- Fix empty session issue due to forced Windows update restart. (Fix #9850, #12389, #5737, #4148, #2730… and much more)
- Fix printing with extra background colors issue due to Change History. (Fix #12281)
- Update to scintilla 5.3.1 and lexilla 5.2.0. (Implement #12327)
- Updated nlohmann json to 3.11.2 and boost to 1.80.0. (Implement #12271, #12273)
- Make large file restriction configurable. (Fix #11389, #12260, #11670)
- Optimize open/save large files time. ( Commit)
- Remember Column Editor settings through the sessions. (Implement #12386)
- Fix plugin admin search issue. (Fix #12375)
- Installer enhancement: prevent arm64 installer from installing on non ARM64 system. (Fix #12320)
- Installer enhancement: remember “Don’t use_%APPDATA%” option. (Fix #12202)
- Add new API NPPM_GETBOOKMARKID for getting bookmark ID. (Fix Commit)
- Enhance “Go To” dialog: update line/position data dynamically. (Fix #12284)
- Fix lines hiding issue. (Fix #12184, #8149)
- Fix language detected from content not applied if default language is set. (Fix #11504)
- Fix long filters get truncated in Find in Files feature. (Fix #12041)
- Add ESC Key for aborting “Move to Recycle Bin” confirmation prompt. (Fix #12117)
Enjoy v8.4.7 RC!
-
P PeterJones referenced this topic on
-
I consider setting a green change history marker on every line of a file when the Reload from disk command is executed to be a bug, because it isn’t useful to do this. IMO this command should result in an empty change history margin throughout the lines of the file.
Anyway, this bug is still present in 8.4.7 RC.
Apparently this is a bug from Scintilla that hasn’t been fixed, even with an “update to scintilla 5.3.1” in the meantime?
I bring this up because I wonder if Notepad++ can do anything to fix it (by working around it for the time being), because such problems introduced by a new feature such as Change History can turn people off to the feature and the product.
Sure I’ve made previous statements about such a big feature having some “growing pains”, but apparently it is new release time, and perhaps the opportunity thus exists to mitigate some of the pains.
-
@Alan-Kilborn said in Notepad++ v8.4.7 Release Candidate:
I consider setting a green change history marker on every line of a file when the Reload from disk command is executed to be a bug, because it isn’t useful to do this.
I agree with it. I will see what I can do about it in the future versions.
-
Recently a user reported that the green change history marker also appears when changing (not converting!) the character encoding of a file. Since this doesn’t change the content of a file but only the interpretation of the content, I would consider showing the change history bar in this case as a bug too.
Seems like there have to be done more investigations which features of Notepad++ trigger the change history bar.
-
@dinkumoil said in Notepad++ v8.4.7 Release Candidate:
changing (not converting!) the character encoding of a file
Not an expert at this, but changing character encoding would change the bits/bytes on disk (maybe?) and thus trigger the Scintilla change history. I think these should ultimately be addressed with bugs / feature requests to Scintilla, but I also think Notepad++ could probably do some “work arounds” to make it behave as expected.
I’ve already filed a bug or two with Scintilla regarding change history. Ultimately, the usefulness for me outweighs any of these hiccups and I know how to deal with them should they really annoy me, but ultimately we need to appease a much larger potentially less willing to “hack a PythonScript solution” community.
Cheers.
-
@dinkumoil said in Notepad++ v8.4.7 Release Candidate:
when changing (not converting!) the character encoding
this doesn’t change the content of a file but only the interpretation of the content
@Michael-Vincent said in Notepad++ v8.4.7 Release Candidate:
Not an expert at this, but changing character encoding would change the bits/bytes on disk (maybe?)
dinkumoil means the equivalent of choosing one of the options on the Encoding menu ABOVE the separator. Although it is far from clear from the text of those menu options, these do NOT change the data in any way, just the interpretation of the data, in order for N++ to show you something (and hopefully the correct thing) visually. If nothing bits-n-bytes-wise has changed, change history shouldn’t trigger.
-
@Michael-Vincent said in Notepad++ v8.4.7 Release Candidate:
changing character encoding would change the bits/bytes on disk
No, it doesn’t. There is a difference between changing and converting character encoding.
Changing character encoding only causes a reinterpretation of a file’s content, i.e. what is shown in Npp’s editing window is different from that what has been shown before encoding change but the bytes in RAM are not touched. When the file is saved, the bytes on disk are the same as before.
When converting the character encoding, even the bytes in RAM representing the file’s content are changed - code points from the source encoding are mapped to code points of the target encoding and after that the file’s content is reinterpreted using the target encoding. So, the glyphs you see on screen may be the same like before encoding conversion (it depends on having equivalent glyphs in source and target encoding scheme). But when the file is saved, the bytes on disk are (obviously) not the same anymore.
The difference between changing and converting character encoding is the reason why we have different menu entries for them:
The menu entries in the red box convert (as their names suggest) the encoding of a file whereas all the menu entries in the green boxes only change the encoding, i.e. they trigger Npp to only reinterpret a file’s content.
You explained it in a much more shorter way!
-
-
@donho said in Notepad++ v8.4.7 Release Candidate:
- Fix language detected from content not applied if default language is set
I have confirmed that this is working for me: the default language isn’t overriding a detected language, and shebang/prolog/first-line detection isn’t overriding known extensions.
Thanks for all the work that @rdipardo and @ArkadiuszMichalski put into hashing out the exact priorities required and making it work, and for putting up with my inputs even when I misunderstood and otherwise confused things.
-
@donho said in Notepad++ v8.4.7 Release Candidate:
- Fix printing with extra background colors issue due to Change History.
I confirmed that it no longer includes the Change History margin colors as background colors when printing. Thanks for fixing that! :-)
-
C conky77 referenced this topic on
-
@dinkumoil said in Notepad++ v8.4.7 Release Candidate:
Recently a user reported that the green change history marker also appears when changing (not converting!) the character encoding of a file. Since this doesn’t change the content of a file but only the interpretation of the content, I would consider showing the change history bar in this case as a bug too.
Is there any issue opened in GitHub? If no, could you open one - I’ll also see what I can do about it.
-
-
Is there any issue opened in GitHub?
Cf. Reloading a file will mark all lines as changed in change history bar
Does changing the encoding cause buffer reload? If yes, it’s probably the same issue as the reported one.
The reload issue is already being addressed upstream:
An issue that has appeared with change markers is that SciTE’s Revert command leads to the whole document getting a green change mark as revert just reloads each byte of the file. Since its useful to undo to before the revert, this point can’t just be set as the start of change history to appear clear.
[ . . . ]
This is implemented in SciTE and only works for moderate length (1MB) files in 8-bit encodings as it reads the whole file into a temporary buffer and then checks and modifies. A streaming version could be written that would handle larger files. Scintilla could also add an ‘Update’ API that could minimize change markers.https://groups.google.com/g/scite-interest/c/I2wN_BiPfGM/m/70AoM0loAQAJ
(emphasis added) -
@dinkumoil said in Notepad++ v8.4.7 Release Candidate:
Recently a user reported that the green change history marker also appears when changing the character encoding of a file.
@donho said in Notepad++ v8.4.7 Release Candidate:
Is there any issue opened in GitHub?
It is not necessary to open an issue. Using SysInternals’ ProcMon I was able to figure out that Notepad++ reopens a file when its character encoding is changed. So, the issue I was talking about should be resolved automatically when already existing issue Reloading a file will mark all lines as changed in change history bar gets resolved.
-
@dinkumoil said in Notepad++ v8.4.7 Release Candidate:
It is not necessary to open an issue. Using SysInternals’ ProcMon I was able to figure out that Notepad++ reopens a file when its character encoding is changed. So, the issue I was talking about should be resolved automatically when already existing issue Reloading a file will mark all lines as changed in change history bar gets resolved.
I can reproduce it. The issue is kind of reminder (assigned to me) to put me on the track when I’ve time to work on it.
-
-
D donho unpinned this topic on
-
