If your “blocks” are separated by a line break, you can use the commands:

SCI_PARADOWN Ctrl+] SCI_PARAUP Ctrl+[

as they navigate between paragraphs.

@Nicholas-Crabtree ,

I can only see them in HEX mode

Since you can only see them in HEX mode, that means Notepad++ is doing the right thing, and you don’t fully comprehend the meaning of what you are seeing in the HEX. Let me explain:

You don’t have the character Â, that’s just the first byte in a two-byte representation for certain characters. You have a properly-formed UTF-8 document, which when Notepad++ is reading it natively as text, it will interpret those two adjacent bytes as a single character – hence, in the text mode, Notepad++ is just showing the single character that it correctly interpreted those two bytes as.

For the UTF-8 encoding, the Unicode codepoints U+0080 - U+00BF are represented by the byte pairs 0xC2 0x80 through 0xC2 0xBF. You’ll notice that the second byte in the two-byte sequence is the same byte as the Unicode codepoint of the actual character. Thus, if you look at any character U+0080 - U+00BF in a HEX editor, where it’s showing you the hex of the bytes, and then interpreting those bytes as ANSI characters in the panel on the right, you will see  followed by the character you hoped would be there.

For example, the center character ¢ is U+00A2, which is represented in UTF-8 bytes as 0xC2 0xA2; when a HEX editor puts the ANSI representations to the right, it will show those two bytes as ¢, thus tricking you into thinking there is an extra character there. There isn’t. There is one character represented by two bytes.

(You actually have the oppsoite problem of a lot of people: a lot of people have malformed UTF-8 documents which Notepad++ mis-interprets as using an ANSI codepage, and so normal Notepad++ shows the two bytes of that single UTF-8 character as ¢. Yours is actually properly formed, so Notepad++ correctly interprets those two bytes together as representing ¢, so properly only shows the ¢ character. So congratulations on having a good file.)

If you were to somehow trick Notepad++ into deleting those  bytes, then you could maybe delete those bytes, but then Notepad++, and any other application that believes it is trying to read a UTF-8 file, would see the lone 0x80 - 0xBF bytes as malformed, broken UTF-8, and they would complain to you about bad file encoding or improper UTF-8 or similar. If I helped you do this, I would be helping you to break your UTF-8 encoding.

That said, if you are trying to convert a UTF-8 encoded file into a 256-codepoint ANSI character-set encoding, then you can do that on each fiile inside Notpead++: after loading the UTF-8 file (and seeing it say UTF-8 in the lower-right of the Notepad++ status bar), you could go to Encoding > Convert to ANSI to get Notepad++ to convert from UTF-8 to ANSI… and as long as all the non-ASCII Unicode characters in your UTF-8 file were also found in your default ANSI codepage (Windows 1252 is usually the default in US installations of Windows), the file would look the same, and once you save it, and look at it in any HEX editor, the HEX editor will only show one-byte-per-character, because that’s all that ANSI character sets use; however, any Unicode characters in your original file that aren’t in the active codepage will be converted irreversably into ?, so be forwarned that it’s an incredibly bad idea to do that conversion without a good understand of what characters are in your file and what characters are in your default codepage.

But the best advice: just leave the UTF-8 file as it is, because that’s a good, international, modern standard for text interchange, whereas the 256 character sets of the various ANSI codepages were a tolerable workaround in the 80s, but completely insufficient in the 2020s, and no modern tool should be forcing you into codepages instead of allowing UTF-8 encodings.

@Taras-Tkachenko ,
@PeterJones has been trying to help you, but you don’t seem to be able to be helped.

I downloaded version 8.5 32 bit:

Notepad++ v8.5 (32-bit) Build time : Mar 6 2023 - 02:15:26 Path : C:\Users\<username>\Documents\Development Tools Downloads\Notepad++ Versions\npp.8.5.portable\notepad++.exe Command Line : Admin mode : OFF Local Conf mode : ON Cloud Config : OFF OS Name : Windows 10 Home (64-bit) OS Version : 22H2 OS Build : 19045.5608 Current ANSI codepage : 1252 Plugins : mimeTools (2.9) NppConverter (4.5) NppExport (0.4)

And made my default file choice to be the D language, made a file, saved it. Created new, saved it, and in that directory was the other D file that I had just created. I shut down the application, came back, started a new document, saved it, and it too, defaulted to the same directory that my previous opened file was pointing to, and when I saved the newly created document, it too had the default extension of .d and the other .d files and only the other .d files were present in the dialog box.

I think you’re trolling, or lying. There is no forgetting. the file extension set from the Settings->Preferences...->New Document->Default language: dialog box selection area.

NPP85PrefDialog.PNG

From what I can see, you are not using the application properly, or not as you described. So unless you can take the time to properly describe EXACTLY what you are doing I don’t think @PeterJones or anyone else on here should bother giving you anymore suggestions until you stop with the vague decscriptions of your problem or the snide comments about a contributing forum member regardless of how you percieve their influence.

I tried doing the things you say, and unless you are Using the Open Files Dialog box like below, then yes, you will have the *.* file listing:

NPP85OpenDialogFilesList.PNG

And any file in there will be shown. If your directory only has the files you described in your use case, then those files will be there, only.

If you instead use the Save As Dialog, then the only thing you will see with the default file extension .d will be shown as this shows below:

NPP85SaveAsDialog.PNG

As you can see, only the files that you have saved with the same file extension will be in there. From my view, I’ve just done everything you said you couldn’t do. So which is it? Trolling, lying or is it just being purposely dense?

If someone offers you a way to do what you want, regardless of the way it is done, and seems like it’s too much trouble, then just say thank you for the effort, but it seems to difficult to do, or you’re too lazy to do it (I say that all the time about myself), but you’ll make a suggestion the proper way to the developers…and then move on. No need for the entitled attitude.

@Coises
sorry if I made a mistake in putting the photo on the site.

I converted the text as you told me everything and now it works perfectly, thank you, you were very kind, bye :)

