The survey of needs

This is not the most up to date version, but I’ve started writing in my latex file, so I don’t take the time to keep my .txt files up to date. Sorry.


This section will discuss the result from the survey about developers needs in an editor. After the survey had been up for 12 hours, nearly 40 different developers had sent in their feedback, which is nearly all of the developers that had received the e-survey by e-mail. Other communication of the survey was done through word of mouth, whiteboard in lectures, and info screen spread around Department of Informatics. I will start of presenting the survey in its full, then discuss the ambiguity some of the questions rose. At the end a discussion of what this survey teaches will be presented.

There where a total of 5 mandatory questions, and three text boxes to add more information. The first question where not really necessary for this survey, but helps to show the representation of the developers that answered this survey. As predicted mos of the feedback was from developers rating them self as something in the middle and up of just started and experienced programmer.

Since this survey where focused on what editor features developers uses, there was a certain need to find out what tool they use when developing, and if they use the features I predicted was necessary for an editor. As it not only important to find out what features they use, it can be relevant to see how much they use that certain feature, so there where also table asking for how much they used each of the features. Ranging from “not used”, “uses” to “uses all the time”. Between what kind of features a developer uses and how much they use it, I had a question asking what kind of features they felt was necessary to make a good IDE/text-editor. The text-boxes in this survey was there to let the participant elaborate to either the features they thought was needed for a good editor, other features the often use, or just wanted to add some extra thoughts about this survey or IDE/text-editor generally.

After I had sent out the survey some of the recipients came to me to discuss some of the questions and answers. It quickly arose that people had not read the transfiguration in the description. Which in turn led to users answering the questions with different features in mind. Especially ‘refactoring’ and ‘source tree’ where to features that the users had misunderstood or thought was directed to other features. The obvious reason behind this misunderstanding is that the survey participant did not read the description before they did the survey and did then not get the explanation about the different terms used in the survey. The not so obvious reason is that the two terms ‘refactoring’ and ‘source tree’ are also used to describe other features.

