Emacs vs Eclipse Che

Emacs can be controlled entirely with the keyboard. While true, I often find the mouse and menus handy for those lesser-used commands. An aide-memoir.

Customizations can be made to a wide range of Emacs' functions through a Lisp dialect (Emacs Lisp). A robust list of existing Lisp extensions include the practical (git integration, syntax highlighting, etc) to the utilitarian (calculators, calendars) to the sublime (chess, Eliza).

You can debug, compile, manage files, integrate with version control systems, etc. All through the various plugins that can be installed.

Licensed under GNU GPL.

Emacs has extensive help support built-in as well as a tutorial accessed with C-h t.

You can use Emacs' command line interface or graphical user interface.

With 30+ years of use the Emacs documentation is very thorough. There are also a lot of tutorials and guides written by third parties.

Fully compliant GNU-emacs is available on many platforms, and they all understand .emacs configuration files.

With lisp customization, any behavior of Emacs can be changed. Update with pre-release patch can be also applied without recompiling the whole Emacs.

Dynamic word completion.

Advanced planning and publication which can start as a simple list.

You can pass complicated arguments in the mini buffer.

Through its programmability, a very broad range of functionalities can be integrated in emacs, turning it even into a "single point of contact" with the underlying operating system.

Emacs can select rectangularly.

Evil mode emulates vim behaviors within Emacs. It enables Vi users to move inside the Emacs universe.

The first verion of Emacs was written in 1974 and GNU Emacs in 1984.

Evil is an extensible vi layer for Emacs. It provides Vim features like Visual selection and text objects.

Review the "Emacs Rocks" video.

Works on Linux, Windows, Macintosh, BSD, and others.

You can jump straight from your org-mode files to programming tasks - and back - and build a seamless workflow.

Powerful commands, search, and more with the Helm plugin.

Emacs is great for everything.

Since version 25 you can run GTK widgets inside Emacs buffers. One of these is the WebKitGTK+, which allows the user to run a full-featured web browser inside Emacs with JavaScript and CSS support among other things.

The tutorial you are presented with at startup shows you exactly what you need to get started and teaches you how to use the built-in help yourself later.

Emacs has a number of shell variants: ansi-term, shell, and eshell.

Managing several large mailing lists has never been easier using Gnus. The threading commands and the various ways of scoring articles means that I never miss important messages/authors, etc. A joy to use.

You can use the underlying operating system shell as a terminal emulation in an Emacs buffer. Don't like the default shell for your configuration? You can change it to your liking.

Built-in packages make editing Lisp source code feel natural.

Missing some neural package that predicts actions
Maybe in the next release ...

Built-in terminal with root access so you can make changes to your running machines. Being able to SSH into the workspace so you can use a desktop IDE is handy.

You can package up custom commands with your workspace and then use them (or share them) with everyone else.

You can choose from pre-configured environments for Java, Javascript, C++, PHP, C#, etc., or you can define your own by dropping in a Dockerfile - makes it easy for simple and complex projects.

Projects can be easily imported from any Git or Svn repository hosting service.

The workspace in Che includes project sources, IDE and the runtime. So if you hand your Che workspace definition to another user and they execute it they will get everything they need to build, run and debug the project.

Also the runtime is in a Docker container so it will work even if the second user is on a different OS than the original user who shared their workspace with them.

Che does a nice job to automatically map the service:port running in the Docker container (e.g. tomcat on 8080) to the Docker port it actually uses (something in the ephemeral range). You never need to figure that out - it's just made available when you run your server.