New and Noteworthy in Orion 13.0

With Orion 13.0 released (just in time for the holidays), it is time again to share with you the new & noteworthy items developed during this release. There are lots of changes across all of Orion, so lets dive in to each area and see whats new.

Accessibility

We have been striving to make Orion as accessible as possible to all developers. In Orion 13.0 we have improved accessibility across the board – from standard labels to the code edit widget and everything in-between. We still have a ways to go, but plan to be fully accessible in Orion 14.0.

Code Edit Widget

The code edit widget just keeps getting better and better. In Orion 13.0 two great things happened: (1) You can finally see the keybinding dialog, and, (2) you can now add your own custom code folding!

To jump right in and start enhancing your use of the widget with some cool folding, check out the docs.

Electron

We have created an experimental version of Orion that runs as an Electron app!

The Experimental Orion Electron app

The experimental Orion Electron app

Currently, to use the app, you have to build and run it locally (we are working on providing regular builds of the app).

Language Server Protocol

A lot of work has gone into investigating and supporting the language server protocol since its announcement last summer.

In Orion 13.0 we have experimental support for the LSP and for Java that can be used on your local machine. For full details on how to get up and running, see this great readme.

Language Tools

Lots of cool new stuff is available in the language tools in 13.0.

Linting

We have provided 13 new linting rules (a coincidence, I promise), such as, no-extra-bind and no-implicit-coercion. The complete list of rules added in 13.0 can be found on our rules wiki.

The no-implicit-coercion linting rule

no-implicit-coercion (with fix)

To accompany the new linting rules, many new quickfixes have been added as well, allowing problems to be quickly and easily resolved.

The quotes linting rule quickfix

quotes rule quickfix

To keep all of the rules running smoothly, we also updated to ESLint 3.0.1

ECMA 2016

Orion 13.0 ships with complete support for ECMA 2016. To start developing using the new language features, you have to make sure to set the ecmaVersion entry in your .tern-project file to 7.

ECMA 2016 example snippet showing content assist

ECMA 2016 example

AST Outline

A lot of times, while working on language tooling features, developer have wondered what the backing AST looks like (to help diagnose whats wrong). In Orion 13.0 we have provided an AST outline for JavaScript, to make this task easier.

You can see the new outline using the View > Slideout > AST Outline menu item when working in JavaScript files.

The AST outline showing a simple snippet

AST outline

Code Formatting

One of the most sought-after features of an IDE is the ability to quickly fix the shape of code. One of the easiest ways to do that is code formatting. In Orion 13.0 we provided a platform API (orion.edit.format) to add formatting to any language, editor hooks to format-on-save, support to format selections of code and support for .jsbeautifyrc files (for project-level formatting options).

Orion ships with four language formatting implementations: (1) JavaScript, (2) HTML, (3) CSS, and (4) JSON.

Formatting can be used in one of three ways:

  1. Format-on-save: head into the editor options to enable this feature, then, as you save your work, it will also be formatted
  2. The Edit menu item: look for Format Code under the Edit main menu
  3. The pop-up menu: look for Format Code in the pop-up menu in the editor
Format code popup menu from the editor

Format code in editor

Not happy with the way the formatted code looks for JS/HTML/CSS/JSON? Simply head over to the formatting preference pages for each language and change the settings as desired.

The page with CSS formatting options on it

CSS formatting options

HTML Validator

In addition to updating our HTML parser in Orion 13.0, we also provided a pluggable HTML validator to help you keep your page source in tip top shape.

Example HTML validation

HTML validation

Like all our other validation, you can configure the HTML rules severities. The settings are found on the HTML Validation settings page.

Improved Internationalisation

All of the linting messages coming from the CSS tooling can now appear in other languages than English.

Updated Libraries

As we do each release, we have updated many of the libraries we use in our language tools. This time around we updated the following:

  • ESLint to 3.0.1
  • Doctrine to 1.2.2
  • ESTraverse to 4.2.0
  • Acorn to 3.3.0

Platform Improvements

Syntax Styling

Orion 13.0 has improved syntax styling support for many of our existing languages (like PHP and SQL) and also adds support for .sh files

Excluded Files

Any callers of the search API (via the file client) can now specify an array of names to be ignored by the search engine. This allows callers to ignore all kinds of things they don’t care about while speeding up the search for things they do.

The new property is named ‘exclude’ and is an array of strings. See the API doc for more information.

Filtered Resources

