"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote:

> I'm using a combination of Epsilon (Emacs), and VC6.0. As you might expect, neither show any sign of doing anything with the D-specific comments, although they happily highlight D source as they would C++.
> 
> I could probably rattle up some additional EEL code for Epsilon, but it'll never be quite as nifty as what you're working on ...

Right, so you don't get comment coloring at all if you use /+ +/ :-(

LOL -- The line above just gave me a funny idea, to provide specific colors for certain emoticons, such as :-), :-(, and like that.  For that matter, I could highlight certain words/phrases found frequently in comments, such as "KLUDGE", "BUG", "WALTER ROCKS", or "DAMN YOU MICROSOFT". And to make it complete, I could make BOLD BLINKING TEXT if I find any hungarian-style identifiers :-)

-- 
dave

Cool!

I was gonna' suggest that you highlight the "enabled" version{} block or blocks, cos' I imagine you're parsing all that stuff. Does the environment you're working in support lifecycle state?

BTW; it might be a laugh to see the regex for recognizing Hungarian-notation <g>

- Kris

"Dave Sieber" <dsieber@spamnot.sbcglobal.net> wrote in message news:Xns94C7EDDFB1E4dsiebersbc@63.105.9.61...
> "Kris" <someidiot@earthlink.dot.dot.dot.net> wrote:
>
> > I'm using a combination of Epsilon (Emacs), and VC6.0. As you might expect, neither show any sign of doing anything with the D-specific comments, although they happily highlight D source as they would C++.
> >
> > I could probably rattle up some additional EEL code for Epsilon, but it'll never be quite as nifty as what you're working on ...
>
> Right, so you don't get comment coloring at all if you use /+ +/ :-(
>
> LOL -- The line above just gave me a funny idea, to provide specific
colors
> for certain emoticons, such as :-), :-(, and like that.  For that matter,
I
> could highlight certain words/phrases found frequently in comments, such
as
> "KLUDGE", "BUG", "WALTER ROCKS", or "DAMN YOU MICROSOFT". And to make it complete, I could make BOLD BLINKING TEXT if I find any hungarian-style identifiers :-)
>
> --
> dave

Dave Sieber wrote:

[...]
> For that matter, I could highlight certain words/phrases found frequently in comments

VIM does that since a long time. Apropos how did you code your lexer for recognizing correctly `[2..4]', `[cast(int)2...4]', `[x...y]' and the like?

So long!

"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote:

> I was gonna' suggest that you highlight the "enabled" version{} block or blocks, cos' I imagine you're parsing all that stuff. Does the environment you're working in support lifecycle state?

I had thought of that, because MS does it with their C# editor, so it should be doable. But it would have to know which -version switch you want to highlight, or if it's a debug build, for instance. My first goal is to get basic syntax highlighting working, then add that kind of functionality step by step.

> 
> BTW; it might be a laugh to see the regex for recognizing Hungarian-notation <g>

You can define new color classes, and then attach them to token types. Since you typically scan symbols for keywords vs. identifiers, you can also check for other words or spellings, etc.  But maybe that should be in a later version, though :-)

-- 
dave

Manfred Nowak <svv1999@hotmail.com> wrote:

> VIM does that since a long time.

Yes, it's not uncommon. I was really just joking :-)

> Apropos how did you code your lexer
> for recognizing correctly `[2..4]', `[cast(int)2...4]', `[x...y]' and
> the like?

For tricky things like these, I looked at how Walter did it in his front- end, since the editor should reflect the syntax just as the compiler would see it.  The first example is legal, but the last two produce syntax errors, because, while "..." is a legal token itself, it can't be used in an array slicing context. In the second example, Walter's lexer detects this as an error because when he begins parsing a number and encounters '.', he looks ahead to see if the next char is also '.', in which case he backs out because ".." is illegal in a float, but is a valid token otherwise. When he backs out he then sees the third '.', and it's illegal in its context. In the third example, he sees "..." as a token right after the "x", but it too is in an illegal context.

Syntactically they are all legal, so lexing doesn't produce errors. It's the semantic parsing that detects incorrect usage. As far as lexing and parsing of tricky contructs like the above, my own philosophy is that it's more important simply to be consistent with the errors rather than trying to deduce what the most logical interpretation is. In cases where the interpretation could go either way, I would prefer myself to write it explicitly clear, as in:

[cast(int) 2. .. 4]

Even if I am clear on how D might parse "2...4", the next guy working on the code might not be. After decades of errors and misinterpretation of code in our industry (something C++ specializes in :-), we should realize that depending on everyone's (and the compiler's) understanding of and agreement on the interpretation of tricky contructs is a dubious practice. </soapbox> <G>

-- 
dave