On the subject of smart completion in IDEs, I've been experimenting with the
Xtext (http://wiki.eclipse.org/Xtext) to produce a simple, text-based
editor with
primitive syntax completion, error checking and outline views for Eclipse.

http://code.google.com/p/camel-extra/wiki/CamelSpit

There's some screenshots there to have a look at -- I started by looking at
Vadim's ANTLR grammar, but drifted from that somewhat purely because I
haven't fully grokked yet how Xtext does its thing.

Camel processors seem to follow a basic genetic plan, with some semantic
constraints, along the lines of

 <processortype> <expression>
      <action-section>
      <targeting-expression>
      <configuration-section>

plus any scoping syntax to clump things accurately.  This could lead to a
very clear grammar *but* it means that you have extra semantic-check
pieces to put in to make up for the generic structure (i.e. for some processors
you don't have configuration, or you can do any actions).

Taking the from the editor perspective, the goals are really to be as
deterministic
as possible, so that when a syntax completion request comes in, the options
that are presented to the developer make sense. Ideally, the semantic processing
is minimized to cut down on the lag time before the completion pop-up occurs.

The xtext grammar at http://tinyurl.com/5vsp28 goes down this route.

Of course, the bit that's interesting is the approach of going
editor-first. Xtext
will generate an ANTLR grammar, as well as the model elements for a syntax
aware editor and outline view, which is nice. However, the generated ANTLR
isn't as, ah, elegant as you might want it to be. There's bound to some kind of
maintenance issue going on there, as well as concerns not being correctly
separated. Trade-offs persist.

 --oh

Reply via email to