|
Written by fullmetalcoder
|
|
Wednesday, 14 March 2007 |
|
Spring is coming! No, I'm not kidding! Just have a look at Edyuk's SVN log... I've finally decided to reorganize a bit the damn layout of Edyuk's sources. Now, instead of hundreds of subfolders grouped in src/lib there are only a few ones (and this should even shrink later on) and all the independent modules (i.e. QCumber, qmdilib, QCodeEdit, QHierarchicalModel, ...) have moved to a 3rdparty directory. The most important reason is clarifying the hierarchy. Besides it will allow easy independent checkout of all these modules which will be a great benefit. Moreover standalone project files and examples for each of these modules will be added (if not present already) and this will spare me some pain when I'll feel like releasing them in separate packages.
Some of you might have noticed that a new folder appeared in QCodeEdit sources : xld2. What's that? Well, it is part of the "lifting" QCodeEdit is undergoing. First the syntax engines and the color palette will be separated via a QFormatFactory clas, which will allow an easier implementation of a (not-so-)soon-to-be configuration dialog. Then the XLD file format lacked consistency and flexibility and a new specification is being designed as follows. The basic element of a syntax definition will be an "area" (or "context", not sure yet) which may have a format of its own. In this "area" will be applied several rules defined by 3 types of elements : - KeywordList : obviously a list of keyword to be highlighted in a certain way
- RegExp : a regular expression (useful for numbers)
- Trigger : the trickiest but most interesting of all these. A trigger is basically composed of two strings : starting and ending sequences (possibly an escape sequence as well). It does not have a format of its own so you may ask : What's the point of this item? The answer is pretty simple : it switch the context to any other!!! This allow for example very simple implementation of Doxygen inside C++ and of HTML inside Doxygen and...
 As with the previous spec the key concept is flexibility. Thus, each syntax element will have a per-file unique id which will later be usable to access a component from any place in the syntax (or even from another syntax) which avoids code-duplication.
However this shiny brand new spec is not implemented yet and will have to wait a little more so I'm open to any comment so as to improve it BEFORE starting coding.
What will prevent me from simmerging myself in the nice world of raw text-processing yet another time? Another text-processing task : code completion, which still needs fine-tunning and implemtnations of configuration dialogs... |
|
Last Updated ( 2007-05-24 19:07:57 )
|