@john-burr

In regular expression mode, \f will enter ASCII 12. So check the Search Mode = Regular Expression to get that behavior when you replace

mode before after normal 76faf0ba-02fe-4c8e-99d4-02983e04e63f-image.png 47b949a5-492d-48ae-8445-e41eb733d2f5-image.png extended 3f74a214-8b64-439d-ba5b-ecff837ab2b6-image.png 222327ea-62ae-430c-b4a4-03478d210938-image.png regular expression eec66efc-a0fa-4860-b31b-abc26bebc77b-image.png 7e62c935-8c72-47a5-983a-4d18d183cdd5-image.png

see:

https://npp-user-manual.org/docs/searching/#regular-expressions
https://npp-user-manual.org/docs/searching/#control-characters

Hello, @peterjones, @terry-R and All,

Peter, you said, in your last post :

the “length” field is the (equivalent) file size …

it’s quite a good approximation !

Here is what the length field, located in the status bar, represents, depending on the current encoding :

For an ANSI encoded file : the size of current file

For a UTF-8 encoded file : the size of current file

For a UTF-8 BOM encoded file : the size of current file - 3 bytes ( the BOM )

For a UTF-16 BE BOM encoded file : The displayed number is erroneous ! It should be the total number of characters of current file × 2 - 2 bytes ( The BOM )

For a UTF-16 LE BOM encoded file : The displayed number is erroneous ! It should be The total number of characters of current file × 2 - 2 bytes ( The BOM )

Remainders :

With the UTF-16 BE BOM or UTF-16 LE BOM encodings, do not use characters over the BMP ( so, with Unicode value > \x{FFFF} )

In this regard, the names of these two encodings is quite misnommed. We should roll back to the old N++ names of UCS-2 BE BOM and UCS-2 LE BOM

Indeed, in a true UTF-16 file, characters are coded with two bytes if its Unicode code-point is <= \x{FFFF} and coded with four bytes if its Unicode code-point is > \x{FFFF} ( using the two surrogate pairs )

While, in a UCS-2 file, characters are always coded with two bytes ( chars of the BMP only ) and the surrogate zone ( from D800 to DFFF ) is not used

