I'll take a look at your grammar. Many thanks!
I'd suggest to move any conversations regarding the new Eclipse
plug-in to its own mailing list:
http://groups.google.com/group/protobuf-dt . This way we don't spam
non-Eclipse users :)
On Wed, Aug 3, 2011 at 4:15 PM, Benjamin Wright <compuware...@gmail.com> wrote:
> Thanks for pointing me to the right place on import paths, next time I'll
> RTFM ;-)
> Enum Values are supported, but Enum Value Options are not... at least as far
> as i can tell. (I'll have to check more closely tomorrow)
> As far as supporting custom options goes, I have some experience in that
> front as I had to support them for what I was doing. They were by far the
> hardest part to build into the grammar and I never quite got it working
> right. The best I managed was to have five separate sets of rules, one for
> each type of custom option (field, enum, enum value, message, file)...
> I've attached what I came up with for an XText grammar in case it gives you
> any ideas on how to better handle it. The two things I never quite settled
> 1) How to handle enumation namespaces between enum value declarations and
> usage of those values in custom options. The namespace in proto is global,
> but XText grammar expects the ID to be qualified when used in another scope
> (while the compiler does not)... I suspect I just don't have a good enough
> grasp of XText to solve that problem. To support enumeration values i ended
> up putting the enum values at the top level by not having them be part of
> the the enum production.
> 2) How to validate the values of custom options... I left this as simply
> either a "MessageOption" or a "DirectOption", where the Message option is
> constrained to the structure (but not valid contents) of a TextFormat
> protocol buffer, and the Direct option is any of int, float, ID, etc...
> This could be taken further to handle each unique syntax type separately but
> it seems very inelegant and I was hoping to figure out something better
> before releasing anything (which I won't with now anyway as this is clearly
> the project that should move forward).
> One possibility that i was leaning towards that could solve both of these
> problems was to allow validation of option fields to fall on the compiler
> The XText API allows for secondary validation to occur, and the compiler
> provides line and character numbers in it's output... presumably you could
> just run the exe through java and capture & parse the System.out stream to
> determine any syntax errors not caught directly by the grammar. I did not
> have the compiler integrated but these plugins do - so it would seem this
> might not be that difficult to pull in.
> The downside of this option being that it will not provide auto-complete or
> other built in features of XText automatically - although to some extent
> that could be made up for with more custom code.
> -Ben Wright
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To view this discussion on the web visit
> To post to this group, send email to email@example.com.
> To unsubscribe from this group, send email to
> For more options, visit this group at
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to firstname.lastname@example.org.
To unsubscribe from this group, send email to
For more options, visit this group at