Bracket matching causes the cursor to become misaligned in proportional font
-
Hello all,
I’ve been using NPP for a very long time, and this issue has always annoyed me, but I sort of learned to live with it. However, I’m starting to think it doesn’t affect others as I never see any mention of it.
When I place the cursor next to some brackets ( “(” or “{” or “[” etc.), the pair get highlighted, as per the feature in NPP. However, both brackets also move slightly to the right, and as a result the cursor no longer lines up with the insertion point in the text. So it becomes really difficult to see where you are typing.
When coding, it’s especially tricky. Eg. if I have this:
testFunction(){ ; do something }
and I put my cursor after the “)”, the “()” moves to the right, such that the “{” looks like it’s actually inside it!
This only happens with proportional fonts. Does anyone else see this?
TIA, WPB
-
Hello, W P Blatchley,
I can’t reproduce this behaviour with, either, a monospaced font or a proportional font !?
For instance, see that image, below :
Everything looks OK, isn’t it ?
Best Regards,
guy038
-
-
Hi, W P Blatchley,
I could open and see your image from the site imgur.com, without any trouble. Really amazing ! I don’t understand !?
However, I noticed that you’re using an User-Defined Language, named AutoHotKey
Could you, please, do this test, again, with the simple language Normal Text ? Is it OK or KO ?
As for me, in my previous test, my new 1 file was a Normal Text file, with the default UTF-8 encoding, so, without the invisible Byte Order Mark ( BOM ),
Cheers,
guy038
-
Happy to do that, but I don’t know how to set a proportional font in “Normal Text” mode. Do I have to use the Style Configurator?
-
Well, I don’t know exactly what’s happening, but I think I have some useful insight. You were right that the problem was tied to the UDL “AutoHotKey” (which is not authored by me). So I checked the XML file that defines that UDL, and noticed that every style in the <styles> section had a fontName specified, and that the font specified was not a font on my system.
In the “Define your language…” dialog within NPP, all the “Styler” buttons were leading to dialogs with “Font options” -> “Name” being blank, which I assumed to mean “use the default style”. However it appears that NPP is NOT using the default style when it doesn’t recognise the font specified in the XML file. Why or even if that leads to the strange bracket-matching behaviour above, I don’t know.
For now, I have removed those fontName specs from the AutoHotKey UDL on my system, and NPP now uses the default font as expected, so everything is fine.
I hope this information can help lead to the bug being tracked down.
WPB