Emacsy, An Embeddable Emacs-like Library
Emacsy, An Embeddable Emacs-like Library
Emacsy is an embeddable Emacs-like library aimed at non-textual applications. Make your app more extensible, scriptable, and fun!
Emacsy is an embeddable Emacs-like library aimed at non-textual applications. Make your app more extensible, scriptable, and fun! Read more
About this project
"There are Emacs power-users, then there's this." —Spencer Kormos, @skormos
"It sounds useful." —Richard Stallman
Emacsy is inspired by the Emacs text editor, but it is not an attempt to create another text editor. This project "extracts" the kernel of Emacs that makes it so extensible. There's a joke that Emacs is a great operating system—lacking only a decent editor. Emacsy is the Emacs OS sans the text editor. Although Emacsy shares no code with Emacs, it does share a vision. This project is aimed at Emacs users and software developers.
Emacs has been extended to do much more than text editing. It can read your email, run a chat client, act as your therapist, and more. For some, the prospect of reading email from within your text editor sounds weird. Why would anyone want to do that? Because Emacs gives them so much control. If you are frustrated by a particular piece of functionality, you can disable it in Emacs. Unhappy with some unintuitive key binding? Change it. Unimpressed by a built-in function? Rewrite it. And you can do all that while Emacs is running. You don't have to exit and recompile.
The purpose of Emacsy is to bring the Emacs way of doing things to other applications natively. In my mind, I imagine Emacs consuming applications from the outside, while Emacsy combines with applications from the inside—thereby allowing an application to be Emacs-like without requiring it to use Emacs as its frontend. I would like to hit M-x in other applications to run commands. I would like to see authors introduce a new version: “Version 3.0, now extendable with Emacsy.” I would like hear power users ask, “Yes, but is it Emacsy?”
This project was inspired by my frustration creating interactive applications with the conventional edit-run-compile style of development. Finding the right abstraction for the User Interface (UI) that will compose well is not easy. Additionally, If the application is a means to an end and not an end in itself (which is common for academic and in-house tools), then the UI is usually the lowest development priority. Changing the UI is painful, so often mediocre UIs rule. Emacsy allows the developer—or the user—to reshape and extend the UI and application easily at runtime.
Emacs has a powerful means of programmatically extending itself while it is running. Not many applications can boast of that, but I believe a powerful idea within Emacs has been overlooked as an Emacsism rather than an idea of general utility. Before I explain that idea, let me mention another idea that may have become a Lispism but has thankfully seen widespread adoption.
Lisp programmers introduced the term Read-Eval-Print-Loop (REPL, pronounced rep-pel), an interactive programming feature present in many dynamic languages: Python, Ruby, MATLAB, Mathematica, Lua to name a few. The pseudo code is given below.
The REPL interaction pattern is to enter one complete expression, hit the return key, and the result of that expression will be displayed. It might look like this:
The kernel of Emacs is conceptually similar to the REPL, but the level of interaction is more fine grained. The REPL assumes a command line interface. Emacs assumes a keyboard interface. I have not seen the kernel of Emacs exhibited in other applications, but I think it is of similar utility to the REPL—and entirely separate from text editing. I’d like to name this the Key-Lookup-Execute-Command-Loop (KLECL, pronounced clec-cull).
Long-time Emacs users will be familiar with this idea, but new Emacs users may not be. For instance, when a user hits the ’a’ key, then an ’a’ is inserted into their document. Let’s pull apart the functions to see what that actually looks like with respect to the KLECL.
Key sequences in Emacs are associated with commands. The fact that each command is implemented in Lisp is an implementation detail and not essential to the idea of a KLECL.
Note how flexible the KLECL is: One can build a REPL out of a KLECL, or a text editor, or a robot simulator (as shown in the video). Emacs uses the KLECL to create an extensible text editor. Emacsy uses the KLECL to make other applications similarly extensible.
The goals of this project are as follows.
Easy to embed technically
Emacsy will use Guile Scheme to make it easy to embed within C and C++ programs.
Easy to embed legally
Emacsy will be licensed under the LGPL.
Easy to learn
Emacsy will be easy enough to learn that the uninitiated may make parametric changes, e.g., key ’a’ now does what key ’b’ did and vice versa. Programmers of any stripe ought to be able to make new commands for themselves. Old Emacs hands can happily rely on Emacs idioms to change most anything in Emacsy.
Opinionated but not unpersuadable
Emacsy will be configured with a sensible set of defaults (opinions). Out of the box, it is not a blank slate, but if the user wants to choose every detail, they can.
Key bindings can be modified at runtime
It wouldn't be Emacs-like if you couldn't tinker with it.
Can define new commands
New commands can be defined in Guile Scheme or C/C++.
Commands compose well
Interactive commands can call other commands. No special arrangements must be considered in the general case.
A small number of interface functions
The core functions that must be called by the embedding application will be few and straightforward to use.
Just as important as a project’s goals are its anti-goals: the things it is not intended to do.
Not a general purpose text editor
Emacsy will not do general purpose text editing out of the box, although it will have a minibuffer.
Not an Emacs replacement
There have been many attempts to replace elisp with a newer Lisp dialect. Emacsy is not one of them.
Not source code compatible with Emacs
Although Emacsy may adopt some naming conventions from Emacs, it will not use elisp and will not attempt to be source code compatible with Emacs.
Not a framework
Emacsy will not steal your run-loop. You call Emacsy when it suits your application not the other way around.
6. Emacsy Features
These are the core features from Emacs that will be implemented in Emacsy.
- recordable macros
- tab completion
- major and minor modes
My plan is to work out in the open on github, part-time this Summer. I'll report noteworthy builds and solicit feedback. I believe that by the deadline I can produce a usable and documented Emacsy library that includes all the features mentioned above, and maybe even some features I haven't mentioned. That should provide an excellent foundation for this project to thrive after the deadline, and I expect to maintain it for sometime after that.
8. Implementation Details
I want to briefly touch on some implementation details. Emacsy will be built on Guile Scheme. It will not assume any particular GUI library—meaning it should work with any of them. For embedders, the Emacsy API will roughly look like this.
For those interested in more details, I've written a guide that shows the code necessary to plug Emacsy into an minimal example program.
9. How you can help?
Tell other people about Emacsy.
Have a friend who uses Emacs? Tell him or her about Emacsy.
Tell me how to make Emacsy better.
- You can send me an email: shane (dot) celis (at) gmail (dot) com
- You can leave a comment on kickstarter.
- You can vote on features at http://reddit.com/r/emacsy
- You can check out the latest code from http://github.com/secelis/emacsy
Become a supporter on kickstarter!
It won't happen without your support. :)
Support this project
- (30 days)