[BUG] <title>Disabled options for character encoding

[dimmav]

Is there an existing issue for this?

• [x] I have searched the existing issues

Is the issue reproducible in Notepad++ without plugin?

• [ ] I have tried Notepad++ without plugin

Is the issue reproducible in portable version of Notepad++?

• [ ] I have tried portable version of Notepad++

Does the issue affect SciTE?

• [ ] I have tried SciTE

Description of the Issue

It looks like v8.8.8 has disabled some options for character encoding.

1. In Settings > Preferences > New document, ANSI is disabled and "Apply to opened ANSI files" is also disabled.
2. In Encoding menu, ANSI is also disabled.
3. When creating a New > Text document with Windows Context Menu and open this file, it remains without a specific encoding and is not automatically converted to the preferred encoding.

When we revert to an older version (like 8.8.5), the above behavior disappears and everything works smoothly.

Steps To Reproduce

1. In NPP v8.8.8 go to Settings > Preferences > New document, select UTF-8 for encoding (and try to check "Apply to opened ANSI files").
2. Close NPP;
3. Create a New > Text document with Windows Context Menu.
4. Open the file with NPP.
5. Check the Encoding menu. No encoding is selected.
6. Install NPP v8.8.7 and repeat the above. See that in step 5, Encoding UTF-8 is selected.

Current Behavior

I can't control the encoding of new empty files.

Expected Behavior

New documents should have the preferred encoding when "Apply to opened ANSI files" is checked.

Debug Information

Notepad++ v8.8.8   (64-bit)
Build time: Nov 16 2025 - 20:55:01
Scintilla/Lexilla included: 5.5.7/5.4.5
Boost Regex included: 1_85
Path: C:\Program Files\Notepad++\notepad++.exe
Command Line: "C:\Program Files\Notepad++\change.log" 
Admin mode: OFF
Local Conf mode: OFF
Cloud Config: OFF
Periodic Backup: OFF
Placeholders: OFF
Scintilla Rendering Mode: SC_TECHNOLOGY_DIRECTWRITE (1)
Multi-instance Mode: monoInst
asNotepad: OFF
File Status Auto-Detection: cdEnabledNew (for current file/tab only)
Dark Mode: OFF
Display Info:
    primary monitor: 1920x1080, scaling 105%
    visible monitors count: 1
    installed Display Class adapters: 
        0000: Description - AMD Radeon R7 200 Series
        0000: DriverVersion - 27.20.1034.6
OS Name: Windows 11 Home (64-bit)
OS Version: 25H2
OS Build: 26200.6584
Current ANSI codepage: 65001
Plugins: 
    DSpellCheck (1.5)
    mimeTools (3.1)
    NppConverter (4.7)
    NppExport (0.4)

Anything else?

No response

[xomx]

Current ANSI codepage: 65001

You have enabled the Windows Settings > Time & language > Language & region > Language > Beta: Use Unicode UTF-8 for worldwide language support. Because of that, the ANSI system code page for you is now actually UTF-8.

• In Settings > Preferences > New document, ANSI is disabled and "Apply to opened ANSI files" is also disabled.

• In Encoding menu, ANSI is also disabled.

If you disable (uncheck) that Windows feature, these options become accessible again.

[Coises]

Confirmed on Windows 10 with Notepad++ 8.8.8 (64), Windows setting Use Unicode UTF-8 for worldwide language support enabled.

This is a bug. The encoding should be UTF-8. When opening an empty (length 0) file, no encoding is selected on the Encoding menu, and ANSI is shown in the status bar.

Opening the PythonScript console and entering editor.getCodePage() returns 0; this should always be 65001 when the system code page is 65001.

[Coises]

@dimmav:

As @xomx noted, the ANSI options are intentionally disabled when the Windows option Use Unicode UTF-8 for worldwide language support is enabled; for a full discussion, see Encoding and Use Unicode UTF-8 for worldwide language support in the user manual and Issue #17057.

However, you are correct that Notepad++ 8.8.8 misbehaves when opening an empty file. It should open it as UTF-8; instead, it opens it as ANSI (which isn’t supposed to be possible in 8.8.8 when Use Unicode UTF-8 for worldwide language support is in effect).

Suggestion: I think you can edit the title of this issue. The disabled options are not a bug, but the way Notepad++ is opening the empty file is. You had no way of knowing this when you opened the issue, but Empty file opens with wrong encoding when Windows is set to use UTF-8 would better describe what is actually wrong.

[trainvoi]

Would rolling back to a previous version of Notepad++ solve this issue?

[dimmav]

Yes. Version 8.8.7 is working fine. This is how newer versions should work. But 8.8.8 and 8.8.9 don't.

On Fri, Dec 19, 2025, 14:51 trainvoi @.***> wrote:

trainvoi left a comment (notepad-plus-plus/notepad-plus-plus#17258) https://github.com/notepad-plus-plus/notepad-plus-plus/issues/17258#issuecomment-3674967815

Would rolling back to a previous version of Notepad++ solve this issue?

— Reply to this email directly, view it on GitHub https://github.com/notepad-plus-plus/notepad-plus-plus/issues/17258#issuecomment-3674967815, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABWFZGVVY5NGQLRJ3BIP4YL4CPYDJAVCNFSM6AAAAACN25HGUWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMNZUHE3DOOBRGU . You are receiving this because you were mentioned.Message ID: @.***>

[Coises]

@trainvoi:

Would rolling back to a previous version of Notepad++ solve this issue?

While it would avoid this issue, it would also mean returning to the behavior described in Issue #17057. One way this could occur would be opening a file that is encoded in the legacy “ANSI” encoding for the system and contains some non-ASCII characters. It won’t open as UTF-8 because it isn’t UTF-8 or pure ASCII; it will open as ANSI, which would be correct if Use Unicode UTF-8 for worldwide language support were not checked, but which does not work properly when that option is checked. Notepad++ 8.8.8 and later will correctly open such a file using the appropriate selection from Encoding | Character sets submenus, which does work.

Opening an empty file (or any file) as ANSI when Use Unicode UTF-8 for worldwide language support is checked is a bug. I suspect this thread just hasn’t gotten @donho’s attention yet.

@dimmav: That’s why I suggested editing the title. Disabling those options is correct behavior, so it’s easily passed over as a misunderstanding. Opening an empty file with what appears to be no encoding (actually it is opened as the supposedly disabled ANSI encoding) is a bug.

My guess is that the problem happens because this code looks at the Apply to opened ANSI files setting. That setting is (correctly) disabled when Use Unicode UTF-8 for worldwide language support is checked, but in my opinion it should be disabled but checked, rather than disabled unchecked. If for some reason it must be disabled but unchecked, then the condition in that line is incomplete.