Standard interface between a text editor and an IDE?

You may probably consider this a rant post.

Problem definition

Long time ago, I used to edit code right in my IDE. For example, assume I work on some Qt project, so, Qt Creator is the IDE I use. I use it for rather long time, so I learned its text editor shortcuts, learned how it behaves, etc.

And one day, I need to work on some Java project. Okay, so I pick Eclipse, or NetBeans, or something else. And, whatever the case, I find it painful, just because I learned how to work in Qt Creator's text editor, and it is convenient for me. So I dig deeply inside the editor's preferences, trying hard to emulate the behavior I'm familiar with. I even try to come up with some color scheme to mimic that of the IDE I used to work with.

It's hardly possible to emulate the behavior completely. So the next step is probably to try some other IDE, just because I don't like the text editor of the IDE we're trying to use now.

As I said before, I find this process of accommodation to IDE's text editor painful. And actually, it's ridiculous: we switch IDEs just because we don't like its editor! Pfff. The IDE may have perfect tools for refactoring, for code navigation, it may fit extremely well in everything else, but I'm still unhappy, because I'd like my text editor to behave differently, or to look differently.

All of this led me to Vim, several years ago. I wanted single, universal, cross-platform text editor; Vim is one of such beasts.

I'm definitely more happy now than I used to be before I met Vim: I always edit code in the same text editor. That's great, but every time I need to run my project, or debug it, or add/remove files to/from project, or perform some complicated refactor, I switch to an IDE, and do what is needed there. For embedded projects, this is MPLABX; for Java, it's usually Eclipse; for Qt, it's Qt Creator, etc.

Vim is a great text editor, but, still, I have a lot of headaches: I want code auto-completion inside my editor, I want to check syntax without leaving my editor, I want to build and run project from within my editor, I want to navigate to some function's definition, etc. For each of the platforms I work with, I have to invent something new: google some Vim plugins, try to set them up, write something on my own, trying to make Vim to accommodate to some particular IDE. For example, I currently ended up writing rather hackish Vim plugin that parses project files of various IDEs (be it MPLABX, or Qt Creator, etc), fetches list of project's files, various options, and makes Vim more or less aware of the project I'm working on.

I also had to invent plugins that allow me to navigate code and to manage per-project options, since I wasn't satisfied with other solutions I've come across.

A lot of headaches. I've spent enormous amount of time setting things up. And all of these troubles could be probably eliminated by some open standard on text editor ↔ IDE interoperation.

Possible solution

The thing is that IDE should not include text editor. Well, it might include one, just to be more self-contained, but the text editor shouldn't be a major part of an IDE: instead, there should be an interface that both parties (IDEs and text editors) should agree on.

A programmer's text editor has some limited number of must-have features in virtually any field these days. Off the top of my head:

  • Code auto-completion;
  • Code navigation (jump to definition, etc);
  • Select/add/remove project files;
  • Build file or just check syntax, navigate build errors;
  • Build/run project;
  • Maybe debug facilities: set breakpoints, run, step, etc.

Wouldn't it be great if we can open any editor (Vim, Emacs, Sublime Text, etc), bind it to any particular IDE that we need, be it Qt Creator, Eclipse, or whatever, and immediately get all of the IDE luxuries, like code auto-completion, and so on? Without any hackish plugins that try to mimic IDE behavior?

That sounds great, to me.

And, by the way, this is an important part of the Unix philosophy:

Write programs that do one thing and do it well. Write programs to work together.

There are people who agree with me, and they try to change the world: look at the Eclim project by Eric Van Dewoestine. “Eclim” stands for “Eclipse + Vim”: as you might have guessed, it allows Vim to bind to Eclipse, and get all the power of an IDE inside Vim.

I use it for my Java projects: I can't imagine efficient software development among tons of APIs (that Java has) without rich auto-completion, and Eclim solves this trouble for Vim (and other editors, too: as far as I know, there are ways to make Eclim to work at least with Emacs). In Vim, when I press a dot in in Java source file, Eclim performs a request to the Eclipse that runs in parallel, Eclipse returns all the auto-completion data for the given position in code, and Vim displays convenient pop-up menu.

PlantUML Graph

It works flawlessly, very fast and exciting.

Eclim also supports build error handling, refactoring, and a lot of other IDE-related actions. It's not perfect of course: I even submitted a couple of patches to make it better, and now I use it heavily.

Still, it is a kind of hack. Neither Eclipse nor Vim developers care about Eclim (in general).

I'm really surprised by the fact that this topic receives so little interest. As I already mentioned, what's needed is a standard interface for IDE ↔ text editor interoperation, that all mature IDEs and text editors should agree on. Then, we would use our favourite single editor for whatever we're working on. The transition to some new field will be much more smooth, as we still feel “at home” in our editor.

I think, that would make a lot of programmers happier, and, as a consequence, make our software better.

Discuss on reddit:

Discussion

skadge, 2015/10/09 21:34

