Hi Volker, thanks for this initiative!
On Sat, Sep 10, 2016 at 5:47 PM, Volker Krause <vkra...@kde.org> wrote: > Hi, > > please review KF5::SyntaxHighlighting (syntax-highlighting in Git) for > becoming a framework :) > > This is a tier1/functional version of the Kate syntax highlighting engine. > It's not tied to a particular output format or editor engine, the interface is > basically just passing in a line of text and getting back a set of formatting > instructions. A QSyntaxHighlighter and a HTML CLI highlighter are included, > for example. > > Use Cases > > - I initially started this for use in GammaRay's QRC browser (which can embed > into QtCreator, making using the KXmlGui-dependent Kate part problematic) > - It's already used in KDAB's internal QML-based training presentation tool > - Kate, obviously (see below) > - possibly replacing a few hand-written highlighters in KDE PIM (Sieve, > message source, diff attachments), and enabling inline attachment highlighting > - the Kate team apparently also had some demand for this in the past, e.g. for > use in CLI tools > > Relation to Kate > > I showed my work on this to the Kate team at Akademy, originally to get help > regarding some semantic corner cases in the highlighting files, however the > feedback I got was a plan to turn this into a framework, and a migration > strategy for Kate, therefore the recent activity into that direction :) > > The migration would happen in small steps, the first one being Kate switching > to use the syntax definition files from the new library, as well as the > indexing and meta data loading code. More features would follow in the > subsequent releases, together with making the corresponding API officially > public. Future steps might include syncing the format/theme settings, > determining which syntax to use for a given file, and of course the ultimately > switching the entire syntax highlighting related code over to the new library. > > For this all to start, we'd need an initial KF5::SyntaxHighlighting release > first though, to not have KTextEditor depend on something unreleased. >From what I can see, the progress so far looks very promising, especially since you seem to be using this already in several places. :-) As you noted, the most important part is how to process. The idea of having an initial release in KDE Frameworks is fine, I would suggest that we need to agree the API is ok as is by then, and the API documentation is good [enough]. I already added some API docs, but the next days I can also look into the public interfaces again to see whether all makes sense from a KTextEditor perspective. Best, Dominik