Sometimes there are things you just don’t want to see in your workspace (or that you shouldn’t see). In Orion 13.0 we provided the ability to filter / hide resources from appearing in the UI.

The preference for this is on the General settings preference page and is a simple comma-separated list of names of things to not show.

Shows general settings page and hidden resources preference

Resource names to hide

Light Theme

Orion now sports a shiny new light theme!

But don’t worry if you really really liked the old theme, in Orion 14 we are bringing back the theme preferences to allow this to be customized.

Posted in New & Noteworthy | Tagged , , , | Comments Off on New and Noteworthy in Orion 13.0

Announcing Orion 13

We are pleased to announce the thirteenth release of Orion, “Your IDE in the Cloud”. You can run it now on OrionHub or download the server to run your own instance. Once again, thank you to all committers and contributors for your hard work this release.  There were over 180 bugs and enhancements fixed, across more than 350 commits from 13 authors!

What’s new in Orion 13?  The Orion 13 release continues to emphasize our language tooling.  In particular, we now have code formatting, support for .jsbeautifyrc files and full ECMA 2016 support.  We have also been investigating LSP and have some experimental work in place to support Java, but this is not yet generally available.

The other focus of this release is consumability and accessibility. To make Orion easier to use for end users, admins and everyone in between, we substantially improved the node.js server (which is used on orion.eclipse.org or locally), created an experimental Electron app version of Orion, improved accessibility, enabled custom code folding in the code edit widget and a whole lot more!

Enjoy!

Posted in Announcements | Tagged , , | Comments Off on Announcing Orion 13

Google Cloud Shell adopts the Orion Code Editor

It’s nice to see Google Cloud Shell using Orion in their latest offering. Google Cloud Shell is just that: a shell (really a bunch of shells) to a machine in the cloud. The machine contains source files (go figure) and Orion is great at editing files, syntax coloring, code assist, refactoring, dynamic linting and much more.

This is how you get to Orion in Cloud Shell:

google-cloud-editor-launch

Here is Orion running in Google Platform Shell:

google-cloud-editor-orion

I am reminded that IBM makes extensive use of Orion as a code editor in Bluemix DevOps Services and that we should really blog about that again soon.  Development in the cloud for the cloud!

Steve

Posted in General | Comments Off on Google Cloud Shell adopts the Orion Code Editor

New and noteworthy for codeEdit widget 12

Orion codeEdit widget debuted just one year ago in Orion 9.0. Thanks to all the valuable user feedback over the past year, now in Orion 12, the widget has been improved a lot for both usability and customizability. We’ve updated the widget wiki page to include the latest features, summarizing user feedback in the FAQ section.

The codeEdit demo page shows you two of the biggest improvements in the widget: customizable editor configurations and fine tuning your web language tooling. In Orion 11.0 we introduced tern project – now this feature is integrated into the widget. In the demo you will see a zoom ruler in each editor, enabled by an editor configuration change. You will also see how the javascript file validation behavior changes while live editing the tern project and eslint rule files.

Aside from that, there are other major improvements that are not shown in the demo.

With all the improvements so far, we found it’s been much easier for the existing users to consume and customize the widget. We are still improving in other areas so please stay tuned.

Posted in General | 1 Comment

New and Noteworthy in Javascript tooling for Orion 12.0

As noted in our Orion 12.0 announcement, a tonne of work has gone into this release of Orion.  Over 350 Bugzilla reports were fixed.  Here are some of the many things we have been working on for the JavaScript language tooling.  Expect more in-depth looks at these items in the next few weeks.

Cross-file linting

The ESLint based validation in our JavaScript tools up to Orion 11 was only focused on the single file you were editing.  No consideration was given to the rest of your project setup.  With 12.0 the linting is now aware of the other files in your workspace and the project configuration you have set up.

  • no-undef: Warn when a global variable has not been defined
  • no-undef-expression:  Warn when a function (member expression) has not been defined
  • no-unused-vars: Warn when declared variables are not used.
  • unknown-require:  Unknown required library
  • type-checked-consistent-return: Discouraged inconsistent returns

So we can now in many cases tell you that you are using a function that doesn’t exist.  Especially helpful when you mistype the name or use the wrong casing.

Make the tools consumable

We have created a new API and webpack build that will package up the JavaScript tooling in one consumable bundle that can be used to drive language plugins for other IDEs, such as Brackets or Atom.

