Notepad++ v8.4.9 Release

[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:

[Ann Witbrock]

@Alan-Kilborn I’m sorry you are not making yourself at all clear.

I see in the thread below that there is a new, additional place to set this. I had not noticed this in the menu. Perhaps the word Blank is not so obvious if you aren’t expecting it.

I’ll try again with that setting. Not sure how that should interact with the global setting.

[Alan Kilborn]

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

I’m sorry you are not making yourself at all clear.

I think I’m pretty clear, if you’d just read and provide what I’m asking for.
You are probably referring to Mark’s posting, which isn’t going to help you solve the root of your problem (which is, what you get [spaces or tab character] when you press the Tab key).

[Ann Witbrock]

@Alan-Kilborn It’s OK I see it now, I was attempting setting the language in the main panel rather than the tab settings panel. I’m sorry. I’ve been using other editors more recently and missed the labelling. It’s really quite obvious ONCE YOU SEE IT!
And it does resolve my problem, indeed.

To avoid confusion, it might be useful to have it obey the default when no language is set.

I’ve tried out the edit menu settings as well now (thanks Mark for pointing me in the right direction) and although it’s a little confusing it seems to be quite useful :-) This actually would have saved me all the trouble if I’d noticed in advance and changed all the tabs to spaces as normal.

Hopefully this discussion will help others if they come across this. Thanks.