Getting Started

[amyers735]

Hello,

Currently there's an eclipse plugin for CFML (cfeclipse.org) which has become stagnant and I was looking to re-start the project. I initially looked at DLTK but that seems dead and LangEclipseIDE looks like being a good starting point.

I've got my basic project set up and I'm now having a look at getting syntax highlighting to work. At this point I'm a little bit vague on the best way to go (eg. what should be in PartitionScanner, LangPartitionScanner, and whether an ANTLR grammar I already have available for the language is any use to me).

Is there a mailing list or IRC channel you would recommend for me to ask this kind of question? Or alternatively re you willing to accept some (possibly dumb) questions from me to help me get started? I don't want to be a nuisance but I hope that maybe with a bit of guidance I can pick up and run with it.

Many thanks, Andrew.

[bruno-medeiros]

There's no mailing list or IRC channel at the moment. Discussion here in this issue is fine. How did you find out about LangEclipseIDE BTW? I haven't publicized it much: although it achieves quite a bit already, the API changes frequently - I don't to get stuck with the work and debt of maintaining a stable API so early in the project - but that might change if more people start to use it.

What do you mean "what should be in PartitionScanner" ? There is no class PartitionScanner, perhaps you meant LANGUAGE_PartitionScanner ? In any case, the scanner is meant to be a simple lexer, used just for syntax highlighting. That's nearly entirely its entire purpose - the partitions that it creates are mainly used to highlight source. (They can also be used to configure content assist and other editor features in a per partition basis - but that could achieved in a different way too)

[bruno-medeiros]

Ok, before people start using this, I've renamed it to MelnormeEclipse, I need to cleanup the name.

Also, a hint. If you want to check out a more complex IDE to see as an example, I suggest RustDT - it's the one with the cleanest code of the three - the only one who was created from scratch from MelnormeEclipse, whereas the other two started in a different way, and then where gradually adapted to MelnormeEclipse.

[amyers735]

Hello Bruno,

Thank you for getting back to me. I found out about the project in the Eclipse Community Forums - via this post: https://www.eclipse.org/forums/index.php/t/828006/

Yes, sorry, I was referring to LANGUAGE_PartitionScanner (in my case this will be called CfmlParitionScanner). If various sections (eg. in my case anything between the tags had some kind of "context specific" rules, I was thinking I'd create a rule in the LANGUAGE_PartitionScanner to identify this section, and then in the LangSourceViewerConfiguration use another Scanner to create more detailed highlighting for that section. Does this sound like the correct process?

I will check out RustDT as per your suggestion before I ask any more questions, as it may answer some for me.

Thank you also for your warning about the fact that things may change. I am willing to work with that, so please don't feel you're stuck with any particular decisions just for my sake. :)

All the best, Andrew.

[bruno-medeiros]

Yes, sorry, I was referring to LANGUAGE_PartitionScanner (in my case this will be called CfmlParitionScanner). If various sections (eg. in my case anything between the tags had some kind of "context specific" rules, I was thinking I'd create a rule in the LANGUAGE_PartitionScanner to identify this section, and then in the LangSourceViewerConfiguration use another Scanner to create more detailed highlighting for that section. Does this sound like the correct process?

Sounds about right, assuming all kinds of sections you can have are all known before-hand, for any file. This is because each partition is basically just a source region with a "type" associated with it, where "type" is just a string, that is part of a fixed, enumerated set of strings.

Usually a partition will correspond to a big token in the language (like a comment, a string, etc.), or it will be a generic region that will further be subdivided into other tokens or areas for highlighting. (that's when the secondary scanner is used)

[amyers735]

Hi Bruno,

Thanks for this.

I've made some good progress.

At this stage I don't have any requirement for a build comment. Is there a way I can prevent the build console activating when I save a document?

Many thanks, Andrew.

[bruno-medeiros]

Yes, there are several ways to do it. For starters the current version of Melnorme was changed so that the builder no longer runs automatically when you save a document. But for this you must have this change in: https://github.com/bruno-medeiros/MelnormeEclipse/commit/8119ffa4256ffe8f76c429511b5b9f8c52a2ae0f particularly the change in the plugin.xml. And it will only affect subsequently created projects.

But even so, the console will still pop-up when invoking the build manually. If you want to remove that entirely there is two ways:

• You can remove the builder altogether by modifying LANGUAGE_Nature and overriding #configure() so as to not add the builder. (only takes effect for subsequently created projects)
• You can modify the build operation to not output console messages.

[amyers735]

Hi Bruno,

I've now got Syntax highlighting mostly working on my Melnorme based plugin over at https://github.com/am2605/CfmlEclipseIDE.

• A couple of more questions that I've come across. I noticed there's a dependency on CDT when I install the plugin. Is that strictly required?
• I see that you've made a few changes to the Melnorme source - is there a clever way to bring them in to my project, or will I need to cherry pick them? (I expect it's the latter which is okay, but I just wanted to make sure before I spend the time on it).

Thank you! Andrew.

[bruno-medeiros]

The dependency on CDT is only for GDB debugging functionality. If you don't need that, you can remove that dependency. Just open feature.xml and remove and org.eclipse.cdt.* from Dependencies, and the .ide.debug plugin from "Included plug-ins".

As for new Melnorme changes, you can merge the whole changes, although there probably will be a few conflicts. Changes to files with with name "LANGUAGE_" won't apply to your IDE and should be discard. New files with "LANGUAGE_" name, might need to be renamed and adapted to your IDE.

Normally, the best thing would be to merge each individual commit chronologically, so it's easier to understand any potential API change, fix such compilation errors, and then go the next commit. However, if the only thing you've integrated so far is Syntax highlighting, you probably will be ok just merging the ~master HEAD and fix things from there.

[vladdu]

Hi! I found your project the same way as Andrew. I was about to set up to doing something similar (although less ambitious in scope).

I haven't started yet to try to implement my language, but I have a question related to how future changes to the framework can be merged in: I'm not sure I want to have framework commits mixed with the language-specific ones. If the language-independent parts are generic, what is the reason for making a language-specific copy of them? What is the advantage over having them in separate bundles?

[vladdu]

Reading the code, I see that one reason for not separating the language independent parts is that in some places the dependencies are inverted (independent depends on language specific). This is interesting, but creates an entangled web of dependencies, which in turn makes things more difficult to change. IMHO.

[bruno-medeiros]

Reading the code, I see that one reason for not separating the language independent parts is that in some places the dependencies are inverted (independent depends on language specific)

Yup, that is the second reason for this approach. This is so Melnorme code can refer to IDE-specific code directly, and thus preserve certain type-system constraints statically. Otherwise (using the library approach), you would sometimes need casts and runtime checks from a Melnorme generic type to the IDE-specific type. For example: IStructureElement is pure Melnorme code, but refers to StructureElementKind which is a language specific class and can be modified by the concrete IDE. In a language such as C++ or D, one could probably write Melnorme as library that used templates and meta-programming, but it's not something one can do in Java.

[vladdu]

An interesting way to solve this, at least for the structure model, can be found at https://projects.eclipse.org/projects/technology.handly

[bruno-medeiros]

An interesting way to solve this, at least for the structure model, can be found at https://projects.eclipse.org/projects/technology.handly

Oh, I didn't know about that one, and it looks very interesting. A clean attempt (unlike DLTK) at refactoring common JDT code, even if only part of JDT. I'll have to look into it in more detail.