As someone posted recently, I would also like to see the custom highlighting, improved in a few ways** - though I can understand why this would not be a high priority. So I just want to ask a few questions, to try to get the most I can out of what’s already there.
First I just want to verify there is no way to do a couple things, as it is:
-Use regex's or wild cards in keywords. (I know there is a prefix checkbox that treats all of that group as prefix's)
-Define a delimited range, where the range has to start with a combo of two characters. (i.e. has to start with "\:" and ends with ":" -- ":" is used elsewhere without a second one so I cant just make it ":" and ":")
-Make a certain keyword group, only valid if preceded by an operator, so if it's preceded by a space, it will be ignored.
-A way to define certain operators as escapes within a delimiter range.
If any of the above are currently possible please let me know. Because I'm under the impression they definitely can't.
Also -- Is it possible to define more groups of keywords. (like is there a file i could edit by hand, and just follow the layout of the file, and add a "group5=" or whatever the layout is?
Do the syntax highlighting scheme's for the built lang's (like perl) use the same set up as the user defined syntax highlighting? That is to say -- would it be possible to create, with the custom syntax highlighter, a highlighting scheme that would work identically, to one of the included highlighters?
And if so, (or either way really) is there a file I can look at to see how the included highlighters (namely perl's) are set up/how they define things? Because for instance, if I made a user defined syntax highlighter for perl, I cant think of how I could highlight "s///" -- and much less, how to highlight "s///" one way and // another way. (*=wildcard)
Anyway -- I just want to say, I love the new version. And, thanks to all those involved, for this great editor.
**Namely: to have the ability to define Regex syntax definitions, in addition to the simplicity of keyword lists. Or even just being able to include keywords, and well as regex's in the keyword list. Or at least the ability to use wildcards so you can define suffix's, and be able to use prefix's in the same key word set without having to make them all prefix's.
Being able to use an operator as folder open and close keyword, or being able define in another way to treat the folder open and close as a symbol.
Being able to define certain operators as escapes within the delimiter range's.
Being able to use characters defined as operators in your keyword's. For instance in the lang I’m working with I would like to be able to highlight any single letter (a, b, c, etc.), if it's preceded by a "$" or "," and has a space or other operator after it. But I don’t want to highlight, any single letters that are just surrounded by spaces or other operators. The only way I could do this would be to make "," and "$" not operators, but I need them to be operators for other ways they are used, So I cant just make "$" a prefix keyword.
Being able to make a range, where one or both of the endpoints, are multiple characters. For instance \:sometext: -- so "\:" opens and ":" closes. I can just make it start with ":" because, ":" is often used singly, when not preceded by "\.
And this is probably kinda of far out there, but who knows -- so i might as well say it. I was thinking, for certain parts of the lang I am working with (CfMC's Survent/Mentor BTW) -- It could be handy to be able to define a couple keywords, with a regex, and to be able to format (color/font/etc) different parts of the actually regex text, to define how I would like the different parts of what matches the regex to be colored. This may well be a stupid idea, since, there may well be easier ways to do it -- but as someone who's working in an odd lang, it seems like if it were not too hard to program that functionality -- it seems that it could provide almost unlimited flexibility, in the syntax highlighting. I could be completely wrong, though, and I could see how this might cause problems with the priority of highlight's etc. -- but I thought I'd throw it out there.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As someone posted recently, I would also like to see the custom highlighting, improved in a few ways** - though I can understand why this would not be a high priority. So I just want to ask a few questions, to try to get the most I can out of what’s already there.
First I just want to verify there is no way to do a couple things, as it is:
-Use regex's or wild cards in keywords. (I know there is a prefix checkbox that treats all of that group as prefix's)
-Define a delimited range, where the range has to start with a combo of two characters. (i.e. has to start with "\:" and ends with ":" -- ":" is used elsewhere without a second one so I cant just make it ":" and ":")
-Make a certain keyword group, only valid if preceded by an operator, so if it's preceded by a space, it will be ignored.
-A way to define certain operators as escapes within a delimiter range.
If any of the above are currently possible please let me know. Because I'm under the impression they definitely can't.
Also -- Is it possible to define more groups of keywords. (like is there a file i could edit by hand, and just follow the layout of the file, and add a "group5=" or whatever the layout is?
Do the syntax highlighting scheme's for the built lang's (like perl) use the same set up as the user defined syntax highlighting? That is to say -- would it be possible to create, with the custom syntax highlighter, a highlighting scheme that would work identically, to one of the included highlighters?
And if so, (or either way really) is there a file I can look at to see how the included highlighters (namely perl's) are set up/how they define things? Because for instance, if I made a user defined syntax highlighter for perl, I cant think of how I could highlight "s///" -- and much less, how to highlight "s///" one way and // another way. (*=wildcard)
Anyway -- I just want to say, I love the new version. And, thanks to all those involved, for this great editor.
**Namely: to have the ability to define Regex syntax definitions, in addition to the simplicity of keyword lists. Or even just being able to include keywords, and well as regex's in the keyword list. Or at least the ability to use wildcards so you can define suffix's, and be able to use prefix's in the same key word set without having to make them all prefix's.
Being able to use an operator as folder open and close keyword, or being able define in another way to treat the folder open and close as a symbol.
Being able to define certain operators as escapes within the delimiter range's.
Being able to use characters defined as operators in your keyword's. For instance in the lang I’m working with I would like to be able to highlight any single letter (a, b, c, etc.), if it's preceded by a "$" or "," and has a space or other operator after it. But I don’t want to highlight, any single letters that are just surrounded by spaces or other operators. The only way I could do this would be to make "," and "$" not operators, but I need them to be operators for other ways they are used, So I cant just make "$" a prefix keyword.
Being able to make a range, where one or both of the endpoints, are multiple characters. For instance \:sometext: -- so "\:" opens and ":" closes. I can just make it start with ":" because, ":" is often used singly, when not preceded by "\.
And this is probably kinda of far out there, but who knows -- so i might as well say it. I was thinking, for certain parts of the lang I am working with (CfMC's Survent/Mentor BTW) -- It could be handy to be able to define a couple keywords, with a regex, and to be able to format (color/font/etc) different parts of the actually regex text, to define how I would like the different parts of what matches the regex to be colored. This may well be a stupid idea, since, there may well be easier ways to do it -- but as someone who's working in an odd lang, it seems like if it were not too hard to program that functionality -- it seems that it could provide almost unlimited flexibility, in the syntax highlighting. I could be completely wrong, though, and I could see how this might cause problems with the priority of highlight's etc. -- but I thought I'd throw it out there.