If one sets {} or () as folder opening / closing characters for a User Defined Language, though the folding is working, but the brace higlighting goes astray, displaying all braces as unmatched ones.
How can this issue be solved?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After examining the sources I have found the problem, and here it is a solution for that.
The problem: the LexUser.cxx uses different styles (SCE_USER_BLOCK_OPERATOR_OPEN and SCE_USER_BLOCK_OPERATOR_CLOSE) to mark the beginning and the ending of a block, but the BraceMatch function finds matches only with the same style.
I have changed the mask to STYLE_MAX in the LexUser and set the ..._OPERATOR_CLOSE constant to 44 (12 + 32), so it has the same lower 5 bits as the ..._OPEN value.
Now the BraceMatch masks the 6-8th bit, so it does not differentiate among the two SCE_USER_... but the folding routine does, making it possible to fold the text. One problem persists yet: the 6th bit represents an indicator, so we must set the indicators[0].style in ViewStyle.cxx to INDIC_HIDDEN (the program does not use indicators, so it is not harmful to change the code), and we can now use braces as folding characters with brace matching.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am having a similar problem, trying to set { and } for folder begin and end. It does fine identifying the {'s but NONE of the }'s are identified (even on line by iteself).
It't just the braces -- the preckets and parens work fine, and it identifies both sides.
I am using latest version of NPP 4.0.2.
Any suggestions?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
correction -- if I define the } as close first and then { as open -- then its oppisite -- it only sees the }'s and not the {'s. (Even if on line by itself etc.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry for so many posts - but one more question. How can i get it to "not care" if the { or } have stuff next to it. When it does notice them, it only notices if it has spaces or new lines on each side.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Correction once again -- i figured it out -- when I remove something from the operators list -- it doesn't "take" until I add something else to the list.
I was messing arround trying to add it to the operators list to see if it would get it to recognize the {}'s even though they had text next to them. In doing so, even after removing the last one fromthe operators list, it was still on there, until I added somthing else.
I tested by making my line comment char an operator, and all the comments when unstyled -- then took it off the operators list -- still unstyled -- as soon as I added a random other char as an operater, all mo comments where once again styled.
Probably a bug.
I would still like to know how to make it consider any { or } as a folder begin/end even if it has text like this
{Q1: [2/13
Do you want to........
!cat
(1) 1 yes
(2) 2 no}
Thanks in advance for any help!!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If one sets {} or () as folder opening / closing characters for a User Defined Language, though the folding is working, but the brace higlighting goes astray, displaying all braces as unmatched ones.
How can this issue be solved?
After examining the sources I have found the problem, and here it is a solution for that.
The problem: the LexUser.cxx uses different styles (SCE_USER_BLOCK_OPERATOR_OPEN and SCE_USER_BLOCK_OPERATOR_CLOSE) to mark the beginning and the ending of a block, but the BraceMatch function finds matches only with the same style.
I have changed the mask to STYLE_MAX in the LexUser and set the ..._OPERATOR_CLOSE constant to 44 (12 + 32), so it has the same lower 5 bits as the ..._OPEN value.
Now the BraceMatch masks the 6-8th bit, so it does not differentiate among the two SCE_USER_... but the folding routine does, making it possible to fold the text. One problem persists yet: the 6th bit represents an indicator, so we must set the indicators[0].style in ViewStyle.cxx to INDIC_HIDDEN (the program does not use indicators, so it is not harmful to change the code), and we can now use braces as folding characters with brace matching.
I am having a similar problem, trying to set { and } for folder begin and end. It does fine identifying the {'s but NONE of the }'s are identified (even on line by iteself).
It't just the braces -- the preckets and parens work fine, and it identifies both sides.
I am using latest version of NPP 4.0.2.
Any suggestions?
correction -- if I define the } as close first and then { as open -- then its oppisite -- it only sees the }'s and not the {'s. (Even if on line by itself etc.)
Sorry for so many posts - but one more question. How can i get it to "not care" if the { or } have stuff next to it. When it does notice them, it only notices if it has spaces or new lines on each side.
Correction once again -- i figured it out -- when I remove something from the operators list -- it doesn't "take" until I add something else to the list.
I was messing arround trying to add it to the operators list to see if it would get it to recognize the {}'s even though they had text next to them. In doing so, even after removing the last one fromthe operators list, it was still on there, until I added somthing else.
I tested by making my line comment char an operator, and all the comments when unstyled -- then took it off the operators list -- still unstyled -- as soon as I added a random other char as an operater, all mo comments where once again styled.
Probably a bug.
I would still like to know how to make it consider any { or } as a folder begin/end even if it has text like this
{Q1: [2/13
Do you want to........
!cat
(1) 1 yes
(2) 2 no}
Thanks in advance for any help!!