A deep-dive into the new API is coming in a subsequent blog post. To get a jump on it, we have provided two wiki pages: (1) JavaScript tools API and, (2) Building the JavaScript API.

Improved Tern integration

In Orion 12.0 we moved the remainder of our client-side services to be Tern plugins.

These new plugins include:

  1. ESlint
  2. Occurrences
  3. Templates / templating
  4. Quickfixes
  5. Outlining

The move to be more Tern-centric with our features carries many benefits, but most importantly it allows us to cut down on message passing, improve memory use and make the features more portable.

ECMA 2015 support

Orion 12.0 supports all of the ECMA 2015 specification like arrow functions, import/export statements and classes.

The tooling completely understands the new language syntax with new quick fixes and code templates also being available to get you started.  The linting rules have also been updated to respect the new ECMA 2015 code patterns.

Outlining has been updated:

ECMA 2015 outlining support

ECMA 2015 outlining support

Occurrences has been updated:

ECMA 2015 occurrences support

ECMA 2015 occurrences support

Linting has been updated:

Lint rules updated for ECMA 2015

Lint rules updated for ECMA 2015

We also support import and export statements which require the source type to be “module”. This is set through the .tern-project file – and you can use a handy quickfix to write it all for you.

Change sourceType quickfix

Change sourceType quickfix

Support for ESLint project configuration files

Users can now include .eslintrc files in their projects.  These files can configure all of the ESLint settings that your files are validated with, including rule severities.

.eslintrc file example

.eslintrc file example

When this file is present, the rule values will override any workspace settings.  If you go from editing your project to changing settings the page will warn you that an .eslintrc file is present.

Preference warning banner for .eslintrc overrides

Preference warning banner for .eslintrc overrides

We support other forms of ESLint configuration too, such as settings in package.json. There is a hierarchy of configuration files that you can use. Read the full details on ESLint’s configuration page.

Package.json ESlint configuration section

Package.json ESlint configuration section

Support for in-project definition files

You can define and use your own definition files in your project. See the file IndexCreation.md to find out how to proceed.

Tern index file example

Tern index file example

The tooling will include all the type information found in your definitions to improve content assist, tooltip hovers and more.

Content assist for example in-project index file

Content assist for example in-project index file

Updated third-party libraries

Most of our third-party libraries have been refreshed:

  • Acorn 3.1.0
  • Doctrine 1.2.1
  • ESrecurse 4.1.0
  • Estraverse 4.1.1
  • Escope 4.2.0
  • Tern 0.18.0

A notable change to our consumed library lineup is that we have discontinued use of the Esprima parser in favour of Acorn.  There are many reasons for the switch, but the main reasons are:

  • Acorn has complete ECMA 2015 support (with recovery for most of it).
  • We can easily extend the Acorn parser via its plugin mechanism, so there is no need to edit parser code to have our Orion customizations.
  • Acorn has robust recovery support right out of the box (no more editing the parser to hack our own in).
Posted in New & Noteworthy | Tagged , , , , | 1 Comment

Announcing Orion 12

We are pleased to announce the twelfth release of Orion, “Your IDE in the Cloud”. You can run it now on OrionHub or download the server to run your own instance. Once again, thank you to all committers and contributors for your hard work this release.  There were over 350 bugs and enhancements fixed, across more than 900 commits from 22 authors!

What’s new in Orion 12?  The Orion 12 release continues to emphasize our JavaScript tooling.  In particular, we now have full support for the ECMA 2015 spec, vastly improved project configuration capabilities, support for eslintrc.* files and much much more!

The other focus of this release is consumability. To make Orion easier to use for end users, admins and everyone in between, we created an experimental node.js server (which can be used on orion.eclipse.org or locally), a metrics service for plugins, some super cool updates to the code edit widget and a whole lot more!

Enjoy!

Posted in Announcements | Tagged , , | 1 Comment

Configuring your Orion project

Everyone loves to customize stuff.

In Orion 11.0, we provided support for .tern-project files so you can do just that. A .tern-project file, for those unfamiliar with them, is a configuration file that lives at the root of your project, is entirely JSON, and tells Tern how and what to run with.

Lets see an example file (the one used in the Orion client):

{
  "plugins": {
    "node": {},
    "requirejs": {},
    "express": {}
  },
  "ecmaVersion": 5,
  "libs": [
    "ecma5",
    "browser",
    "chai"
  ]
}

See? It’s not so bad. Now lets talk about what all the parts mean, and why you would want to make one.

