@Denislav-Dimitrov

Maybe you want one instance of Notepad++ per file? If so, change your shortcut or whatever you use to invoke Notepad++ to pass the -multInst parameter. That, with the addition of the hide-tabs configuration setting that has already been discussed, may achieve what you want.

@Jason-Low

It is a long-known issue that the “underlined key” mechanism in the Find family of windows is messed up. I’ve made it less of a problem I care about by reassigning a lot of the text in the Find windows to something “better” and I remap the keys in the process. This thread discusses how to do all of that if you are interested in doing something similar: https://notepad-plus-plus.org/community/topic/11041/new-alt-shortcuts-in-the-find-dialog-for-default-english-language)

not sure what the developers are thinking
this is a well know issue
set the default location for both options under Settings/Preferences/Backup
better to switch to some other editor

@Vasil-Georgiev

2 pieces of advice:

Hello, @shhlkien,

Claudia is right about it : your present version of the Monaco font cannot reproduce the glyph of the character ổ ( “LATIN SMALL LETTER O WITH CIRCUMFLEX AND HOOK ABOVE”, of Unicode code-point 1ED5 )

This character is part of the Unicode Latin Extended Additional block, which describe 256 characters, from Unicode code-point 1E00 to Unicode code-point 1EFF. Refer to the link, below, to get the complete list of these characters

http://www.unicode.org/charts/PDF/U1E00.pdf

Now, I found out, a nice monospaced font, named Monaco for Powerline, with Euro sign and slashed zero, proposed by Daniel Shæfer ( alias epegzz ), which works on Windows configurations and, probably, on OSX ones ! You can download it from the link, below :

https://gist.github.com/epegzz/1634235/raw/4691e901750591f9cab0b4ae8b7c0731ebf28cce/Monaco_Linux-Powerline.ttf

Consult, also, the page :

https://gist.github.com/epegzz/

Once this font installed, on your operating system, your text chào buổi sáng should be correctly displayed :-))

Only 10 characters, ( from 1E9C to 1E9F and from 1EFA to 1EFF ), out of the 256 characters, of the Latin Extended Additional block, do not have any glyph, with the Monaco for Powerline font. These are, principally, some medieval characters + the Latin Capital German letter Sharp S, of code 1E9E

Hope this post will help you !

Best Regards,

guy038

BTW, an issue was created for what I was just talking describing:
#3640 – Backward-direction checkbox enabled with Reg Exp search mode (at N++ startup)

…but discussion on it kind of got tied up with this issue:
#3533 – <<Find" (Find Previous) button is disabled for “Regular expression” search

…and sadly, none of this has gotten any attention to this point.

@David-Habier

I’m not 100% sure but I don’t think so. It’s been a while since I did automated installation for npp.
If the newer versions are still behaving the same then you might need to create links (hard-/soft-/junctions …) to achieve what you are looking for.

Cheers
Claudia

@ThosRTanner

did you see this?
Although not sure if this is related to your problem.
I’m not a java developer but as far as I understand jslint and jshint are tools for code quality assurance.
If so, you might be able to run the newer versions with nppexec plugin.

Cheers
Claudia

Isn’t that a browser problem?
I’m sure NPP can ‘read’ any file but the parsing is done in a web browser.
Or maybe I misunderstand your problem.

it works on any similar regex engine eg php functions like preg_match_all()

but you have to make sure to escape all characters that would be interpreted as a regex pattern part instead of a character you are searching for

eg: if you use / as a regex start and end delimiter character, you have to write \/ for every slash you want to find to make regex search for the character /

so /s/[0-9]+/1/ in a php example where you use / as regex start-end delimiters it has to be rewritten to:

or you can use a different delimiter character:

then if you search for the physical character # you’ll have to write \#

As I mentioned in another thread, my registry associates .txt with the HKCR\txtfile key; yours may be different: you can look in HKCR\.txt to determine the right association for your machine. Assuming my setup:

You’ll notice the three keys “open”, “print”, and “printto”: mine does not have an “edit” key. So if they are really using the hardcoded “edit” key, rather than the default action (listed here as HKCR\txtfile\shell:(Default)=open), then it’s a poor choice on their part, because there is no guarantee that the “edit” key exists for a given association on a given machine.

!!WARNING!! What I am about to explain involves editing the registry. This has associated risk, and should only be followed if you understand everything said, and are willing to take all responsibility for any change in behavior that occurs in your system. I make no guarantee or waranty regarding the effectiveness or safety of the following. (If your computer stops working, or doesn’t work the way you want it to, it’s not my fault.) Use at your own risk.

You may be able to work around their choice. Right click on shell, select New Key = edit. Right click on edit, select New Key = command. Left click on open > command, double click on (Default), and copy the path to NPP (if your default isn’t “open”, but some other key, then use the command from that key, instead); left click on edit > command, double click on (Default), and paste the path to NPP. Exit the registry editor. (Some people say that they need to reboot, or at least log out and back in, or perform other similar actions to make sure the registry has fully updated… but my guess is just closing the registry editor and closing/reopening the third-party program will be sufficient.) In general, this should create the new “edit” action, which will execute the same command that the “open” action executes.

@decoderman

It was before and i haven’t un-ticked it. No idea how it got un-ticked.

Anyway, thanks a lot for this. I really needed it sorted.
Have a great day!