In addition, for a UTF-16 BE BOM or UTF-16 BE BOM encoded file, N++ oddly displays, in the length zone, the bytes count as it were an UTF-8 encoded file :-((

The moral of this story is to stick to the UTF-8 encoding, in all circonstances !

Best Regards

guy038

@peterjones said in Weird behavior of the "In selection" option in "Search" dialogs:

I think Guy’s complaint is that in #2, Notepad++ doesn’t redo the selection-length calculation, even though the selection and length has changed and the FIND window has been re-opened.

OK, this makes this thread make sense to me now, and although it appears Guy and Peter have accepted this behavior, I guess we are calling it the “sticky” behavior, to me there are lingering bugs in the In selection logic as a whole. And I don’t buy into the “sticky” argument. :-)

I’ve spent the intervening time trying to do research on when the weird behavior with In selection first started, but I was unsuccessful in this search. I found some issues (e.g. 9611) but nothing that really satisfied.

For anyone who has a taskkill-based solution – either the Run command or a fancier PythonScript – you might want to add /F to make it a “stronger” kill. I have run across some circumstances (for example, for here where a normal kill wasn’t sufficient).

Edit: one downfall of the /F is that it will cause an “emergency exit”, so Notepad++ is not given a chance to save any settings (including recently-closed files). So only use the /F if you really need the extra power

@socu ,

It would make sense if there were an “accent-insensitive” flag in the standard regex engines, just like there’s “case-insensitive” flag. But no regex engine that I’ve ever used has had such a flag… Given that some of those engines have decades of development (for example, the Boost regex engine used by Notepad++ was derived from the PCRE engine, which had its roots in late-90s Perl regular expression), most of which has included knowing about Unicode, and the number of times I’ve seen “is there an accent-insensitive flag for regex-flavor-X” questions answered in the negative in programming forums, I would assume that if it were technically reasonable to be included, it would have been developed and included in the major ones by now. Given that it hasn’t been developed, I am assuming that’s because there’s a huge technical roadblock that’s beyond my pay grade to understand.

@peterjones
I checked the user manual and learned about the Notepad++'s specific environment variables, thank you for the reminder!

@markus-gaugg

It’s also in the source code, or in the User Manual’s “Usage via the command prompt”. With that, and the ability to copy the whole text directly, there is already a plethora of ways to get the text you want.

For a piece of text that almost never changes (as opposed to the Debug Info, which has dynamic info), I think that’s plenty of access (IMO, of course).

@dave-wilks ,

Install the PythonScript plugin, and search the forum for add_1 for examples of doing math on found numbers

@ralphw Just delete the Nativelang.xml file and restart the n++…

@rdipardo That worked!!! Thanks very much.

Hello, @dejoota, @terry-r and All,

@dejoota, I suppose that you just want to remove the messages in the last group of double quotes, don’t you ?

So, here are three regex S/R which achieve this goal. Now, whatever your choice :

Open the Replace dialog ( Ctrl + H )

Untick all options

Tick the Wrap around option

Click once on the Replace All button ( Do not use the Replace button if the regex contains a \K syntax )

Then :

If you want to remove, both, the portuguese and the english versions :

SEARCH (?-i)[^"]+(?="$)

REPLACE Leave EMPTY

So, from this INPUT text :

"npc_citizen.question00" "isto é um teste" "[english]npc_citizen.question00" "This is a test"

you’ll get this first OUTPUT text :

"npc_citizen.question00" "" "[english]npc_citizen.question00" ""

If you want to remove the portuguese version, only :

SEARCH (?-si)^(?="npc_citizen).+"\K[^"]+(?="$)

REPLACE Leave EMPTY

you’ll get this second OUTPUT text :

"npc_citizen.question00" "" "[english]npc_citizen.question00" "This is a test"

If you want to remove the english version, only :

SEARCH (?-si)^(?="\Q[english]\E).+"\K[^"]+(?="$)

REPLACE Leave EMPTY

you’ll get this third OUTPUT text :

"npc_citizen.question00" "isto é um teste" "[english]npc_citizen.question00" ""

Best Regards,

guy038

@dulce-gd

Without knowing where you downloaded which file, no one can check whether this is actually the case, which I doubt is the case anyway.

@michael-vincent said in Bug with annotations relating to z-order:

that actually isn’t an “annotation” in the sense of a Scintilla annotation

I was actually working on some script code that deals with annotations at the time I noticed that, so I guess that was on my mind. :-)

There also might be some nuggets HERE for someone with ambition and skills enough to “roll their own”.

@lavanyadeepak ,

What I can think of is that if Find in Files was running in another thread then the user could modify/delete files in parallel which would mess-up the ongoing search operation.

@rdipardo said in MIB file (SNMP) syntax highlighting [User Defined Language]:

This definitely won’t work:

That is why I said “test the lexing quality with old NPP version”.
if there is interest, I may invest the time. Or since the source code is available then maybe someone else will take over.

If everyone is happy with UDL, great.

Yes, I get it, it’s not an indentation bug, I must have done something wrong. :-)

So I’ll have to mess with it to see what I did wrong. I will try creating a user startup.py and put it where ever it goes (reading the instructions on file locations I have here somewhere), and remove it from the machine startup.py. This is kind of the thing, I know I’ve screwed it up somehow and I don’t understand the indentation rules for Python…I’m am only learning and dabbling at the moment, and indentation was never a critical part of any programming I’ve ever done, so it’s new to me. I’ll get it. Thanks for the pointers and the tests.

@joe-schmitz

No, this is not an error. Some files like xml or html sometimes provide a tag that Npp uses to identify the encoding. If this is not present or Npp does not know that it is an XML or HTML file, it tries to guess the encoding using the chardet module.
So it works as intended. By the way, in this particular case, ISO-8859-1 and your ANSI version (1252) are identical.

@alan-kilborn , thanks very much. This is exactly what I needed. Have a great day!