Apparently, the background color for the current line takes precedence over the background color from a brace highlight. Is there a way to override this behavior?
Without the background color of a highlighted brace or parenthesis, it can be difficult to pick out which one is actually highlighted. Sometimes, a complex sequence of braces can all appear on one line, and it would be nice to be able to see the highlighted background color without having to turn off highlighting of the current line.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried using the latest version (5.2 Unicode). I have a dark blue background with a lighter blue current line background. I set the background for the brace highlight to grey, and when I moved the cursor next to a parentheses so that it would be highlighted, the current line had the lighter blue background, but the parentheses both had the light grey background, even though both were on the current line.
As for the highlighting of "Begin" and "End" for Pascal, the built-in languages are pretty inflexible and only allow for the changing of keywords really.
You could try making a user-defined language to imitate Pascal and try different settings to see if you can get the Begin and End to highlight.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm using N++ 5.3 Unicode, and have had the same issue with all previous versions that I can remember.
1/ In the C highighter, OPERATOR style has a green background.
2/ Just for testing, the Global Style -> Brace highlighting style has a yellow background.
3/ The current line uses a light blue background.
1/ shows in an edited C file outside the current line.
2/ doesn't show at all
3/ colors all the background on the current line.
Note that foreground colours on the current line are preserved; only the background attributes are cobberd.
CChris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was looking for something completely unrelated in scintilla.iface, and found something about the foreground highlighting clobbering style background rather than blending with it.
In Shortcuts.xml, I added the following, right after the definition for Trim Trailing and save macro:
Here:
* 45 is the code for the INS key, this can be changed at will using the Shortcut manager;
* 64 means the color of the current line background is 64/256 times the current line highlight color + (256-64)/256 times the style background color at each character.
* 2470 is the number of the SCI_SETCARETLINEBACKALPHA message. It is not listed in the shortcut mapper.
I found this to be much better visually. Of course you can always play around with various values for transparency.
The only inconvenience is that you have to execute the macro at startup. It could be nice to execute macros on any file open/file save. And you need one macro for each desired level of blending.
(btw I'm still looking for where the recognised values for the type attribute in saved shortcuts are documented)
CChris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> (btw I'm still looking for where the recognised values for the type attribute in saved shortcuts are documented)
Found how to use:
0 means send a message and don't use sParam. The message is any WM_ or SCI_ one.
1 is the same, but use sParam. When lParam points to a string, it needs to be serialised for output, and sParam then holds the string.
2 sends a command id as listed in menuCmdID.h. For instance, <type="2" message="43001" wParam="0" lParam="0" sParam="0"/> opens the Find dialog.
CChris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I also find it a problem that the current line highlighting clobbers the current syntax highlighting for that same line.
I'd suggest adding the following group of options in some preference tab:
<frame Current line>
<chkbox Enable current line marking/>
<!-- when unhecking this, all other in frame are inactive or hidden
-->
<chkbox Use color scheme/>
<chkbox Only highlight trailing whitespace/>
<!-- the latter checkbox is inactive/hidden on unchecking the one above
-->
<chkbox Show marker in front of current line/>
<chkbox Italicise line number for CL/>
</frame>
How about this? I tried to include all alternatives I could think of, perhaps some are not deemed useful.Hopefully the pseudo XML is clear enough.
CChris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Maybe its due to bad eyesight or something, but when I have black text with a light blue background for the active line (which I like), its hard to see a single parenthesis when it turns dark green (or dark red, or dark any color really).
Anyway I guess the point is, active line highlighting works on the entire line, its pretty obvious which line is currently active even if a parenthesis or two has a different background color. So I have a hard time understanding why active line highlighting takes precedence over matching brace highlighting (or at least why there isn't an option to choose).
On a side note, does anyone know if there's a configuration file that controls which characters are used for brace detection for a given language? I wanted to mess around with it and see if I could get highlighting for begin/end pairs in Pascal, among other things. I couldn't seem to find such a file after some looking. Is this hard-coded into the program?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> So I have a hard time understanding why active line highlighting takes precedence
> over matching brace highlighting (or at least why there isn't an option to choose).
I guess that's because it's never been a problem to anyone before and the coder didn't think of this while writing the particular piece of code for the active line.
> Is this hard-coded into the program?
Brace highlighting is only implemented for single characters as far as I know.
You will find a couple of matches when searching for them in the .xml files.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Apparently, the background color for the current line takes precedence over the background color from a brace highlight. Is there a way to override this behavior?
Without the background color of a highlighted brace or parenthesis, it can be difficult to pick out which one is actually highlighted. Sometimes, a complex sequence of braces can all appear on one line, and it would be nice to be able to see the highlighted background color without having to turn off highlighting of the current line.
What version of NP++ are you using?
I tried using the latest version (5.2 Unicode). I have a dark blue background with a lighter blue current line background. I set the background for the brace highlight to grey, and when I moved the cursor next to a parentheses so that it would be highlighted, the current line had the lighter blue background, but the parentheses both had the light grey background, even though both were on the current line.
As for the highlighting of "Begin" and "End" for Pascal, the built-in languages are pretty inflexible and only allow for the changing of keywords really.
You could try making a user-defined language to imitate Pascal and try different settings to see if you can get the Begin and End to highlight.
I'm using N++ 5.3 Unicode, and have had the same issue with all previous versions that I can remember.
1/ In the C highighter, OPERATOR style has a green background.
2/ Just for testing, the Global Style -> Brace highlighting style has a yellow background.
3/ The current line uses a light blue background.
1/ shows in an edited C file outside the current line.
2/ doesn't show at all
3/ colors all the background on the current line.
Note that foreground colours on the current line are preserved; only the background attributes are cobberd.
CChris
I was looking for something completely unrelated in scintilla.iface, and found something about the foreground highlighting clobbering style background rather than blending with it.
In Shortcuts.xml, I added the following, right after the definition for Trim Trailing and save macro:
<Macro name="test" Ctrl="yes" Alt="yes" Shift="no" Key="45">
<Action type="0" message="2470" wParam="64" lParam="0" sParam="" />
</Macro>
Here:
* 45 is the code for the INS key, this can be changed at will using the Shortcut manager;
* 64 means the color of the current line background is 64/256 times the current line highlight color + (256-64)/256 times the style background color at each character.
* 2470 is the number of the SCI_SETCARETLINEBACKALPHA message. It is not listed in the shortcut mapper.
I found this to be much better visually. Of course you can always play around with various values for transparency.
The only inconvenience is that you have to execute the macro at startup. It could be nice to execute macros on any file open/file save. And you need one macro for each desired level of blending.
(btw I'm still looking for where the recognised values for the type attribute in saved shortcuts are documented)
CChris
> (btw I'm still looking for where the recognised values for the type attribute in saved shortcuts are documented)
Found how to use:
0 means send a message and don't use sParam. The message is any WM_ or SCI_ one.
1 is the same, but use sParam. When lParam points to a string, it needs to be serialised for output, and sParam then holds the string.
2 sends a command id as listed in menuCmdID.h. For instance, <type="2" message="43001" wParam="0" lParam="0" sParam="0"/> opens the Find dialog.
CChris
Edit:
The example for opening the search dialog should read:
<type="2" message="0" wParam="43001" lParam="0" sParam="0"/>
Too bad I cannot eit the previous post.
CChris
You aren't helped by the foreground highlighting?
I also find it a problem that the current line highlighting clobbers the current syntax highlighting for that same line.
I'd suggest adding the following group of options in some preference tab:
<frame Current line>
<chkbox Enable current line marking/>
<!-- when unhecking this, all other in frame are inactive or hidden
-->
<chkbox Use color scheme/>
<chkbox Only highlight trailing whitespace/>
<!-- the latter checkbox is inactive/hidden on unchecking the one above
-->
<chkbox Show marker in front of current line/>
<chkbox Italicise line number for CL/>
</frame>
How about this? I tried to include all alternatives I could think of, perhaps some are not deemed useful.Hopefully the pseudo XML is clear enough.
CChris
Maybe its due to bad eyesight or something, but when I have black text with a light blue background for the active line (which I like), its hard to see a single parenthesis when it turns dark green (or dark red, or dark any color really).
Anyway I guess the point is, active line highlighting works on the entire line, its pretty obvious which line is currently active even if a parenthesis or two has a different background color. So I have a hard time understanding why active line highlighting takes precedence over matching brace highlighting (or at least why there isn't an option to choose).
On a side note, does anyone know if there's a configuration file that controls which characters are used for brace detection for a given language? I wanted to mess around with it and see if I could get highlighting for begin/end pairs in Pascal, among other things. I couldn't seem to find such a file after some looking. Is this hard-coded into the program?
> So I have a hard time understanding why active line highlighting takes precedence
> over matching brace highlighting (or at least why there isn't an option to choose).
I guess that's because it's never been a problem to anyone before and the coder didn't think of this while writing the particular piece of code for the active line.
> Is this hard-coded into the program?
Brace highlighting is only implemented for single characters as far as I know.
You will find a couple of matches when searching for them in the .xml files.