Re: GtkEtext final design



> > # ...and this is for HTML:
> > CommentStart = !--

> shouldn't that be:
> CommentStart = <!--
> ?

	...not sure, but "!--" is what they ship with (and what works).  
I'm guessing that nothing outside of a < > pair is parsed, and so once
you're inside a "<" the immediate "!--" indicates everything else up to
the next > is a comment.  I'm only guessing, it would be interesting to
dink around with it and see if I could break the syntax highlighting.

	Then again, it could be a workaround for a bug in their parser :).

> > # Not only that, but it supports more than one kind of comment:
> > CommentStartAlt = 
> > CommentEndAlt =
> 
> is that for single line comments? those are generically featured by
> GScanner as well.

	No, those are for multi-line comments.  However, there is also an
option for alternate single-line comments (so you could properly highlight
the "!" and "#" comments in an smb.conf file).

> > # There are other config options that are cool, too.  These are for HTML:
> > CharStart = &
> > CharEnd = ;
> 
> since the characters enclosed in & and ; in xml are actually arbitrary
> keywords as well, this again looks more like a parser item.

	This is one example where my understanding of scanner vs. parser
falls apart.

> at least so far i haven't seen a compelling reason in your mail to
> implement a *new* lexical scanner to surpass GScanner, since at the
> lexical level it is easy enough to expand to suit your needs.

	I think "new" may have been too strong a word.  Although I haven't
seriously looked at this problem yet, my general plan was to copy GScanner
and add the functionality I needed (as you suggest).  I didn't want to
worry about involving other people and/or binary compatibility issues, so
I was just going to call it GEScanner (since I only expected to see it
used in my personal application).

> and beware, implementing a reliable lexical scanner, that's still
> compact and fast enough to outperform lexx and co, is not a trivial
> task. it's also very hard to resist the temptation of implementing
> parser functionality at the wrong layer.

	Incidentally, I know practically nothing about scanners and
parsers.  I was planning on doing much reading when it came time to
implement this part.  Right now I'm focusing on my text widget.

	Also, since my real goal is multiple-language, configurable syntax
highlighting, my parser requirements may not be the same as a "real"
language parser.

> that being said, i'm willing to provide you with any help you require
> to extend GScanner beyond its current functionality to adapt it to
> your requirements.

	Excellent!  It will be a few weeks (circa 3 to 6) before I have
any time to commit to this, but I will certainly get in touch with you at
that time. As you have hinted, I have a strong feeling it will be a simple
matter of adding the necessary options to the GScannerConfig.

	In the meantime, if you're interested, read the documenation and
configuration files you get with the win32 "TextPad" program
(www.textpad.com).  The documentation is excellent regarding what those
options do, and you could dink around with it to try and break their
syntax highlighter :)


Thanks,
Derek Simkowiak
dereks@kd-dev.com



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]