@fml2 said in Jumping between matching brackets is not idempotent:

Is it the intended behaviour of Notepad++?

That’s kind of the edge case condition, which probably wasn’t thought about too much. Notepad++ intentionally designed the brace matching so that whether your caret was on the left or the right of the brace-type character, when it went to the matching pair, it always puts the caret before that character. But that means when it gets moved between the two different opening braces, it’s before one and after the other… and because Notepad++ is processing the bytes in the order it finds them (ie, in Western cases where N++ works best, left-to-right), that means that it notices the caret is after the first brace, before it has a chance to notice it’s also before the second brace.

If you have the brace-highlighting turned on, you can tell which brace-pair Notepad++ thinks your caret position is associated with by which are highlighted. Here are screenshots of the highlights for each of the brace-adjacent caret positions, from left to right:

6eb029a2-9ef2-4f23-b3ca-eb2fefa57e68-image.png df0226af-4f73-4494-b88e-ab443d200194-image.png 8b20bba2-5e3e-4660-b49a-3fd46e834261-image.png f07cb269-31f9-4664-b625-5b2cea433edb-image.png 97c5bec2-e46b-4468-92b3-c24257c621c6-image.png 84eeb00a-aeca-48be-b61a-f2792897a78f-image.png 5fd69989-c036-4500-be55-abb337a03df4-image.png

Because 4 and 5 both highlight the inner (...). the brace-match from there will take you to the before the opening (, at condition 2. But in condition 2, the pair that Notepad++ sees as active is [...], so the brace match from there will take you to condition 6, and from 6 will go to 1 (because it’s before the [)

The behavior borders on a bug… but I’m not sure there’s 100% agreement on which pair should be active and where the brace match should go in each condition, and thus I don’t know that it makes more sense to confuse people by “fixing” it to your interpretation, when it would then subvert years of expected Notepad++ behavior.

@Eric-Wiseman said in Bug in sorting lines, staying there for years:

Line Operations -> Sort lines works ONLY if you convert Edit -> EOL Conversion ->Unix.

Unless I am missing something this looks like a bug…

Correction: Edit > Line Operations > Sort … commands work ONLY if you have consistent EOL, whether it is consistently Unix (LF), consistently Mac (CR), or consistently Windows (CRLF). There are multiple Issues in the official issue repository for this (the most recent of which is #17251).

You can try the experiment yourself: do the Edit > EOL Conversion to Unix, then back to Windows CRLF, and you will see that you can still sort correctly, so it’s obviously not anything unique about the Unix line ending.

And if you look at the original version of your file where sort didn’t work right away, and use View > Show Symbol > Show End of Line, you will see that one of more of the lines that didn’t sort correctly have a different line ending than the one shown in the status bar (like the image @mpheath posted in this comment on issue #17251)

Mismatched line endings are evil, and if you have some other application that is creating a file that has them, it needs to be reported to the maker of that software as a bug. And until that end of the process is fixed, you can use Notepad++ to convert the EOL twice (once to something other than Windows EOL, then a second time to get back to Windows EOL) to get consistent line endings.

@Dan-Walter-0 said in Networking problem:

Before I open a ticket with my helpdesk, I want to know if there is anything I am missing on the application configuruation level.

From your N++ DebugInfo, I think not.

But could you 1st follow the instructions in my linked issue and paste here the nppLogNetworkDriveIssue.log obtained?

@PeterJones this worked perfectly! Thank you very much