The first thing typically asked when talking about these files and configuring your project is: “what if I don’t have a .tern-project file?”. The short answer is; we start Tern with a default configuration that contains every plugin we pre-package in Orion.

The longer answer is:

  1. you get all of the required core services plugins from Orion (like HTML support, parsing plugins, etc)
  2. you get all of the pre-packaged plugins (mongodb, redis, mysql, express, amqp, postgres, node, requirejs and angular)
  3. you get a default ECMA parse level of 6
  4. you get a default set of definitions (ecma5, ecma6, browser and chai)

Basically, everything will work right out of the box, the downside is that you get a lot more stuff loaded in Tern than you might need (or want).

ecmaVersion

This is the most common element that people create a .tern-project file for, and its an easy one. If you are coding against ECMA 6, the defaults are fine. If you are not, its best to change this to be 5.

libs

This entry describes type libraries you want Tern to use. These libraries provide type information that is used for content assist and inferencing. At the moment, only the definitions that come pre-packaged in Orion can be entered in this list, which include  ecma5, ecma6, browser and chai.

I know what you are thinking. What if I have a definition not in the list I would like to use? We are working on support for custom definition files directly in the project, and providing a UI to install new ones.

plugins

This entry describes all of the plugins that you want Tern to run with. As mentioned, by default you get everything. Leave it out? You get everything. Empty plugins entry? You get everything.

Regardless of what you put in the plugins entry, you will always get the core services plugins that Orion needs to function – so no, you cannot break the tools.

While everything will work fine right out of the box with all plugins running – you can really improve the performance and memory usage of the tools if you tell us what support you actually need. For example, working on a node.js project? only include the node plugin. Working on AMD browser project? only include the requirejs plugin. You get the idea – only load what you actually need.

At the moment, the list of plugins that can be enabled is amqp, angular, express, mongodb, mysql, node, postgres, redis, requirejs. And yes, we are working on ways to provide your own.

loadEagerly

This entry is a list of files that are so important, that you just have to have Tern load them when it starts up. All joking aside, this entry is best for pointing Tern at the ‘main’ in your project. For example, say you were working on a web page. You could add index.html in the loadEagerly entry to have Tern automatically load that file and all the dependent scripts right away, so everything was primed and ready to go immediately (as opposed to Tern filling in its type information as you open and close files).

dependencyBudget

Don’t change this entry. Set too low, it will cause dependency resolution to time out (incomplete type information). Set too high, the IDE will wait longer before answering whatever you asked it (content assist, open decl, etc).

So thats it. Those are all of the supported entries that can appear in the .tern-project file. A pretty short list.

You can’t break the tools by setting a bad entry – we have sanity checking that will revert to a “something is wrong, load the defaults” state. We also have linting / sanity checking that will alert you if you have broken something in the file.

Tern project file linting

Tern project file linting

Broke the file and still navigated to another file (or maybe brought in a change from git that broke the file)? We will alert you that its bad in the banner, with a handy link to jump to the file and fix it!

Tern project file banner message

Tern project file banner message

Remember, you can ignore all the warnings (if you really want to) and Tern will still start with the defaults as a safety measure.

Feeling a bit lazy and don’t want to type out a brand new file for your project? Just open up the new (empty) .tern-project and hit Ctrl+Space, which will auto-magically insert a shiny new template for you.

Happy configuring!

Posted in General | Tagged , , , | Comments Off on Configuring your Orion project

Your code has mistakes – We can help you fix them

Orion has powerful linting tools that detect potential programming problems as you type.  Our tooling provides a huge list of rules, everything from basic syntax mistakes like missing semicolons to multi-file function reference checking.  Try out the latest at orionhub.org.

The linting tools are based on ESLint, but we have our own set of rule implementations.  These rules are used to test the code in your editor as you type.  Discovered issues are marked with annotations, squiggly yellow or red underlines reminiscent of Eclipse.

linting1

Hovering over the annotation will give you a tooltip hover with a description of the problem.  In addition the hover may show buttons representing quick fixes.  Quick fixes modify your code to fix the linting problem.  While no quick fix should ever break your code, you can always undo the effects (Ctrl+Z).  Most fixes will automatically fix the code, adding or removing content, but a few will start a rename operation requiring you to type a new name.

linting2

linting3

Some quick fixes also have a ‘Fix All’ option which will fix all instances of that problem in your file.

linting4

Our rule list continues to expand.  We have incorporated rule implementations from ESLint, added rules specific to our translations support, and now we are working at writing rules that use our type inference engine to detect reference problems between scripts.

linting5

If a rule goes against the programming practices your dev team follows, you can change which rules run on the JavaScript Validation settings page.

linting6

If you want to run a linting pass on multiple files you can use the Show Problems command.  Select a file or folder in the file navigator, right click and press Show Problems… (Ctrl+Alt+P).  This will run the linter on all of the files and display them in a table.  You can click on any problem to navigate to it.

linting7

linting8

 

Posted in Tips & Tricks | Comments Off on Your code has mistakes – We can help you fix them

What is new and awesome in Orion 11.0

With Orion 11.0 officially released, it is time again to share with you the new & noteworthy items developed during this release.  Unlike previous announcements we will be posting more in-depth articles about the new functionality and how to use it.

11references

Where is this function used?  Where is it declared?  What if I need to change its signature? Global search is not the only tool for answering these questions if you use Orion 11.0.  Find All References can search through your project or workspace find potential matches and then figure out which ones are actually referencing the function (or variable) you are interested in.  Orion will sort all the matches into reference types and then provide a green check if we are sure this is a matching reference, a question mark if it is a possible reference, or a red X if it is not a reference (but matches the search text).  You can take it a step further and refactor the contents of multiple files at once.  There is a full write-up on Planet Orion with the details.

11jsdocassist

Documentation of your APIs not only is good practice, it makes the existing language tools work better.  When your JSDoc (add it to any function using Alt+Shift+J) specifies the type of a function’s arguments and returns, the tooling can offer more accurate content assist and hovers.  To help you fill in these types we now offer content assist inside JSDoc.

11quickfixall

Our JavaScript linting (based on the ESLint validator) continues to expand with new rules, new quick fixes and more.  Remember that all of the rules can have their severity configured on the JavaScript Validation settings page.  The excited new feature for 11.0 is ‘fix all’, applying quick fixes to the entire file.  Open up a file with warnings throughout and quickly apply safe fixes to clean up the whole file.  There is a lot happening in our validation support during this release and the next, so we will have a more in-depth look at the features in an upcoming article.

 

11ternproject

Many of the JavaScript tools work closely with our type inferencing engine, Tern.  To get the most accurate content assist, correct navigation and detailed hovers it is best to have your project set up in a way Tern can easily analyze your code.  The best way to provide our tooling and Tern with this information is through creation of a .tern-project file.  In the coming weeks we will give a full write-up on how to do this and exactly how it will benefit your project.

11htmlassist

Our tooling for HTML has seen impressive improvements during this release.  The parser we use was entirely replaced with HTMLParser2 providing us with much more accurate ranges and more recovery options for incomplete HTML.  Content assist has expanded to support accessibility attributes, specifically ARIA roles.  We also provide assist for many attribute values, not just the elements and attributes.  See the full write up here.

11tagmatch

We also highlight the selected tag and its matching tag close.  Have Show Occurrences option turned on in the Editor Settings to see it.

The Orion client continues to improve each release.  There were more than 150 bugs fixed during 11.0.  We have updated the libraries that we depend on to pick up their hard work:   Acorn 2.6.4 Doctrine 0.7.1 Estraverse 4.1.1 ESLint 1.9.0.  Our test suites continue to expand, the shining example being JavaScript tools which has 2232 tests and growing.

Try it right now at orionhub.org!

 

Posted in New & Noteworthy | Comments Off on What is new and awesome in Orion 11.0

Announcing Orion 11

We are pleased to announce the eleventh release of Orion, “Your IDE in the Cloud”. You can run it now on OrionHub or download the server to run your own instance. Once again, thanks to all committers and contributors for your hard work.  There were 163 bugs and enhancements fixed, across 435 commits from 21 authors! Thank you to everyone for your hard work this release.

What’s new in Orion 11?  The Orion 11 release continues to emphasize our JavaScript tooling.  In particular, the new References feature allows you to quickly browse and refactor your code.  Think of this capability as a kind of structured search: It finds raw references, then categorizes and weighs them based on how well they match your initial search and finally, provides a prioritized view for you to browse and edit.

Another area in Orion 11 that was improved was git page.  Support for pull requests and the “train tracks” (git merge/branch history) view was added.

Finally, we’ve improved our accessibility support to make it easier for you to write accessible code on the web.

Enjoy!

Posted in Announcements, New & Noteworthy | 2 Comments