@PeterJones said in Can I Insert Symbols using a Shortcut Keys, just like in MS Word ?:

I have script for the PythonScript plugin: pyscReplaceBackslashSequence.py, which I assign to Alt+\, which allows me to type something like \U+1F61E or \x{1F61E} or &#x1F61E; then hit my Alt+\ shortcut, and it will convert it from the codepoint / entity into the actual character (and it handles the surrogate pair calculation inside the script).

Another plugin with similar functionality and a quicker setup is HTML Tag.

Current versions can also (de/en)code Unicode scalars in the U+010000 to U+10FFFF range:

I can’t follow the connection between the question you asked and your screenshots.

I don’t understand why this happens. I have tried everything, it still highlights all English words and letters in red.

To the best of my knowledge, DSpellCheck has no way of knowing what language a given word is “supposed to” be in. If you say to spell-check in Russian, it’s going to highlight everything that isn’t a Russian word. If you want it not to highlight English words, then you have to include English as a dictionary.

If you expect it to somehow guess from your text which language it is in, and only spell-check when it is in Russian… I don’t think it can do that.

(Note to other readers: the original poster has also raised issue #359 in the GitHub repository for DSpellCheck, which might get more informed and useful responses.)

@PeterJones said in Where are new files (still unsaved by the user) stored?:

If you have Session Snapshot enabled

These settings I have:
alt text
https://i.imgur.com/yxx1Fhy.png

Again, I reiterate: new 1 being preserved has nothing to do with the X: drive (unless you have someone set up Notepad++ to use the X: drive for its preferences and backup folder).

Yes, I had understand. But I reiterate as well: if the back up file (without extension, with date, time being added) of new 1 is deleted when it is no longer available (e.g. when I close it in Notepad) and the same happens when new 1 is not available anymore because of the disconnected X: then, I would think, X: (indirectely) has to do with it (it is one cause (of maybe more / many for the issue) . Is probably a matter of interpretation, I guess, I understand what you mean. With the (new) setting on the screenshot it won’t happen again hopefully.

@unal-mk ,

I’ve never looked into the Ctrl+C behavior on NppExec. But there are some power-users of NppExec that sometimes read here, and even occasionally the author @Vitalii-Dovgan – so hopefully someone else will be able to help you with that.

@AUZAZURZ ,

Sorry, no.

Running the program in non-maximised window is not an option.

Bummmer, there goes my first idea for a workaround. Do you have a reason why?

here are some other potential workarounds:

You could try using View > Distraction Free mode (you can assign a keyboard shortcut to it in Shortcut Mapper if you are frequently doing that toggle).
a2393980-ca63-428e-9773-d0811dc4b7b5-image.png

Or maybe if you turned on the second View – create a new empty file, then View > Move/Clone Current Document > Move to Other View, after which Notepad++ should remember that you want two views open – then the second view could be resized enough that your primary editing view was narrow enough for you.
da314a65-7439-4f59-92cd-eae6ffc50483-image.png

@tom-p ,

Notepad++ is a text editor. To edit text, you open the file, then start typing.

The way you would make those changes in Notepad++ is the same way you would make those changes in any other text editor (assuming the changes can be made in a text editor), so there’s nothing that we can tell you that’s specific to Notepad++

This forum isn’t about “apex legends”, so we don’t know the specifics about what the syntax is or what config-file changes you need to make in order to change the config for those commands. You would have to ask in an “apex legends” forum to find out what files hold those settings, whether those files are text-editable, and what specific values you would need to edit to get the behavior you want. Such questions are completely off-topic for this Forum, because such questions have nothing to do with Notepad++, even if you happen to be using Notepad++ as your text editor. (If this wasn’t quite enough explanation for you, read our FAQ about why such questions are off topic.)

@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

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.