@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!

Need to have a closing php tag in the file for the function list to work…

?>

Minor thing that caused a lot of pain…

The phrasing I am considering for the user manual:

issue #349 => PR #350

It should be in the next release of the user manual