[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cdt-dev] Editor for custom C-like language
- From: Eugene Ostroukhov <eostroukhov@xxxxxxxxx>
- Date: Wed, 31 Aug 2011 13:38:49 -0700
- Delivered-to: email@example.com
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=sLeRzNJ3Wci7Ng1EgLKI/5nmaCpy6Qke/bEbDrG/aAE=; b=ptGEzazc6GuLbVfuD68W9rJGxq2azMtupiRfuQGy8yDBLweg2L9byL8zArhEiF6Y34 gWqDJb7nXgGndwmwb/eHjkcKPfCr2YX0izFKwON6jAPVEYbtqP9yG5M7Ez4zM3F1cu6w 11SMB6EBbbdNEhE9A5jyQnXsx5TWVIyI8e6BQ=
Our language is not as drastically different as Objective C so I am hoping this is more doable. I can spend around a week on a proof-of-concept.
Am I right that any CDT component (i.e. source editor, formatter, code assist) can refer to a "language" as that extension point is declared in cdt.core? SSE (WTP source editing component) do all such configurations based on the content type.
On Wed, Aug 31, 2011 at 1:10 PM, Schaefer, Doug <Doug.Schaefer@xxxxxxxxxxxxx>
Thatâs the dream. Iâm not sure if itâs practical at this point though. We have folk interested in Objective-C done this way but it proved to be pretty difficult.
I am working on an editor for a custom C-like language and the goal is to retain all the rich CDT editing facilities.
Some requirements that are specific to our language:
1. Custom syntax for invoking functions that run on a different target.
2. Same source file can contain pieces that run on different targets. It is not straightforward to do calls between targets and not all symbols (variables, functions) are available on all targets.
CDT provides excellent way to customize keywords and such using language extension points. Satisfying requirements outlined above does not seem to be as easy. I believe that I will need to do some customizations in the CDT code base.
Currently to me it looks like I need to:
1. Customize parser (and tokenizer) to parse our syntax. I am mostly happy with custom subclass of the AbstractGNUSourceCodeParser - the only problem is that ideally I would need to have custom tokenizer to introduce tokens for syntax like "<<<" and ">>>".
2. Customize CTextTools to introduce custom partitioner so it is possible to introduce different code assists for different run targets.
Are there any other ways to introduce custom C-like language and retain support for Codan, refactorings, etc?
cdt-dev mailing list