Outlining how you plan on handling highlighting going forward?

[seraphx2]

So, in the section called: "Automatic Syntax Highlighting", you outline how to setup the syntax highlighting for Cpp. Previously, all of this was contained in ScintillaNET, was it not? Are you now saying that all the time we need to define these "style sets" ourselves? Also, there is no longer support for SQL?

I'm sorry, I'm just confused about how things are going to be going forward and what I will be expected to do versus what Scintilla will be handling for me. Can you please clarify the future of ScintillaNET in this regard? Thanks.

[jacobslusser]

I've been adding lexer support on an as-needed-basis and you are the first to request SQL. I should be able to get the appropriate constants added to the codebase shortly.

Prior versions of ScintillaNET used a home-grown XML configuration for configuring lexer and style definitions. In some cases (like for SQL) those XML configurations were embedded in the ScintillaNET DLL itself. Internally we would read the XML configuration file and do the work for you of setting the style definitions, lexer enumeration, and keywords as you see documented in the "Automatic Syntax Highlighting".

In my many years of moderating the forum discussions, I found this approach to be a great source of confusion for developers. The XML configuration that was embedded didn't allow for customization, so it was fine if you wanted the colors and fonts we picked out for you, but if you wanted to customize it you would need to create your own XML configuration file and there was no documentation on how to do that. The embedded XML files would also frequently get out of date when new language keywords were added or the lexers themselves were enhanced with new style definitions.

My approach going forward has been to hide less of Scintilla's functionality from the users and instead provide better documentation so they understand the mechanics of what's happening. I think this approach, while seemingly extra work at first glance, will pay dividends later when developers need to troubleshoot or want to explore Scintilla's API deeper.

Thus, I haven't yet, and not sure I plan to, add a single switch for SQL syntax highlighting.

That being said, I'm always interested in developer feedback. If you think there is value in creating some kind of "load style definitions from XML" method, I would be happy to listen. Although, more often than not this tends to be application-specific and developers want these XML files to be handled differently, formatted differently, etc....

[seraphx2]

Totally understand, just was curious about some clarification on that. I think it makes sense to allow it to be open-ended. It can create a lot of different solutions to the same "problem" but allows each developer to tackle it for their purposes.

So, then why do we need the Lexer.Cpp, or Lexer.Python at all if those don't even do anything out of the box (at least they don't appear to on the surface; obviously it's doing something important) and we still need to define the keywords and the colors to even get them to work? What is scintilla.Lexer = Lexer.Cpp accomplishing if not the highlighting?

[jacobslusser]

Specifying Scintilla.Lexer = Lexer.Cpp is the instruction to Scintilla to actually 'lex' the document, i.e. break it down into its component parts: numbers, operators, braces, keywords, comments, strings, etc... However, without various style definitions, you wouldn't likely see the difference. If you were to poke around the document using GetStyleAt you would see various styles assigned to spans of text but since style 1, 2, 3, etc... all have the same appearance, you wouldn't visually see the difference. Scintilla intentionally separates the lexing (classification) of a document, from the appearance (display) of a document.

As for the keywords, it's typical of most lexers shipped with Scintilla to separate-out keywords from the actual lexing logic. This is smart because often the syntax of a language doesn't change, but new keywords are added such as the query keywords (select, where, from, orderby, etc...) introduced in C# 3.5. If they were baked-in to the lexer, the Scintilla team (and ScintillaNET) would need to release new versions each time there is a change. The keyword lists are not just for language keywords, but also for user-defined keywords. For example, you might want to use one of the keyword lists in the SQL lexer for user-defined functions. So setting them independently of the lexer makes sense.

[Orvid]

Perhaps it would still be worthwhile to add a set of default styles that can be applied for each language? A LexerConfiguration and StyleConfiguration for instance. This would also make it easier for end-user applications to deal with the serialization of, say, an XML file to define them.