I don’t know how this was changed unless the default changed with an update…

No “default changed with an update”.

I know how it happened: You clicked on Wrap around and it became unticked. Next time, please analyze what you are doing before posting a complaint.

Kudos to donho for figuring out what your complaint actually was (I certainly couldn’t, from your description).

Find functionality: The Find dialog doesn’t work as well because now it always searches up or down and cannot search the entire document up/down using the find next button. The workaround is to use the “Find All in Current Document” button.

Make sure you’ve checked Wrap arround:

Find functionality: The Find dialog doesn’t work as well because now it always searches up or down and cannot search the entire document up/down using the find next button

So I’m trying to decipher what this is saying…with zero success.
Can you elaborate and clarify?
If a specific example with real text helps, by all means present that.

1. Find functionality: The Find dialog doesn’t work as well because now it always searches up or down and cannot search the entire document up/down using the find next button. The workaround is to use the “Find All in Current Document” button.
2. This issue seems to be tied to the add-in “3P - Progress Programmers Pal”
   Auto-completion text seems to terribly bog down the CPU on my computer, even though it is a relatively powerful computer (Dell for Engineering Design). This only started after upgrading to v8.4.4.

I don’t remember the exact version that I was using prior but highly likely to be the last stable version as I update every time the dialog appears.

Debug Info:
Notepad++ v8.4.4 (64-bit)
Build time : Jul 15 2022 - 17:54:42
Path : C:\Program Files\Notepad++\notepad++.exe
Command Line : “C:\Users\lhs\Downloads_Username.txt”
Admin mode : OFF
Local Conf mode : OFF
Cloud Config : C:\Users\lhs\OneDrive - HydraForce Inc\Documents\Notepad++ customizations
OS Name : Windows 10 Pro (64-bit)
OS Version : 21H2
OS Build : 19044.1889
Current ANSI codepage : 1252
Plugins :
3P (1.8.8)
ComparePlugin (2.0.2)
Explorer (1.9.5)
mimeTools (2.8)
NppConverter (4.4)
NppExport (0.4)

I’d suppose THIS is your problem.

Before it was like this:

Stale or invalid config files are a pretty consistent source of crashes; some recent examples:

NPP crashes on opening Style Configurator if stylers do not exist
NPP crashes on opening a session file
Application does not start (severe bug)

The 3 above issues are fixed to me. If not, please comment on the issue by providing the instructions for reproduce the bugs.

Otherwise, please stop misleading users with your ambiguous comments.

The directory referenced does not exist

Unfortunately N++ doesn’t know any better than to try accessing the non-existent icons. A null pointer dereference would explain the crash.

Stale or invalid config files are a pretty consistent source of crashes; some recent examples:

• NPP crashes on opening Style Configurator if stylers do not exist
• NPP crashes on opening a session file
• Application does not start (severe bug)
• . . .

I have stopped working with code years ago, but still use N++ as my normal text editor. I don’t edit text files much, though.

A few weeks ago I attempted an auto-update. Afterwards, N++ would immediately crash upon attempting to use it. I finally got around to debugging the issue.

Long story short, the crash is triggered by the presence of toolbarIcons.xml in the %appdata%\Notepad++ directory. The date on the file is March 28, 2006. Evidently this file is from a very old version of Notepad++. I can recall some issue with tool bar icons many years ago but don’t remember any details. Anyway, the presence of the file causes all versions of N++ starting with 8.4.2 to crash.

I will copy the beginning of the file below. The directory referenced does not exist on my computer.

<?xml version="1.0" encoding="Windows-1252" ?>
<NotepadPlus>
    <ToolBarIcons>
	    <!-- the value pathPrefix should be the path where you can find all icons -->
		<Theme name = "Crystal++" pathPrefix = "D:\Program Files\Accessories\Notepad++\NppCrystalToolbarIcons\Icons\">
			<Icon name = "new" id = "0">
				<normal>new_normal.ico</normal>
				<hover>new_hover.ico</hover>
			</Icon>
			<Icon name = "open" id = "1">
				<normal>fileopen_normal.ico</normal>
				<hover>fileopen_hover.ico</hover>
			</Icon>

Sometimes I use Notepad++ to edit long plain text files (not code) and I need a way to mark where the page breaks are. How hard would it be to add the capability to highlight line numbers (e.g., put a dot next to 64, 128, 192, etc.)? Or is there a plugin that already adds this capability?

The thread you posted this in is intended to be reserved for critical problems with the titular release, not “general questions” like you asked; please create a new thread and repeat your question there.

Thanks.

Possibly see HERE.

https://github.com/notepad-plus-plus/notepad-plus-plus/issues/11995

@donho & @SeagramFR,

https://github.com/notepad-plus-plus/notepad-plus-plus/issues/11996

Not being able to edit posts here is slightly inconvenient.
I’ve preferred opening new issues on GitHub.

Thank you for providing the step by step instruction. However, I can’t still reproduce it by following your instructions:

@Yaron
Can you reproduce it in your PC?

@Not-Saying

Thank you for your debug info (via the private message).
However, I cannot reproduce the bug at all.
Could you provide the step by step instructions please?

Sure! I just figured out a way to do it again:

1. Do a Find In Files search for something you know won’t be found.
2. Do a Find In Files search for something you know will find multiple files.
3. Do a Find In Files search for something you know won’t be found.
4. Do a Find In Files search for something you know will find multiple files.
5. Observe there are no open/close icons for the results that found no files.
6. Collapse all the results.
7. Delete the result from step 3 (Delete key).
8. You now have the result I described above.

I can tell from the repro steps and gui behavior this is going to be obnoxious to solve. You’ve got two sets of objects, one that describe the gui state and the other the results. They are out of sync with each other. :(

Thank you for confirming.

just the kind I am the only one in the world to detect

The universe is grateful. :)

After changing the display scale from 150% back to 100%, then the document map was showing normally.
But scale =150% was very common on 4K screen.