It’s not working because commentEnd must be non-blank if you want commentStart to work. If I set it to <Language name="batch" ext="bat cmd nt" commentLine="REM" commentStart="::" commentEnd="::REM">, save, exit, reload, then load a file in Batch, the Ctrl+Shift+Q will block-mode, where it puts :: at the beginning of the current selection and ::REM at the end of the current selection; but if I set commentEnd="", it will instead just use the commentLine for the block-comment commands as well, ignoring both commentStart and commentEnd. I tried some experiments, and even if you did something as simple as commentEnd=" " (where it uses a single space in the attribute value), it will use :: for the beginning and a space for the end.
But please note, if you do get it working that way: block comments are meant to allow for multi-line, and abusing cmd.exe’s label syntax (which is actually what :: is for) to be a pseudo-comment will not create a multi-line comment in cmd.exe syntax. It would just put :: at the beginning of the selection and whatever non-empty text you chose for the commentEnd at the end. Which means, if you have more than one line selected, only the first line would be commented out.
If you want to use :: as your line comment, then you should just change commentLine="::", and then line-comment will always use that (and block comments will instead apply the line-comment individually to all selected lines). But you cannot set it up in a way soas to have two different single-line comment syntaxes, as that is not how the comment-feature was designed.
(we literally just added the text These attributes can only define one type of line and block comments; if your language has multiple types of either, you will have to choose the _one_ type that you'd like Comment/Uncomment to work with. to the user manual: it hasn’t even had time to be released to the website yet. but it will be in the next revision of the website.)
You’re right, sir. I’ve heard about this before, and it seems to be a long-standing issue.
I just tried it again, and it doesn’t work.
A solution to this or additional information about why it works for some and not for others would be welcome.
Because they both indicate the same thing and are grammatically correct in this context, they are interchangeable. The phrase “opened files” has the past participle form of the verb “opened,” but the phrase “opened files” contains the adjective “opened.”
It’s in the Search menu, not the Edit menu. (probably in that menu because searching and marking and bookmarking are all intertwined in Notepad++, whereas coloring text has nothing to do with editing, because it doesn’t make changes to the file when saved)
In the start menu, you can make a new shortcut to notepad++ that runs it with the command line arguments -multiInst -nosession. When you click on that shortcut, it will open a new multi-instance window without the current session, but it won’t change the open-with-notepad++ behavior.
Non-multi-instance instances (like those opened with open-with) and those that open with a shortcut will confuse your settings, because depending on which one you exit last, it may save your settings in a state that doesn’t match what you want. This may or may not be what you want, though.
The e68c89 is the UTF-8 3-byte encoding for the one you have shown as 按 in the later example, so Notepad++ is doing the right thing with Unicode characters properly entered when Notepad++ believes it is in UTF-8 mode.
Though I just realized: do you think that typing 按 in Notepad++ will save the unicode character 按 in the bytes of the ini file? If you think that, you are sorely mistaken. Notepad++ saves the characters you type. And unlike HTML/XML, Notepad++ doesn’t translate XML/HTML entities into their actual characters when you save or display the file. So if your ini is really
Then you are getting exactly what you should: you typed a bunch of ascii characters, including ampersand, number sign, ex, six, three, zero, nine, semicolon, and that’s what your game is seeing.
looking again at your post, where you compare the failing screenshot with extra box bytes in the top screenshot, compared to the one below which seems to be correct where you give it enties, maybe you really did type the Chinese characters in the first example. So I crossed out the entity paragraph.
If your game isn’t really expecting the .ini file to be in UTF-8, or if it only believes it is UTF-8 if it has the BOM, you may need to change to Encoding > UTF-8-BOM instead of Encoding > UTF-8 to better convince your game to process the .ini file as UTF-8.
So, to sum up: most likely, either you don’t actually have Notepad++ editing in UTF-8 mode (in which case, you just need to change the encoding in Notepad++), or your game doesn’t recognize an .ini file as UTF-8 without the BOM (in which case, you need to change to UTF-8-BOM in Notepad++ so it saves the BOM character), or your game doesn’t accept UTF-8 for the .ini, despite your assertion that it does.