@Hunder-Lily ,

I don’t know whether this was a serious post, or whether it was just an attempt to spam the Forum with a video game link because the previous post from 2021 had been a spam to some other site (but not deleted, because the moderators back then weren’t as aggressive at anti-spam as we are now; I have rectified that).

Just so you know, links irrelevant to Notepad++ and the on-topic discussion are not allowed in this forum (especially from brand-new users)

However, if you are serious in this reply nearly 4 years after the discussion ended: Picture this: you are editing your complex code, and instead of closing the Search Results panel, you just click back into your code’s text panel – the same way you would if you were going to be typing new text – and suddenly, F3 goes back to finding the next match, the way you expect it to. It’s almost like Notepad++ (like every other text/code editing app I’ve ever used) is designed to have the keyboard shortcuts apply to the tab or panel that currently has focus. When you think of it that way, Notepad++ is behaving quite sensibly.

Besides, if you are dealing with the Search Results from the Search Results window, then instead of doing an F3 (Find Next), which performs a new search from the current location, you should be using F4 (Next Search Result), which will move you to the next result in the active Search Results – and the F4 key, since it’s dealing with the Search Results, works whether your focus is currently in the Search Results panel or in the file-editing tab panel instead.

And if you, like the original poster, were talking about the Find dialog itself, then you can either move the focus from the dialog to the editing tab, or you can use ENTER (like @Alan-Kilborn suggested 4 years ago)

To sum up:

If you want to deal with the recent results in the Search Results window, then F4 will move to the next result whether you have focus in the text-editing tab or in the Search Results window, If you want to deal with doing a fresh search with the most recent search expression (for example, if the contents of the file have changed recently), then F3 will work if the editing tab has the focus; and if the editing tab doesn’t have the focus (either because focus is in the Search Results or in the FIND dialog or in some other panel), then all you have to do is switch the focus back to the editing tab before hitting F3, and the focus will stay there through subsequent uses of F3. None of these options require closing the Search Results panel nor the FIND dialog box, despite the claims to the contrary.

@Sanane-Kurt ,

I am coding and it always stays in Korean. I have a Turkish character problem. Every time I open a new txt or a new c++ file, I have to select Turkish windows-1254 from the coding. After editing is finished, when I click save, it starts in Korean again. What is the solution for this? It does not stay in the coding language I set?

Notepad++ has a feature where it can try to guess the encoding; unfortunately, there is NO reliable way, by looking at the bytes of a Windows text file, to tell for sure what the encoding of the file is – the best any program can do is to guess, and it sometimes gets it wrong.

Settings > Preferences > MISC > ☐ Autodetect character encoding controls that behavior. If it’s not on, you might see if turning it on helps Notepad++ to guess properly. If it is on, then Notepad++ is not guessing properly, so try turning it off; you might also need to make sure that Settings > Preferences > New Document > Encoding is set to your Windows-1254 encoding.

But neither setting is a guarantee that Notepad++ will guess correctly. The fundamental problem is that when the DOS filesystem (FAT) was being decided upon in the 80s, they didn’t bother storing meta-information about file encoding and the like, and that decision from 45 years ago propagated to the FAT32 (USB drives) and NTFS (modern Windows filesystem) as well. Because that metadata isn’t included, there is no way for any application to know for sure, and there’s nothing Notepad++ can do about the underlying filesystem.

That said, in the 90s, this cool thing called “Unicode” was invented, along with the UTF-8 encoding, which can, with a single file encoding, represent more than 1,000,000 characters.

Notepad++ supports UTF-8 encoding (and the related UTF-16 encodings), which give you full access to Unicode. If you were just using the files in Notepad++, there is no reason to use any non-Unicode encoding (like Windows-1254), because UTF-8 will represent all the Turkish characters and all the Korean characters separately, without ambiguity, so there would never be any conflict. Further, you say you are “coding”, and I haven’t heard of any modern compiler that would understand a 256-character encoding like Windows-1254 but not also handle UTF-8. If you do everything in UTF-8, there will be no difficulty with encoding.

@Coises
Thanks much Coises, dang too easy to overlook a simple space, its almost like trying to figure out a sound problem when it was the mute button that was hit.
Thanks again

Some related discussions, in these topics:

https://community.notepad-plus-plus.org/topic/20008 https://community.notepad-plus-plus.org/topic/19395 https://community.notepad-plus-plus.org/topic/20319

