@jw I suggest adding an option to select the AI module.

@dz15mlru Disable automatic encoding recognition. For Windows-1251 encoded Russian, auto-recognition will always open as Macintosh. If you start editing files, you will have two encodings, or rather garbage from two encodings, which will be difficult to fix manually, since you will have to re-read all the texts (this is a module for spoiling files). When you disable automatic encoding assignment, you will only have ANSI, UTF-8, UTF-16. WindowsXP-7-8-10-11 it will always open the ANSI file correctly, in 1251 encoding, as this is the default encoding. The remaining UTF-8 and others will also open automatically correctly. You will get rid of the problem forever. The automatic text encoding recognition module is needed if you open files in Arabic in ANSI, but in reality you will never do this, since a Russian-speaking person has only Russian-language files on their computer. People who want to make the file available to all people on earth save the file in UTF-8 encoding and it will always open correctly for you. You don’t need automatic file recognition, as it’s only for local files that you’ll never get from someone else’s computer abroad. Отключи автоматической распознавание кодировки. Для русского языка в кодировке Windows-1251 автораспознавание всегда будет открываться как Macintosh. Если начать редактировать файлы, то у вас будет две кодировки, точнее мусор из двух кодировок, который будет трудно исправить вручную, так как вам придётся перечитать все тексты (это модуль для порчи файлов). Когда вы отключите автораспозначание кодировки, то у вас будет только ANSI, UTF-8, UTF-16. WindowsXP-7-8-10-11 всегда откроет файл ANSI правильно, в кодировке 1251, так как это кодировка по умолчанию. Остальные UTF-8 и прочие откроются также автоматически правильно. Вы навсегда избавитесь от проблемы. Модуль автоматического распознавания кодировки текста нужен если вы открываете файлы на арабском языке в ANSI, но в реальности вы никогда этого не сделаете, так как у русскоязычного человека на компьютере есть только русскоязычные файлы. Люди, которые хотят сделать файл доступным для всех людей на земле сохраняют файл в кодировке UTF-8 и он всегда откроется правильно у вас. Вам не нужно автоматическое распознавание файлов, так как оно только для локальных файлов, которые у вас никогда не появятся с чужого заграничного компьютера.

@Jeff-Esposito said in Notepad++ VERY slow to open: e gotten my new computer Notepad++ takes 40-50 seconds to launch. I have removed all plugins and don’t check recent file history at launch is checked. There are no open unsaved tabs, even though that is how I want to use it and use it on my old pc and my work laptop. the install It becomes slow when using “Show Folder As Workspace” (which displays the workspace folder on the left side). It starts quickly when this option is turned off.

Yeah, this usually happens with non-breaking spaces (U+00A0) or other Unicode space characters that look invisible but behave differently from normal spaces. Using \xA0 in regex was the right fix 👍 If you face this again, you can: Use \x{00A0} or \s to detect space variants Check in hex editor to identify exact character Then replace all in one go Also, if you’re unsure which invisible character it is, you can test different ones using tools like espaço invisível before applying them in your editor.

Honestly, this cleared up a big confusion for me. I used to think fonts were saved with the file itself, but it makes sense now that it’s just the editor displaying it differently. Also didn’t realize enabling global font overrides can mess with syntax highlighting—good catch. I’ve been tweaking text styles a lot lately while testing name formats on font generator, so this helps keep things consistent

@PeterJones That “Stopped working” is a common overall expression there for the app crashes, hungs etc. So @mapsonx should open that “details” you mentioned or simply launch the Windows EventViewer, i.e.: press WinKey+R to invoke the Windows Run-dialog copy & paste there: eventvwr.msc /c:"Application" and click OK wait for the Event Viewer launching and attaching to OS logs search/filter there for “Error” Level records (or simply follow the ReliabilityMonitor published date/time of the N++ problem), with “notepad++.exe” within app crashes usually have as log Source “Application Error”, frozen apps “Application Hang” Then publish here what the content of such a record tell us, e.g.: Faulting application name: notepad++.exe, version: 8.9.3.0, time stamp: 0x69bc8a94 Faulting module name: USER32.dll, version: 10.0.19041.6926, time stamp: 0xcd1afcbd Exception code: 0xc0000005 Fault offset: 0x00000000000467cd Faulting process id: 0x296c Faulting application start time: 0x01dcce3ba0a16cb7 Faulting application path: ...\npp.8.9.3.portable.x64\notepad++.exe Faulting module path: C:\Windows\System32\USER32.dll

@arnaud-derette said in Terminal window in a N++ tab: i think i get it : It does not handle correctly 4K screen. That does not surprise me. Notepad++ is still not great for high-DPI environments, and it’s been taking a long time to finish some of the last-remaining high-DPI issues. And if the main app, with lots of contributors, still has issues, then it should come as no surprise that the plugins, which usually only have one developer (if they remain interested), whose skillset usually focuses on the feature that their plugin implements, rather than on the generics of all the edge cases of modern win32 coding. (At least, I know that’s true for me on my plugin(s).) I don’t have a High-DPI environment, so I don’t know and can’t test for you, but maybe the NppExec plugin handles high-DPI better than NppConsole does (whether the original, or the intermediate fork)

@William-Fields said in Curse of the Curly Quotes: When pasting code into NP++ from another source, no matter what I do, if the source has curly quotes, the pasted content has curly quotes. Right. That’s because the curly quote characters have different codepoints from ASCII quotemarks. It’s doing the right thing. If you want to convert, then use a regular expression: FIND = [“”] REPLACE = " SEARCH MODE = Regular Expression REPLACE ALL change all curly quotes to straight quotes when opening documents or pasting content There’s no such command or option in Notepad++, because that would be Notepad++ changing characters from one codepoint to another without user interaction, which is the antithesis of text editing https://community.notepad-plus-plus.org/post/102348 The Direct Write ligature-effects from the post you showed is just the fonts changing the appearance of characters based on font ligature rules, but the underlying characters that Notepad++ is presenting are the exact same characters as found on disk. On the other hand, the curly quotes that you are copying and pasting are different characters from the ASCII quote.