When we talk about refactoring in generally, developers often think about code refactoring. Best describe by Martin Fowler

     ”Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.” (

So the case in this survey may have been that participants have been thinking about code refactoring, which is something no tools naitvely supports. As this often is a difficult task, even for humans. Which would often make it even more difficult to make a feature that would do it automatically. The name refactoring in this case comes from Eclipse, and their use of refactor or refactoring.

the ‘source tree’ ambiguity stems mostly from that source in developing are used to describe a lot of different aspects, and that a source tree in some form/kind are something most IDE and some text-editors has. In this survey a source tree was supposed to represent a tree of the code you where currently writing (see image), but a source tree may in many occasion mean a list of files in a project. Also called a ‘project tree’ or project source tree’. In Eclipse a source tree in our context is called ‘outline’. This may have been better to use, and would probably made for less confusion. Other viable terms are abstract syntax tree from compilers, or just plain ‘code tree’.

How did the survey go


The survey in it’s whole can been seen in attachment X and thee answers are in attachment X. The first question was addressed in the previous section and will not be repeated. So I will list up each question and discuss the answers given. This is to make it more clearly and straightforward.

- What is your text-editor or IDE of choice?

This was a question where the user could tick off each editor they used, and add more if they wanted. Over 40% of the participants used Eclipse, but Emacs and Vim was close behind. That which where interesting was that 36% of the users tick of for other, and half of them said the used Sublime. This very interesting since this is a fairly new and up-and-coming editor. The rest of the editor was well distributed.

- Does your choice of IDE/text-editor support one or more of the following features?

Next question was more of a control question to see if the features we expected to be important to implement in a new editor. And our believes where confirmed by the answers. Nearly all of the features where used by at least 75% of the participants, and only source tree and refactoring where less then 70%. As discussed earlier, this is probably because of the ambiguity in the words.

- Which of the following features do you think is necessary for an IDE/text-editor?

To find out what people would want in a new editor, we asked what features they felt was necessary. These answers lined pretty nicely up with what features the editors/IDE they already use supports. It also lines up with what features they use, which can been seen in the next question. One participant also stated;

   ”All the rest is very usefully but syntax highlighting is the only one I can not be without”

- Which of the following features do you use when you develop?

Last question was about which features they used when they developed, and how much they used each specific feature. As predicted most of the features where frequently used, and as previously questions show, ‘source tree’ and ‘refactoring’ where the two that was least used. This, again, can be either because of misunderstanding of what the survey meant, or that they just didn’t use it that frequently. ‘Code completion’ and ‘Code suggestion’ had also nearly the same answers, which is likely since most editors/IDE that have code suggestion, also support code completion. ‘Error-reporting’ on the other hand has a more divided feedback, where nearly 30% says that the use it all the time, but another 30% says that they use it rarely (which is indicated by a 2 in the survey). The remaining 40% was spread between ‘not used’, and ‘uses’. Compared to what kind of editor/IDE participants uses, the distribution between ‘uses all the time’ and ‘rarely used’ is comprehensible, as Vim and Emacs (which more then 55% of the participants uses) does not support error-reporting by default. As they don’t have any understanding of languages without modes or scripts.

To supplement to the last question, there was a text-box for the participants to add features that they did use, but was not present in this survey. A common denominator of the extra features used are that they are complex and split between different tasks. Also none of the participants mention the same feature. 

Some of the more difficult and complex ones, which where not tied to language specific features, where; debugging, version control, plug-ins and plug-ins manager, code optimization (footnote: similar to real refactoring), and macro-recording.

Features which are possible with the RSTA framework; definition jumping, diff view, source link (footnote: accessing other files via ctrl-click), keyboard shortcuts, code generation, dynamic templates, and split window.

There where also mention of features that are already functional in RSTA, which where not mention in the survey. They are as following; automated indentation and tabbing. Both of these could have been added to the survey, but where forgotten.

0 notes

More topics to write about

Today I’ve been reading another master thesis about the ThingML project written by a friend of mine. If your interested you can find it here;

While reading it I’ve picked up on some topics I need to focus on, or have in my thesis. 

These are the following topics

  • Motivation
  • Research Methods
  • With sub-topics like Quantitative vs Qualitative research methods, and Data Collection.
  • Terms and Expression can also be a viable topic

Of course there will also be needs for further explore and explain the topics I have written about, both in the essay and on this blog.

0 notes

How to implement your DSL with RSyntaxtTextArea

This is a chapter about how to implement your DSL with RSyntaxtTextArea and is written without tables, figures, and footnotes even thought they are referenced. This will be added in a later version. Sorry for the inconvenience.


Implementing a custom domain-specific language (DSL) with a IDE or text editor may be a time consuming task. Using the model generated by Eclipse Modeling Framework (Eclipse MF) will make that easier. As last chapter mention, you could use the plug-in that Eclipse MF generates, but this paper is about how to implement a DSL with a custom workbench. In this case it will be showed by using RSyntaxTextArea (RSTA) by FifeSoft ( The aim is to implement the model generated by Eclipse EM with RSTA with changing as little as possible of the RSTA base code. Because of this we are depending on using JFlex to define the syntax highlightning. This may be seen by a drawback for RSTA as you have now two places to manage the keywords used in the language. Since a change in the Ecore-digram and CS-file will potensially affect the JFlex-file. Luckily this is a minor drawback compared to what RSTA gives us for free as a framework.

To implement your DSL into RSTA you need the model code and model editor generated from Eclipse MF, and RSyntaxTextArea and RSTALanguageSupport (which in turn need the AutoComplete library). The RSTA files can all be downloaded from FifeSoft. From the AutoComplete only the JAR is needed. Other then that JFlex is needed to generate the Java-parser for the syntax highlightning. The whole process of implementing the Eclipse model into RSTA is a comprehensive task, and it will be split into different task. To make it easier to follow and understand.

- Start of by separating all into different folders, so that you have it all nicely sorted. This will make it easier to update each of the individually part if you need to expand your language, or there is an new update for RSTA. As mention earlier you only need the JAR of AutoComplete, so that folder is not really necessary after you’ve used ANT to make a JAR.

- Then we will continue to make the syntax highlightning work. In RSTA this is done by a JFlex file with your keywords linked to the different keywords supported in RSTA. This can of course be modified so that you can add more colors (see image for example JFlex file). This is often in editors called a mode, and can be found in the mode folder inside RSyntaxTextArea. Next you need to parse the JFlex-file to generate a Java-file and remove two methods that’s been added twice. “This implementation was created using <a href=””>JFlex</a> 1.4.1; however, the generated file was modified for performance.  Memory allocation needs to be almost completely removed to be competitive with the handwritten lexers (subclasses of <code>AbstractTokenMaker</code>, so this class has been modified so that Strings are never allocated (via yytext()), and the scanner never has to worry about refilling its buffer (needlessly copying chars around). We can achieve this because RText always scans exactly 1 line of tokens at a time, and hands the scanner this line as an array of characters (a Segment really).  Since tokens contain pointers to char arrays instead of Strings holding their contents, there is no need for allocating new memory for Strings.” In this case you need to remove the second definition of the zzRefill() and yyreset().

- Next before highlightning is done is to add your chosen syntax to the file in package org.fife.ui.rsyntaxtextarea. When this is done, what is left of RSyntaxTextArea is to make a JAR for the RSTALanguageSupport. As with the AutoComplete this is done with ANT.

- Rest of the implementation of the Eclipse model is done inside RSTALanguageSupport. API specification used for the code completion in RSTA can be added to the data folder following the syntax of CompletionXml.dtd. Examples can be seen by looking into one of the many languages already there. Also before continue be sure to add all necessary libraries to the ANT-file.

- Depending on what kind of features you want, there are few steps to take just to implement your own DSL. Start by adding the DSL to the language drop-down menu in DemoRootPane, so that it is easily loadable when the editor is running. This means that you need to have added a text-file with a sample of your DSL code. For example an Hello World. If a source tree is wanted for an editor take a look at step X.

- Next up is to add your languages parser, and that means adding your own language factory. This is done in two steps, first add your language to the, and then creating a folder for your language, and your own language support. Preferably DSL/ For reference there are sample language (should probably choose one who looks similar to your DSL or the as it is sort and fairly easy to comprehend). The main job for the LanguageSupport is to link the languages parser (not the Eclipse parser per se) with the RSTA.

- When creating the parser-file you need to be sure to import the Eclipse model. Then you need to build the class extending the AbstractParser class and implement the empty methods, for reference you should as mention look at some of the sample languages. Things to remember is to register your file-extension with the EPackage.Registry and the Resource.Factory.Registry (see example image with ThingML). Without this Java will not be able to load the DSL files for either parsing or compiling.

- Every time a user types something into the textarea (called RTextArea (footnote: RTextArea is a modified JTextArea with added features)), a method in the LanguageSupport called parse(RSyntaxTextDocument, String) is called. So inside this method, to start parsing the document that RSTA creates of the written code it need to be converted to an InputStream that the ResourceSetImpl can load. When loaded there are two main option to run, first the getErrors()-method need to be called to retrieve any syntax-errors. This should throw an ParseException to avoid crashing the loader later. The error-handling will be dealt with in the next step (X). If there are no syntax-errors the next step is to try to find context-errors using the resolveAll(). This will try to simulate run-time of the code. If there are any syntax-errors they can be retrieved by yet again calling the getErrors()-method, which will return a list of Diagnostics objects. This in turn need to be converted into DefaultParserNotice which is what RSTA uses to underline errors in the RTextArea. Every notice need to be added to the ParseResult object that the parse()-method returns. As stated earlier, if there are some context error the parser should throw a ParseException which should be caught inside the parse()-method. And it should create DefaultParseNotice similar to the context-context error, but with the result level as ParserNotice.ERROR. After all parsing is done, a firePropertyChange need to be called.

These steps are all that are needed to get your DSL up and running with RSTA with syntax highlightning, simple auto complete, and syntax and context error underlining. See step X for source tree, and step X to utilize the built in content assist for Eclipse.

- Adding the source tree can mainly be done in two ways. Here we will only cover the easiest of the two. In which case you need to create an own parser that will build the tree from scratch using tree nodes that extends SourceTreeNode. A good source tree example is the XML one, as it’s small with no extra features.

- The work inside the tree building class or method is up to you, as long as the AbstractSoruceTree (explained in the next task) can reach the root of the tree.

- Before testing the tree builder a DefaultCellTreeRenderer and a AbstractSourceTree need to be built. The initial CellRenderer is there to populate the tree and to avoid using Swing’s HTML rendering engine. As it is very slow. Still, there will be problems regarding speed with huge trees. The AbstractSourceTree (which is often named help you manage the tree and textarea interaction. In other words, when to update the tree, when to highlight words marked in the tree and so forth. This class will also retrieve and build a new tree when necessary.

- When all of these four separated classes have been made, the next step is to implement with the RTextArea, so that it gets generated when a user type in code in your new language. This is done in the refreshSourceTree() method inside the RootPane class.

This is all that needs to be done to implement a simple source tree for any given language. The only feature missing in RSTA in regards to source trees are the possibility of marking a word in the textarea and at the same time get it selected in the tree. 

Last we have one of the useful features in RSTA, the content assist or auto-completion as the library is called in RSTA. In RSTA content assist is done in two ways (which can be mixed). There can be an XML-file with information about your language and keywords (as mention earlier), or by implementing them in code or while the program is running.

- Implementing code assistant by XML is explained in task X, so let us look at how to do it by code, and how to add the content assist already generated by Eclipse. Some  code completion is already implemented in code as seen in three different CompletionProvider method; string, comment, and code. So if you only need simple completion, these can be added directly here.

- Adding content assist from the Eclipse model is a little bit more trickier. This is because you need to override the keystroke listener inside the inputmap. See an example in table X. This should be implemented using an AbstractAction. This ContentAssistAction need to get a loaded resource from the Eclipse model. See table X for an example on how it can be done. It is important to remember that the doCompletion() is called last, as this method triggers the content assist window. Letting the user see what can be selected.

In this chapter we have seen how to implement your own domain-specific language designed in Eclipse MF and EMFText with RSyntaxTextArea. The features we’ve seen now are the features that RSTA support out-of-the-box. File handling need to be implemented by the developer, but using the Java and Swing framework makes this easy.

0 notes

The process and steps behind making a textual DSL using Eclipse MF and EMFText

There are several tools to use when making a new domain-specific language (dsl). One of the more popular one is to use EMFText with Eclipse Modeling Framework (Eclipse MF). As mention earlier, EMFText builds on the Ecore model produced by Eclipse MF or other tools that can generate an .ecore-model. An Ecore-model is an XML-schema describing object models. The definition used by the EMF project is as following: “The EMF project is a modeling framework and code generation facility for building tools and other applications based on a structured data model. From a model specification described in XMI, EMF provides tools and run time support to produce a set of Java classes for the model, along with a set of adapter classes that enable viewing and command-based editing of the model, and a basic editor.” ( 

So the way to make an own DSL is to first download Eclipse MF and install the EMFText plug-in (see and, after that you can start modeling your language using the Ecore-model. Which can be done in two ways, either by using the Ecore model editor or the more graphical way with the Ecore diagram editor. Using the Ecore diagram is quite different from the model editor as it is an drag-and-drop editor which automatically generates an .ecore-file. This is also the easiest way to work as you will get a better overview of the context of your language since it is laid out in a graphically view with boxes and arrows. To start creating your language you drag out classes which in turn will represent keywords in your syntax. To get the classes to communicate you create references arrows between them. If you want a keyword to reference or contain another keyword (see image) you need to check “Is containment”.

Next part of your domain-specific language is to either create or update the generator model (.genmodel) which is used to control code generation for the model. You load the Ecore with the GenModel by right-clicking and selecting “reload…”. Then choose “Ecore model”, and browse for your ecore model before you press “Load”. When that is done you can click “Finish”. This will load your new Ecore model into the generator model, which in turn will let you generate model, edit, editor, and test code for you domain-specific language.

The generated code is used to build the editor and a parser for your DSL. Model code is used to generate code implementation of your language, and the interface. Edit and editor code is for the Eclipse plug-in. The “editor” is the UI for the Eclipse editor and wizards, while the “edit” code includes adapters that provide a structured view and perform command-based editing of the model objects ( If you only want to implement your own editor, there is still need for the “edit code” as it generates a very powerful code-completion interface.

For now you have generated a simple syntax for your language based on keywords (see example image). To make this language more complete or straightforward we can use EMFText to generate a .cs-file (complete name :\). Using EMFText you can define the syntax any way you want by describing the “RULES” using the keywords from your Ecore model. It will nearly look like how the programmer will utilize the language (see image … ).

When you have defined your own syntax for the domain-specific language you can generate the Eclipse plug-in with the syntax defined in the CS-file. Then you can either run it or use the generated code for implementation in a separated UI. Which brings us over to the next subject, how to implement a DSL made in Eclipse MF and EMFText with a custom GUI or framework.

0 notes

Which one to use?

There isn’t much difference between Xtext and EMFtext as other have found out (Create a DSL in Eclipse - Christopher Guntli and Petter Graff blog They both give you the same (in the final language) functionality and are both well integrated with Eclipse, and in our case they are both usable outside in other domain-specific editors. Christopher Guntli have made an interesting chart on which task EMFText may be preferred over Xtext and vice versa

(see table 1: comparison between Xtext and EMFText page 8). In this table Xtext is slightly ahead. This may be because Guntlis’ personal choice is to go for Xtext as he likes the way Xtext implements code constraints and formatting by using code injection. If your already familiar with EMF and the Ecore model, the best choice would probably be EMFText.

In summary the main difference is that EMFText is built up by two attributes, the EMF model which describe the context of the language, and the .cs file implemented in EMFText let you describe the syntax of the language. In Xtext on the other hand both the context and the syntax are described in the same file, and there is no need for the EMF model (that you can optionally generate).

There may be some under laying differences in how the Eclipse-plugin is generated, for example how Xtext handles expressions and priority between operators while keeping the metamodel clean from any tricks (Franck Fleurey), but this is outside this thesis scoop.

The reason for using EMFText


The main reason for the ThingML project to choose EMFText over Xtext is that Franck Fleurey (the main developer) is most familiar with EMFText and as mention earlier that is often the main reason to go for the one or the other. Another benefit of EMFText is the use of the EMF model which is a graphical metamodel of the context of the language. This can easily used to describe how the context of the language is built up.

Both tools gives you more or less the same features;

* Code completion

* Syntax Highlightning

* Outline (what is this?)

* Automated parsing and support for quickfixes and warnings.

* Advanced bracket handling

* And more… (guess I need to look a bit into this)

They both gives you approximately (?) the same features, but the development process are very different.




What is EMFText giving us for “free” when it is used and how can it be implemented

What does EMFText lack or do in a poorly way

How to improve on the Standalone editor and Eclipse


In this project there are already two other editors that a developer can use when working with the ThingML language, one is the standalone editor made just to have something easy to work in and with. The second is the Eclipse editor that you automatically get when using EMF and EMFText to generate a domain-specific language.

The question then is how is it possible to improve on what there already is. Let us start on the easiest task, to improve on the standalone editor. The standalone editor was primarily made to show of the language and implement the compile for the different languages.

In summary the two editors we already have are very different. So to improve on both of them may be a challenge, as the Eclipse plugin improves on all the ways the standalone editor lacks. The main question then is how to improve on the Eclipse plugin. 

0 notes

EMFText vs Xtext: Why are we using EMFText - Difference of EMF and EMFText

Article relevant to this subject is the “Create a DSL in Eclipse” by Christopher Guntli. Here he discuss how to make a DSL using Eclipse and in turn present a nice comparison of Xtext and EMFText. He also points to another great comparison done by Petter Graff the co-founder of SciSpike over at his blog In these three blog posts he talks short, but thoroughly about the topic.

What do they have in common?
Xtext and EMFtext are both using ANTLR (ANother Tool for Language Recognition, ANTRL is open source and is probably the most known parse generator for at least LL grammars) as parser (instead of for example the java only jFlex). They both create Eclipse ready plugins with built in parsers. In the end you end up with the same product, it is only two different ways of building a domain-specific language. So the question should rather be formulated as what does working them have in common. Firstly let us look at each of them individually.

EMFText is built on top of the models generated by Eclipse Modeling Framework. And uses that model to built a syntax to describe the domain-specific language. Works with the EMF xml-schema Ecore used to define object models. When developing with EMFText the developer need to be familiar with EMF and need to make a model of the DSL. Using the graphical Ecore UML class diagram builder is an easy way to build the model if not generated or given by other systems. Using only the model to generate the language gives you a bracket looking language (show an example figure). You can use the syntax definition tool (.cs) given by EMFText to define your own syntax by modifying the keywords. EMFText does not come integrated with a code generator or other transformer technologies, but instead let the user decide which one to use. This is often preferred if there are no need for a code generator or transformer, as you save the time needed to remove the generator or transformer from the generated Eclipse-plugin.

Xtext on the other hands derives everything from a description of a concrete syntax language. In other words, the abstract and concrete syntax is written together. Therefor there are no need for the EMF model (even though you can generate it using Xtext). You start of by defining your grammar and Xtext generates the rest for you. Adding constraints to the syntax is easily implementing by creating a Java class and since everything is done by dependency injection Xtext takes care of the generation and interaction with the editor. When it comes to code generation and transformation Xtext uses Xtend and Xpand, so if you want to use another technology you need to deconfigure and reconfigure the project. Meaning that if you want code generation or transformation your best bet is to stick with Xtend and Xpand. In short you can say that Xtext uses one file to handle the abstract and concrete syntax.

0 notes

Why should simplicity get primacy over features/richness?

This is a rather good question and stems from how the user interact with the tool/workbench. Eclipse is a somewhat feature rich tool having solutions to most of the common and uncommon problems encountered while developing. It also help the developer to speed up developing time. This is done by different plugins or extensions that are implemented in the editor. Which of course are all editable. The problems with all these extra features are that the user needs to learn how to best utilize the different tools/plugins. This is an manageable task for an experienced user already familiar with the features of an IDE, but a inexperienced user (novice in other words) may and probably will struggle the first times using an IDE such as Eclipse. And therefor in the beginning will have problems using the features that the given tool support. That is one of the reason for why simplicity should get primacy over features. As an introduction to a new tool (language in our case) rather should focus on what the user really needs and not what the tool really can do, and then represent that in an easy and understandable way. A good example is the thought behind the early Apple mouse where there where only one button for the user to click on. Since Steve Jobs meant that the user should not need the extra choice or be disturbed by them while working. Often refereed to as a single button control interface. Other examples are the Processing and Arduino tool, that focus only on the representative language. As an editor they are pretty weak, but they give the novice user an easy start by not giving them much options other then; writing code, compiling code, and look at examples. As a novice that is mostly what you need. A different example is teaching, as most teaching focus on the important part and try to describe or teach them in a simplified form. Then later when the student have gotten a broader understanding of the problem, more detailed information is given.

0 notes

Things to write about

I haven’t spent much time thinking about what to write about, but I did spend some time last week on reading some articles about editors, compilers and other interesting master related subjects. For now I just want to list up some topics that I my need/should write about.

  • EMFText vs Xtext: Why are we using EMFText
  • Difference of EMF and EMFText
  • What is EMFText giving us for “free” when it is used and how can it be implemented
  • What are the benefits of using EMFText
  • What does EMFText lack or do in poorly way
  • How to improve on the Standalone editor and Eclipse
  • Why should simplicity get primacy over features
  • How to improve on Eclipse with proper Project Management
  • Project Management and Maven builds

I will try to write at least some lines on each of these topics before the semester starts next year, but first I will write a short summary of all the new articles I’ve read.

0 notes

Just a quick update since I haven&#8217;t had much time to work on my master the last week. What I have done is to change the icon to something more smaller (a lot!), and I&#8217;ve implemented better save function. So now when you try to close the application it will check to see if all the files are saved, and if not ask you if you want to save them or not. I&#8217;m also working on minor tweaks to make the ThingML experience better. This is also a very time consuming task with little of visible earnings.

Just a quick update since I haven’t had much time to work on my master the last week. What I have done is to change the icon to something more smaller (a lot!), and I’ve implemented better save function. So now when you try to close the application it will check to see if all the files are saved, and if not ask you if you want to save them or not. I’m also working on minor tweaks to make the ThingML experience better. This is also a very time consuming task with little of visible earnings.

0 notes

The perks of being an editor

I had written about ten lines of text before Opera decided to break down, which in turn removed my post since Tumblr doesn’t auto-save. So I was talking about the features that are needed in the editor in the last post, and here I will talk about what the extra features I’ve added. They are not on my “need to have list”, which you can read about in my Master essay (I will post it in the next one). These features are the ones that make your life easier and you kinda take for grated are in an editor. Which doesn’t make them easier to implement.

  • Cut/Paste/Copy: These features are usually done native by the OS, but I thought that I should add buttons for each action since not everyone know or remember the shortcuts for them.
  • Open/Save/New: The two first actions are essential for an editor to work. The last one, not so much. As you are rarely making a new file that you don’t want to save. The original ThingML editor didn’t support this, and it was something we really missed. So every time you wanted a new file, you needed to exit the program, create the file in the OS and open the program again. And saving was automatically. Which is not really a bad feature, but it’s good to have the option. For now in the new editor you can open files, save file, and create new empty files without a name.
  • Compile: For now you can only compile to Arduino, but this is just temporarily and I will add a dialog asking you to check the languages you want your ThingML code to be compiled to. For now the compiler supports; Arduino, Scala/SMaC, Posix C, ROS Node, Java/Swing, ThingML/Comm, ThingML/Comm2, Scala/CoAP, Java/Kevoree, Experimental/PauWare. Also where the output folders for all the code that will be deployed. I’m also thinking of making a separate folder for each language. So it doesn’t become a mess when you choose all of them. I have personally only tried to compile to Arduino, and when you do it will open up the Arduino editor (if it’s on your system) with your code. So I’m thinking about adding another option if you want to just create Arduino code, or if you also want to open Arduino. When you hit compile and check the languages you want, the editor (if it’s the first time you try to compile a file) will ask you for the configuration file. Since the configuration file contain a link to the ThingML file it needs to know that first. There is also possible to have the configuration in the top of your code file, but that is not working in my editor now. This is something that I need to implement later.
  • Tabbing: Every good editor should let you have several files up at ones. And there are several ways to do it. I’m personally a fan of using tabs. As it gives an easy and a clear overview of the files you have open. For now I’m not sure if you will have that many ThingML-files open in one project, but you need to create your configuration-file by code for now. So that is at least two files.
  • Samples: One thing I really like about the Arudino and Processing editor is the waste option of samples you can try out. So that’s why I chose to implement a menu with four different samples (more is probably coming). All of the samples will (in the end) have their configuration file mapped to them, so you don’t have to find them when you want to compile them.
There are also some features that need to be implemented that are yet not there. Such as;
  • Auto-save: Auto-save can be a very useful tool. Letting you write and not worry about saving. Haven’t thought much about how I should implement it yet, but I’m probably going for something like every time you do an action outside the text area, or every five minute or so.
  • Close tabs: This is a must have feature, as it would just be silly if you had to close the editor to close the tabs. Going for the normal ‘x’ in the corner and let people using the “alt+w” shortcut.
  • Search/Replace: Another must have feature, letting people search for words in the text and replace them if they want to. Not sure when it will be implemented, as I’m going to try some “refactoring” which require the use of search and replace.
  • Project file: Project files is to help the user coding to manage a single project and what files belongs to it. The project file will also keep track on the main configuration file, so that you don’t have to keep finding it every time you want to compile. In the end I also want to add the possibility to just open the project file and automagically open all the .thingml files.
Guess that’s all for now. If you have any suggestion for features the editor should have, please let me know!
0 notes