Home » U++ Library support » LineEdit, EditFields, DocEdit » What do you think about this approach to making CodeEditor more user extendable?
What do you think about this approach to making CodeEditor more user extendable? [message #45606] |
Tue, 15 December 2015 12:07  |
cbpporter
Messages: 1427 Registered: September 2007
|
Ultimate Contributor |
|
|
Hi Mirek,
In my project I require a powerful code editor and I'm using CodeEditor. While it is a very powerful class, it is not that easy to add features to it without forking it. And this is what I've done.
But I am thinking about how to make it much more extensible.
Currently, there is an enum describing a bunch of hard-coded languages and a few tables with hard-coded positions.
I'm thinking of an approach where CodeEditor has no hard coded support for languages. Instead of a single value describing the whole language, we replace it with a structure having options and an old language option acts as a particular collection of new boolean options.
I'll give two examples on how this could work.
First, a statement like:
if(highlight == HIGHLIGHT_CSS ? *p == '#' : pair == MAKELONG('0', 'x') || pair == MAKELONG('0', 'X'))
would become:
if(highlight.UseCSSHex ? *p == '#' : pair == MAKELONG('0', 'x') || pair == MAKELONG('0', 'X'))
We would register the CSS syntax with this option set to true and for other registered syntaxes to false.
Then in CSyntax I added support for #region tags, like in C#. Rather than checking if it is C# or other languages that support #region, one would check highlight.UseRegions. This option would be checked by EditorBar too in order to draw #region outlines, like for #ifdef. I implemented this using a new hardcoded language, but would like a more flexible solution.
One would register a structure with appropriate options set for a language, together with keywords and upp ids.
How does this approach sound? I already have a forked CodeEditor, so I can create an early minimal prototype if you wish.
|
|
|
|
Re: What do you think about this approach to making CodeEditor more user extendable? [message #45609 is a reply to message #45607] |
Tue, 15 December 2015 14:16   |
cbpporter
Messages: 1427 Registered: September 2007
|
Ultimate Contributor |
|
|
Things that I'm trying to fine tune by language:
- highlighting of #ifdefs
- highlighting of @region
- highlighting of nested comments
- highlighting of doxygen like comments
- highlighting things like literal constants a bit differently based on language
- highlighting ids based on other id rules
- highlight a few symbolic meta constants as non-keywords, but as literal constants, like true, for languages where true is not a keyword, but a literal constant and should be highlighted as an int.
And achieve this in a pretty general and fast way.
And generally speaking, the C like language highlighter is able to approximately, often very closely, syntax highlight a given language, but as it currently stands:
- it is not able to properly 100% highlight some inputs. The changes would be trivial to make it 100% but
- would not be compatible with C++.
That's why I proposed a structure with bool options, to make sure that highlighting is fast. What I'd need it to handle, as just one of the examples, is "0.Foo" to be highlighted as a literal int, member selection punctuation, id. And "7.0.Bar" as literal double, member selection punctuation, id. And "7.0f.Foo" as float and so on. For all those pure OOP languages.
|
|
|
|
|
|
Re: What do you think about this approach to making CodeEditor more user extendable? [message #45619 is a reply to message #45609] |
Thu, 17 December 2015 13:30   |
 |
mirek
Messages: 14255 Registered: November 2005
|
Ultimate Member |
|
|
cbpporter wrote on Tue, 15 December 2015 14:16Things that I'm trying to fine tune by language:
- highlighting of #ifdefs
- highlighting of @region
- highlighting of nested comments
- highlighting of doxygen like comments
- highlighting things like literal constants a bit differently based on language
- highlighting ids based on other id rules
- highlight a few symbolic meta constants as non-keywords, but as literal constants, like true, for languages where true is not a keyword, but a literal constant and should be highlighted as an int.
And achieve this in a pretty general and fast way.
And generally speaking, the C like language highlighter is able to approximately, often very closely, syntax highlight a given language, but as it currently stands:
- it is not able to properly 100% highlight some inputs. The changes would be trivial to make it 100% but
- would not be compatible with C++.
That's why I proposed a structure with bool options, to make sure that highlighting is fast. What I'd need it to handle, as just one of the examples, is "0.Foo" to be highlighted as a literal int, member selection punctuation, id. And "7.0.Bar" as literal double, member selection punctuation, id. And "7.0f.Foo" as float and so on. For all those pure OOP languages.
OK, so just to make it clear, what you are proposing concerns CSyntax highlighter?
|
|
|
|
|
Re: What do you think about this approach to making CodeEditor more user extendable? [message #45625 is a reply to message #45623] |
Thu, 17 December 2015 16:46   |
cbpporter
Messages: 1427 Registered: September 2007
|
Ultimate Contributor |
|
|
mirek wrote on Thu, 17 December 2015 17:15OK, i have no problem with that, but perhaps it is as easy to just check current language, exactly as is happening now?
I'm doing a merge and testing stuff right now for the patch. And yes, we could probably leave things as they are in CSyntax. But some things are still a bit hard to do with a semi-hardcoded C-Like language list.
I need to add the #region and #endregion tags. So I have changed this code:
if(*p == '#' && findarg(highlight, HIGHLIGHT_JAVASCRIPT, HIGHLIGHT_CSS, HIGHLIGHT_JSON) < 0) {
static Index<String> macro;
ONCELOCK {
static const char *pd[] = {
"include", "define", "error", "if", "elif", "else", "endif",
"ifdef", "ifndef", "line", "undef", "pragma",
// CLR
"using"
};
for(int i = 0; i < __countof(pd); i++)
macro.Add(pd[i]);
}
I could add them here and that's what I'll do for the patch, but I still think it would be more elegant to have highlight be some sort of structure with fields. findarg(highlight, HIGHLIGHT_JAVASCRIPT, HIGHLIGHT_CSS, HIGHLIGHT_JSON) < 0 could become highlight.HasPreproc. And the macro list would not have to be static, but instead tied to highlight, with each separate highlight having it's own list. This way #region and #using, which are C# mostly, would not show up in other modes.
|
|
|
|
Goto Forum:
Current Time: Sat Apr 26 04:47:32 CEST 2025
Total time taken to generate the page: 0.02988 seconds
|