Notepad++ v8.4.9 Release
-
FWIW, the minor Control-Tab regression seems to have been introduced in commit 662b54e28a (Add property sheet in VS project and clean project file), but I don’t (yet) know why though.
-
“Lycan Thrope” 's discussion here moved to created issue: https://github.com/notepad-plus-plus/notepad-plus-plus/issues/13042
-
@Lycan-Thrope said in Notepad++ v8.4.9 Release:
I’m not sure how to do the test that you asked for with the fix, so that’s my inexperience at issue. However, when I install the hack, in my machine and have opened 8.4.9 and minimize it so that when I double click on a .txt file, it will open the file in 8.4.9 instead of my default system installed version which is 8.4.8.
When I double click a .txt file, NPP 8.4.9 opens it with the orange coloring in the text area and states in the lower left corner that it is a JSON5 file. When I close 8.4.9, and then double click that same file, it opens in my default NPP 8.4.8 and opens it as a text file.OK, I see the problem. This issue is happening because you still keep a previous version of Notepad++ on your machine (in C:\Program File\Notepad++\ ) but the launched instance is version v8.4.9 which you put in another folder.
The scenario of issue cause is: when you use context menu or Notepad replacement, both point to
C:\Program File\Notepad++\notepad++.exe
which is, let’s say version 8.4.8, without the support of JSON5, so a unknown language file is detected byC:\Program File\Notepad++\notepad++.exe
(v8.4.8) as ENUM_UNKNOWN (number 86), then it passes number 86 as detected language to the launched instanceC:\you-new-v849-folder\Notepad++\notepad++.exe
, in which (v8.4.9) JSONS5 has been added as 86 and ENUM_UNKNOWN has been shifted to 87 - then this anomaly. happens.To remedy this issue, updating
C:\Program File\Notepad++\notepad++.exe
from v8.4.8 to v8.4.9 is necessary, via installer or copy/paste notepad++.exe manually. -
@donho ,
I understand what you’re saying…but doesn’t that kind of negate the choice of using a portable version, so you can test stuff without the standard version being subject to any bugs that 8.4.9 may have that one doesn’t want to use in their production install? :)
Thanks for finding the issue, however, so quickly. -
@Lycan-Thrope said in Notepad++ v8.4.9 Release:
@donho ,
I understand what you’re saying…but doesn’t that kind of negate the choice of using a portable version, so you can test stuff without the standard version being subject to any bugs that 8.4.9 may have that one doesn’t want to use in their production install? :)
Thanks for finding the issue, however, so quickly.The “notepad replacement” mode, just like automatic assocations, are focused on installed versions. So it was your trying to mix “notepad replacement” and portable, when you also had an installed version, that caused a weird confluence of events which shouldn’t normally happen.
If I’ve understood Don’s description correctly, your “notepad replacement” was pointing to the installed version (8.4.8), but you already had portable v8.4.9 open, so Windows tried to run the installed, which did the detection (picking 86), but once single-instance Notepad++ saw that there was already a Notepad++ open, so it passed the file and the 86 to the already-open Notepad++ (v8.4.9) in which instance 86 means JSON5, not “unknown”.
-
@PeterJones ,
Yep, that’s the way it sounded like he was explaining it to me, also. I get it, I just thought it humourous that we find what we think is a supposed “bug” in a new version and to get rid of it, we need to update to it. :) <-Notice smiley. :) -
I think I’ve found a solution for the Control-Tab regression, so I’ve opened a pull request (#13067).
-
I do have the same issue, running 64-bit version on Windows 10 Pro version 22H2 build 19045.2486
-
@Jupercio-Juliano said in Notepad++ v8.4.9 Release:
I do have the same issue
There’s like 31 postings in this thread…can you narrow it down to which topic you have the same issue as?
-
FWIW, plugins also look different in v8.4.9 when compared to v8.4.8. I guess this is also because v8.4.9 is a Windows Vista rather than a Windows XP executable now. Anyway, I think this is unlikely to cause any serious issues, so it’s probably fine.
-
@donho Same problem in version 8.4.9 whenever there is a space in the path or file name. Without spaces in the file or path name it works. Version 8.4.8 or earlier is not affected. -notepadStyleCmdline -z no longer seems to interpret the complete file path and file name as a whole.
-
@wallobit said in Notepad++ v8.4.9 Release:
-notepadStyleCmdline -z no longer seems to interpret the complete file path and file name as a whole.
Fixed, and fix will be in 8.5.
-
There is display bug on NPP, related to UTF-8 graphical symbols.
Here example of the text:
🞂 ◷ ◴ ◵ ◶ - clock
◷ ◴ ◵ ◶ - clock
This is how it looks in NPP
The bug is not limited to above symbols, there are quite a few that have similar issue.
Somehow putting that specific triangle symbol in the beginning of line suddenly makes all subsequent symbols also appear correctly. -
@Register-Noname said in Notepad++ v8.4.9 Release:
🞂 ◷ ◴ ◵ ◶ - clock
◷ ◴ ◵ ◶ - clockIt appears that you want DirectWrite enabled; see Settings > Preferences > MISC. As the Preferences dialog says, turning it on “may improve rendering special characters”.
I confirmed in v8.4.9 with my settings, DirectWrite off will have display problems like you showed, whereas DirectWrite on will show all the characters correctly:
But the same has been true for many versions, not just v8.4.9, so this really should have been a separate topic, since it’s not specific to v8.4.9.
@donho: BTW, we frequently get questions here that are solved by DirectWrite being on. Is there a reason that we cannot have that setting enabled by default – that way, new users will just see Notepad++ work great with Unicode characters, rather than having to come complain about poor Unicode behavior and then be told that they need to change a setting. Let me know if you want me to create an issue.
-
@PeterJones I agree this was true for very long time. Sorry I’m new here didn’t want go with opening tickets right away :)
DirectWrite (whatever it is) indeed helped. Thank you!
I also agree that this setting should be enabled by default if the ‘standard behavior’ cannot be fixed. -
Hello, @register-noname, @peterjones and All,
I did some tests and, indeed, the use of
DirectWrite
insrease rendering of characters !I verified that, if the
DirectWrite
option is not checked, the four Unicode characters, provided by @register-noname, are properly displayed ONLY IF the current line contains a character with codepoint over the BMP, so with codepointabove FFFF
!Compare these two screen-shoots below :
WITHOUT Direct Write
And :
WITH Direct Write
Note, particularly, the differences in lines
1
,2
,15
and16
;-))Best Regards,
guy038
-
Hi there, found a regression: the software does not launch anymore on Windows Vista and Windows Server 2008 systems (NT 6.0). The application quits with the error message
“The procedure entry point CoGetApartmentType could not be located in the dynamic link library ole32.dll.”
This issue seems to be present since 8.4.7 already, 8.4.6 is the last version that launches fine.
-
This was noted HERE as well.
Perhaps theSUPPORTED_SYSTEM.md
file is in need of updating. -
This issue seems to be present since 8.4.7 already, 8.4.6 is the last version that launches fine.
Could you help us to identify the problem please:
https://github.com/notepad-plus-plus/notepad-plus-plus/issues/13074#issuecomment-1445398398 -
-
@donho
Using 8.4.9 for Python.
When inserting a tab in an existing Python file, the editor does not respect the setting preference flag for converting tabs to spaces. That is, it always uses spaces whether “Replace by space” is checked or unchecked.
The line with 3 columns in the image has just had a tab inserted.Obviously this is dreadful for Python. It means that misalignment of new code can only be corrected by turning everything into spaces (not desirable) via unindent/indent of blocks.
NB it works ok for a new file (prior to save).
I will install the latest version to see if it is better and update here as appropriate.