A bit different but possibly relevant: You may be aware of neovim (https://github.com/neovim/neovim) that started as a fork of vim, and targets several key structural change, including making vim a… library that other IDE/editor could embed.

Dmitry Frank, 2015/10/09 21:49

Yes, neovim is a very promising project, thanks for mentioning it.

Haven't tried it seriously yet, but maybe I'll do that soon, because recently one of their FAQIs it ready to use?” had an answer like “Not yet, the work is in progress”, but now, they have changed it to “The project is still undergoing frequent changes, but many people use it for their day-to-day work”.

Francis Kim, 2015/11/03 04:40

Was just about to mention NeoVIM. I've only heard good things about it.

Andrew Nambudripad, 2015/10/10 06:29

This is basically the theory behind ACME and Plan 9. _Everything_ has a file system fd attached to it. From files to processes, if you have access rights to the fd, you can pipe to it. Watch Russ' talk on Youtube about ACME and it basically describes everything you're asking for. And it can be run on top of Linux too, exposing components as FUSE mountable entities.

Microsoft has Roslyn which is basically the “guts” of a compiler in it, and I'm pretty sure most of it is Mono-compatible (i.e. cross platform for *nix). From there, not only do you get that 'separation of concerns' you desire, but you also get a lot of semantic and syntactic code benefits (access to the AST, language modifications become possible).

I haven't used LLVM much so I don't know specifically where to hook in, but I bet you can rip out the “guts” (elegantly at that) of either the front-end (be it clang or LDC, or what have you) and get your editor to talk to it as well.

To answer your question: it's a good concept, especially as executed by plan 9. But the practical reason why you won't see it is engineering anything is hard. Engineering robust API's that will work cross-platform, cross-language, cross-environment (think of all the plugins that exist.. where do they fit into your diagram? Do you just add it as more middleware before the compiler? After?), and support the customisations end-users want (keybindings, fonts, spaces or tabs?).

I love the idea, and I love the execution Plan 9/ACME managed to use (you can feel it's influence in Golang too). I'd take it a step further and basically make it language agnostic. I.e, instead of commiting your source-code change to the tree, you commit the compiler front-end's AST output. Completely language agnostic. (In fact, Visual Studio solutions in larger companies, I've seen F#, C#, VB.NET and a home-brewed SMT all working nicely together)

The real problem is political, resource based, and monetary. Political because a program manager who just does “enough” to get this project out the door will think a new paradigm is scary. Resource based because Eclipse and Visual Studio is “good enough” for the industry and everyone knows it, so when Joe leaves, Sue can jump in and fill the role. Monetary, There's no impetus to change over. Atom.io and Light Table are both interesting experiments but $money_saved_from_problem_solved > $money_to_engineer_retrain_recode, the shift won't happen on a large scale.

But really, look at ACME. The editor within the Plan 9 OS basically does exactly what you want, and has been doing it for 20 years.

Stuart Axon, 2015/10/10 08:03

YES! This is definitely needed.. having built a plugin for gedit, it's annoying that do the same thing I'd need to port to a different API for sublime text, eclipse, pycharm etc.

Maybe in the meantime some sort of wrapper can be made for common operations - like add menu items, icons, be notified of buffer changes etc ?

Olliwood, 2015/11/03 05:27

You Can have all these Features in vim…

Have a Look at https://github.com/carlhuda/janus or vim-go if You do not know how to set it up…

Stanislav, 2016/04/08 13:14

I like to use Codelobster - http://www.codelobster.com. It is very light-weight IDE.

Tom, 2016/04/18 16:25

This is a fantastic idea, although perhaps too fantastic an idea to ever see the light of implementation. But I do imagine that extension implementers would also want such an interface, so maybe there is still hope. An API where every feature of the IDE is accessible in a standard way would be very powerful.

I see a great need, especially in the embedded world, for a unified platform. It's already a large effort to get up to speed on a new hardware platform, so why add to the pain by essentially forcing engineers to also learn your entire development environment as well? I get the need for a few product-specific tools to help with pin selection/muxing and peripheral initialization, but having an IDE for every chip manufacturer is completely unnecessary. I also believe that a standard way to manage projects would be desirable, seeing as most IDEs seem to try to do the same thing (in different ways).

I, for one, wish that all programs would provide some sort of an API or hotkey configuration for their UI functionality. Programs like Excel just beg for a vi-like modal interface (if you haven't, you should check out the sc terminal program). I know there is a third-party program that does just that, but a native ability to adjust the UI would be far better. The more consistent I can keep my UI the more productive I am going to be.

My current efforts to achieve UI consistency are as follows: Right now I am running vim under tmux under cygwin on Windows 7 as my “IDE”. I use the bug.n tiling window manager with arrows remapped the vi way to make switching between programs effortless, and for browsing I run chrome with the vimium extension. The standard desktop + GUI environment doesn't even come close to this. I hardly touch my mouse. My thoughts aren't interrupted by having to alt-tab through open programs or rearrange my windows manually. Virtual desktops are far superior to the taskbar, especially when you have a tiling window manager. I can have up to 9 virtual desktops on each monitor, so I keep applications related to a single task on their own desktop. I can't imagine working without a tiling WM, or at the very least some type of virtual desktop.

Enter your comment (please, English only). Wiki syntax is allowed:
  __  __   ___    __ __   ___    ___ 
 / / / /  / _ \  / // /  / _ \  / _ |
/ /_/ /  / , _/ / _  /  / , _/ / __ |
\____/  /_/|_| /_//_/  /_/|_| /_/ |_|
 
blog/2015/1009_why_we_still_don_t_have_any_standard_interface_between_a_text_editor_and_an_ide.txt · Last modified: 2015/10/12 13:03 by dfrank
Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0