Notepad++ v8.4.9 Release

[PeterJones]

@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”.

[Lycan Thrope]

@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. :)

[Theo Niessink]

I think I’ve found a solution for the Control-Tab regression, so I’ve opened a pull request (#13067).

[Jupercio Juliano]

I do have the same issue, running 64-bit version on Windows 10 Pro version 22H2 build 19045.2486

[Alan Kilborn]

@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?

[Theo Niessink]

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.

[wallobit]

@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.

[Alan Kilborn]

@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.

[Register Noname]

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.

[PeterJones]

@Register-Noname said in Notepad++ v8.4.9 Release:

🞂 ◷ ◴ ◵ ◶ - clock
◷ ◴ ◵ ◶ - clock

It 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.

[Register Noname]

@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.

[guy038]

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 codepoint above FFFF !

Compare these two screen-shoots below :

WITHOUT Direct Write

And :

WITH Direct Write

Note, particularly, the differences in lines 1 , 2 , 15 and 16 ;-))

Best Regards,

guy038

[makuhlmann]

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.

[Alan Kilborn]

@makuhlmann

This was noted HERE as well.
Perhaps the SUPPORTED_SYSTEM.md file is in need of updating.

[donho]

@makuhlmann

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

[Ann Witbrock]

@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.

[Alan Kilborn]

@Ann-Witbrock said in Notepad++ v8.4.9 Release:

turning everything into spaces (not desirable)

Did you know that the recommended standard for Python is to use spaces for indentation and NOT tab characters?

the editor does not respect the setting preference flag for converting tabs to spaces.

You aren’t showing the setting for Python in your screenshot. Scroll the listbox in the Tab Settings groupbox down to where the python item is shown and make it active, and then post THAT screenshot. Only then will we know what the setting for Python files is.

[Ann Witbrock]

@Alan-Kilborn Unfortunately we can not always work in our own files. We can still expect our editor to work as expected. I discovered this glitch while working in such a file, when I added some print lines to see the workings. It would have been fine if I could have set the compatibility at all.

The same behaviour is still present in 8.5.2 (see detailed progression of test), including fully setting Python as you pointed out, thanks :-)
(The label “Disabled items” was a bit confusing there, and it’s been a while since I used this editor often so I misinterpreted the highlight).

I think we can probably conclude this is also true for other languages, but it’s vital for Python.

[Alan Kilborn]

@Ann-Witbrock said in Notepad++ v8.4.9 Release:

including fully setting Python as you pointed out

How come you aren’t showing this to us here, in a screenshot, like I asked?

The label “Disabled items” was a bit confusing

Disabled items has nothing to do with what we’re discussing.

Show us your setting like this, with python in view and selected:

[Mark Olson]

@Ann-Witbrock
before:

use Edit->Blank Operations->TAB to SPACE

after: