- “jep” allows to provide cross editor support for any textual language
- “jep” allows to deploy editor support with a software product rather than with an editor or editor plugin
- “jep” is an open protocol rather than a piece of software
- “jep” is work in progress and the protocol is still a draft and far from being complete. We appreciate to hear about your use cases, ideas and feedback in general.
- “jep” has a vision
The are lots of very specific textual languages out there for which no general editor support exists. This includes configuration languages, domain specific languages (DSLs), internal DSLs but also some programming languages. One reason for this is that it’s simply too much work to broadly build editor support. While the core users of a language might spend the effort to build support into their favourite editor, other editors will probably be neglected.
When editor support is actually available by means of some editor plugin, there is still a potential versioning problem. The version of the language supported by the plugin may be different from the version of the language actually used. This is especially likely if different versions of a tool and its associated language are used in one project. In particular, internal DSLs evolve over the lifetime of a project and when working on an old branch of the software, language support should reflect this properly.
The basic idea behind “jep” is to separate editor support for a particular language from the actual editors. The “joined editors protocol” is the link between editors and languages. Ideally, there should be one single “jep” plugin for each editor and one single support logic for each language.
The protocol is open in the sense that it’s publicly available and any editor plugin or language developer may choose to implement it. Since it’s based on very common technology like sockets and JSON, implementation should be easy across programming languages and platforms.
“jep“‘s level of abstraction is pretty much the same as the one of most editor plugin interfaces. There are hooks for auto completion and jumping to definition as well as a way to display error annotations and to define syntax highlighting. This very generic approach leaves maximum freedom for developers to implement the language support. They may reuse existing parsers to find errors. They may choose to implement auto completion by simple heuristics and regular expressions. Or they may choose to work on an AST or some other kind model.
A very simple workspace concept associates a file being edited with a backend process started by an editor plugin. Again, the developer has maximum freedom to design the backend process, its command line interface and the way to tell the process which files belong together in one “workspace”.
The “jep” protocol defines the interface between editor frontends and language backends. This is work in progress and currently in a draft status. Our approach is to start with a simple and consistent set of features and later evolve the protocol to support more things like custom command invocation.
Currently we are working on plugins for VIM, Emacs, Eclipse and Visual Studio. Check out the plugins page to learn more about plugins.
“jep” is an abstraction of the cross editor approach of RText towards arbitrary syntax. As such, we plan to make RText use “jep” at some point. See the languages page for languages already using “jep”.
“jep” was initiated by Martin Thiede as an abstraction of the RText approach. RText is a generic framework for languages derived from ECore metamodels. It’s in use in a number of tools in automotive software development. “jep” is generously supported by E.S.R.Labs