Reusing KHTMLs CSS parser for a KDevelop language plugin

[Milian Wolff]

On Wednesday 21 October 2009 21:51:08 Aleix Pol wrote:
> On Wed, Oct 21, 2009 at 8:11 PM, Milian Wolff <mail at milianw.de> wrote:
> > Hello!
> >
> > Sooner or later I want to start on a language plugin to add CSS support
> > to KDevelop (and eventually Quanta).
> >
> > For that I need a tokenizer and a parser. So far, each language plugin in
> > KDevelop uses an AST and the Visitor concept to build the DUChain. As
> > I've never used Flex myself, and am by far no expert in parsers, does the
> > CSS parser support the Visitor concept?
> >
> > Nevertheless, I'd like to at least reuse the tokenizer from kdelibs and
> > would
> > write a grammar for Kdevelop-pg-qt to get a parser with an AST.
> >
> > I had a quick look at kdelibs/khtml/css and I see that neither the
> > parser, nor
> > the tokenizer gets installed. Of course, this makes sense if noone uses
> > it outside of KHTML. Could this be changed? Or would those classes then
> > have to
> > stay BC and this is not possible/wanted for such internal classes?
> >
> >
> > Alternatively to the above, are there maybe KHTML APIs I can use that
> > give me
> > a low-level analysis of a given CSS file? I'd need e.g. a list of rule
> > definitions, imports, charset statements, together with line numbers
> > where they
> > occur. That should actually be enough to build a DUChain.
> >
> > Note that most of the above could be applied to other languages as well,
> > most
> > notably JavaScript/ECMA Script and XML/HTML/XHTML.
> >
> > Thanks and have a nice day
> 
> Not as far as I know, I needed a CSS parser for a project I've been working
> on, and the only solution I got was to access the CSS through the DOM. My
> solution was to use libcroco (because I didn't have the time to implement
> the CSS parser). libcroco using the SAC parser (like SAX but for CSS) is
> quite light so it would make sense to be used.wa
> 
> A Qt CSS parser would be needed though, IMO, so if you decide to do it, I
> don't think you're going to lose your time. It's not a very complicated
> language anyway. (as a language, there are a lot of semantics created, of
> course)

As I said in the other mail, it will potentially boil down to that. Lets see 
how far I come.

I'll try to re-use as much as possible from the KHTML CSS tokenizer and put a 
KDevelop-PG-Qt parser on top of it. Do you think that something like that 
would have been helpful for you in your project? I don't now neither SAC nor 
SAX nor libcroco.
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20091021/d9be8c23/attachment.sig>