It’s a pity that there is no such functionality for subsequent instances :(

Thank you both!

Hi, @benji2025, @ekopalypse, @alan-kilborn, @coises and All,

I did additional tests :

First, if the Word wrap option is enabled, using the same regex as before, with the Match Case option checked, the BookMarking operation took about the same time : 23.2 seconds

Secondly, after the BookMarking operation if you re-run the same regex, the whole operation is done in 16 seconds. This seems logical because n++ does not have to re-bookmark the already bookmarked lines !

Thirdly, if I do not check the Bookmark line option, in the Mark dialog, the Marking operation is a bit quicker : 19,4 seconds

Fourthly, if I select all the contents of the test file ( => the In selection box is automatically checked ) the operation is a bit slower : 23,8 seconds

Now, for all the tests below, I used these rules :

The Word wrap option is unchecked

In the Mark dialog, the Bookmark line option is checked and all the other box options are unchecked.

Generally the Match case option is unchecked but may be checked in few occasions.

Before each search, I hit the Clear all marks button and place the caret at the very beginning of the test file.

I did my tests twice : on my old XP machine, with N++ v7.9.2 and on my new W10 laptop, with N++ v8.7.6 ( @coises, I avoided, on purpose, using the v8.7.8 and v8.7.9 releases ! )

Each time, I opened N++, from a command prompt window, with the command Notepad++ -nosession Benji.txt Test_Benji.txt, so with only these two files.

For the W10 test, I simply used an USB key containing the portable N++ v8.7.6 release and the test file.

-------------------------- NEC XP - N++ v7.9.2 ------------------------------------------------------------------------------------------------------- (?-s)^.*\R(?=TEST$) 24 s Option 'Match Case' unchecked (?-s)^.*\R(?=TEST$) 23.1 s Option 'Match Case' checked ( The test in my **previous** post ) (?-s)^.+\R(?=TEST$) 23.9 s Option 'Match Case' unchecked (?-s)^.*+\R(?=TEST$) 19.9 s ( Atomic ) Option 'Match Case' unchecked (?-s)^.++\R(?=TEST$) 19.8 s ( Atomic ) Option 'Match Case' unchecked (?-s)^.++\r\n(?=TEST$) 18.6 s ( Atomic ) Option 'Match Case' unchecked (?-s)^.++\r\n(?=TEST$) 17.7 s ( Atomic ) Option 'Match Case' checked (?-is)^.++\r\n(?=TEST$) 69 s ( Atomic ) ( ?! ) Option 'Match Case' unchecked --- Without the ^ symbol --- (?-s).*\R(?=TEST$) 25.6 s Option 'Match Case' unchecked (?-s).+\R(?=TEST$) 23.1 s Option 'Match Case' unchecked (?-s).*+\R(?=TEST$) 21.5 s ( Atomic ) Option 'Match Case' unchecked (?-s).++\R(?=TEST$) 19.2 s ( Atomic ) Option 'Match Case' unchecked (?-s).++\r\n(?=TEST$) 18.1 s ( Atomic ) Option 'Match Case' unchecked (?-s).++\r\n(?=TEST$) 17.25 s ( Atomic ) Option 'Match Case' checked (?-is).++\r\n(?=TEST$) 237 s ( Atomic ) ( ?! ) Option 'Match Case' unchecked --- Without the (?-s)^ part --- .*\R(?=TEST$) 25.1 s Option 'Match Case' unchecked .+\R(?=TEST$) 22.8 s Option 'Match Case' unchecked .*+\R(?=TEST$) 21.2 s ( Atomic ) Option 'Match Case' unchecked .++\R(?=TEST$) 18.9 s ( Atomic ) Option 'Match Case' unchecked .++\r\n(?=TEST$) 17.8 s ( Atomic ) Option 'Match Case' unchecked .++\r\n(?=TEST$) 17 s ( Atomic ) Option 'Match Case' checked (?-i).++\r\n(?=TEST$) 236 s ( Atomic ) ( ?! ) Option 'Match Case' unchecked --- Using the @Terry-R solution --- (?-s).\R(?=TEST$) 77 s ( ?! ) Option 'Match Case' unchecked (?-s).\r\n(?=TEST$) 71 s ( ?! ) Option 'Match Case' unchecked (?-s).{1}+\R(?=TEST$) 93 s ( Atomic ) ( ?! ) Option 'Match Case' unchecked (?-s).{1}+\r\n(?=TEST$) 84 s ( Atomic ) ( ?! ) Option 'Match Case' unchecked .{1}+\R(?=TEST$) 88 s ( Atomic ) ( ?! ) Option 'Match Case' unchecked .{1}+\r\n(?=TEST$) 79 s ( Atomic ) ( ?! ) Option 'Match Case' unchecked --- After CONCATENATION of the line BEFORE the line TEST with the line TEST --- First, the regex \R(?=TEST$) is replaced with NOTHING ( 57 s ) => 142,908,950 bytes for 3,030,301 lines. Then : TEST$ 20.8 s Option 'Match Case' unchecked TEST$ 13.6 s Option 'Match Case' checked (?-i)TEST$ 13.8 s Option 'Match Case' unchecked Last, the regex TEST$ is replaced with \r\n$0 ( 65 s ) -------------------------- HP Win 10 - N++ 8.7.6 ----------------------------------------------------------------------------------------------------- (?-s)^.*\R(?=TEST$) 2,3 s Option 'Match Case' unchecked (?-s)^.*\R(?=TEST$) 2 s Option 'Match Case' checked ( The test in my **previous** post ) (?-s)^.+\R(?=TEST$) 2.3 s Option 'Match Case' unchecked (?-s)^.*+\R(?=TEST$) 1.9 s ( Atomic ) Option 'Match Case' unchecked (?-s)^.++\R(?=TEST$) 1.97 s ( Atomic ) Option 'Match Case' unchecked (?-s)^.++\r\n(?=TEST$) 1.86 s ( Atomic ) Option 'Match Case' unchecked (?-s)^.++\r\n(?=TEST$) 1.5 s ( Atomic ) Option 'Match Case' checked (?-is)^.++\r\n(?=TEST$) 5.8 s ( Atomic ) ( ! ) Option 'Match Case' unchecked --- --- Without the ^ symbol --- (?-s).*\R(?=TEST$) 2.7 s Option 'Match Case' unchecked (?-s).+\R(?=TEST$) 2.3 s Option 'Match Case' unchecked (?-s).*+\R(?=TEST$) 2.3 s ( Atomic ) Option 'Match Case' unchecked (?-s).++\R(?=TEST$) 1.9 s ( Atomic ) Option 'Match Case' unchecked (?-s).++\r\n(?=TEST$) 1.8 s ( Atomic ) Option 'Match Case' unchecked (?-s).++\r\n(?=TEST$) 1.45 s ( Atomic ) Option 'Match Case' checked (?-is).++\r\n(?=TEST$) 23.9 s ( Atomic ) ( !? ) Option 'Match Case' unchecked --- --- Without the (?-s)^ part --- .*\R(?=TEST$) 2.7 s Option 'Match Case' unchecked .+\R(?=TEST$) 2.23 s Option 'Match Case' unchecked .*+\R(?=TEST$) 2.23 s ( Atomic ) Option 'Match Case' unchecked .++\R(?=TEST$) 1.8 s ( Atomic ) Option 'Match Case' unchecked .++\r\n(?=TEST$) 1.7 s ( Atomic ) Option 'Match Case' unchecked .++\r\n(?=TEST$) 1.38 s ( Atomic ) Option 'Match Case' checked (?-i).++\r\n(?=TEST$) 24 s ( Atomic ) ( ?! ) Option 'Match Case' unchecked --- Using the @Terry-R solution --- (?-s).\R(?=TEST$) 6.35 s ( ! ) Option 'Match Case' unchecked (?-s).\r\n(?=TEST$) 8.6 s ( ! ) Option 'Match Case' unchecked (?-s).{1}+\R(?=TEST$) 8.2 s ( Atomic ) ( ! ) Option 'Match Case' unchecked (?-s).{1}+\r\n(?=TEST$) 10.6 s ( Atomic ) ( ! ) Option 'Match Case' unchecked .{1}+\R(?=TEST$) 7.5 s ( Atomic ) ( ! ) Option 'Match Case' unchecked .{1}+\r\n(?=TEST$) 9.75 s ( Atomic ) ( ! ) Option 'Match Case' unchecked --- After CONCATENATION of the line BEFORE the line TEST with the line TEST --- First, the regex \R(?=TEST$) is replaced with NOTHING ( 26.2 s ) => 142,908,950 bytes for 3,030,301 lines. Then : TEST$ 2.3 s Option 'Match Case' unchecked TEST$ 0.95 s Option 'Match Case' checked (?-i)TEST$ 1 s Option 'Match Case' unchecked Last, the regex TEST$ is replaced with \r\n$0 ( 25.3 s )

Conclusion :

So, given the rules above, the best syntaxes seem to be, on my new Windos 10 machine :

The regex .++\r\n(?=TEST$) in 1.38 second, with the Match Case option checked.

The regex TEST$ in 0.95 second, AFTER an initial contatenation of the line before the line TEST with the line TEST.

Best Regards,

guy038

@Terry-R said in Replace many letters at same time.:

\U\1.

0d85b100-3221-4b17-b06e-1348e613198e-image.png

Its perfect!!

Thank u very much Sir!!!

Claudio Raphael

Hi, @dev-petty, @peterjones, @terry-r and All,

Yes I was too rapid, directly answering, without testing in N++. My bad !

So one correct syntax could be :

SEARCH (?s-i)(?-s:^Born:.+).+?California\R

REPLACE Leave EMPTY

Check the Regular expression search mode

What means this regex, except for the literal strings Born: and California ?

The first part (?s-i) are initial modifiers which apply to the whole regex :

The (?s) syntax means that any . regex char, found in the regex, may represent any single character, including the line-break \r and/or \n.

The (?-i) syntax means that the search is done in an sensitive way ( so not insensitive ! ). Thus it will find the words Born and California but not the words born and california or BORN and CALIFORNIA. If an insensitive search is needed just use the (?si) syntax.

The second part is (?-s:^Born:.+) which is a non-capturing group ( a group whose we do not need the contents, further on, in search and/or replacement !) (?:.........) with the -s modifier which applies to this group only. Thus, this part looks for the word Born, with that exact case, at the beginning of line ^, followed with a colon, itself followed with any standard character ., repeated +, till the very end of current line as it stops at the line-breaks.

The third part is .+? which represents the smallest ? range of any character ., including \r and \r, repeated +, until …

The fourth part California\R which represents the word California, with this exact case, followed by \R which stands for any kind of line-break ( \r\n for Windows files, \n for Unix files or \r for Mac files ).

In replacement, as its zone is empty, the entire 4 lines matched are simply deleted !

BR

BR

guy038

@PeterJones Thanx very much for your help

@PeterJones said in "Word wrap" option is reset from time to time:

Thanks for that brutally harsh assessment of my writing

I can see why you interpreted my general statement this way, and I apologize for any disrespect you felt as a result of that misunderstanding. However, I was not trying to imply anything negative about your general capabilities as a writer, or suggest that this particular piece of writing was unacceptable; I was just trying to make a point about the flaws/limitations of AK’s preceding comment.

FWIW, AK’s argument actually made me think of the various instructors I had in undergrad: despite their in-depth knowledge of the course material, many of them lacked the technical communication skills to provide effective lessons.

FWIW, I generally find your explanations on this forum exceptionally clear and easy to read, so I was surprised that this particular excerpt was a bit hard to follow on the first couple of run-throughs.

@PeterJones said in "Word wrap" option is reset from time to time:

you need to understand that (…) you do not get the final say into what’s accepted into the User Manual

Of course - that’s why I literally offered the adjustments as suggestions. However, I think it’s worth pointing out that someone else independently offered very similar suggestions (albeit for a potentially different piece of writing). The fact that two independent sources are suggesting the use of the same argument structure is a strong indication that the structure is worth following.

BTW, based on your multiple references to professional editors, you seem to be under the impression that I lack the experience required to give advice on writing structure. Given that you don’t know me personally, I’m not sure why you would make such an assumption; based on your other interactions on this forum, this seems out of character for you.

Either way, it’s worth pointing out that part of my current job is reviewing the content of user manuals, and I’ve had plenty of similar experience long before I took on this job. So, I’m much more qualified to offer advice on matters like this than you seem to think.

@Graz-Font I solved it. I edited the Windows registry to add a “MultipleInvokePromptMinimum” entry. Thanks to all for the suggestions, but it wasn’t a character length issue.

@Real-Cat

There is another post similar in request to yours which might help.

See this post.

Terry

@Juan-Fco-Rubio-Diaz

No solution.
Notepad++ 's limited development team hasn’t tackled this particular problem yet.
There are already official “issues” open for it.

actually I think they’re only two: config xml and shortcuts.xml,

If used, there is also toolbarIcons.xml and overrideMap.xml

@Maxim-Fox ,

config.xml for the settings, and stylers.xml for the default theme (other themes are in the themes subdirectory, and should be obvious based on which theme you use)

see User Manual > Config Files
https://npp-user-manual.org/docs/config-files/

@n3tcom said in Vertical tabs with horizontal text?:

PLEASE consider proper vertical tabs! The current “feature” feels like it was implemented as a troll to everyone that bothered asking for proper vertical tabs over the years

The readers of this post are users of Notepad++, not the Developer of the app. See our FAQ

it blow my mind that we still do not have this in 2025

Easily explainable if no one has officially requested it, and/or if the developer never thought of it, was never interested in it, or believes that the Document List feature is close enough.

@n3tcom said:

so the best we get across most of the better note apps is this repurposed function list solution

And so you yearn for something better?
I’m not sure what form that would take, as the function-list solution works reasonably.

@mkupper said:

…so pours a glass of wine while chatting about IPA…

@guy038 has always been really good at answering the question that wasn’t asked. It’s not a bad thing, as usually an increase in general knowledge results. :-)