Other projects of the same kind:

Guile-WM (Guile scheme)
-------------------------------------
From the README:
    "Guile-WM is a framework for creating an X window manager (or any other
X
application, really) and a set of useful modules designed for that purpose.

[...]

    Guile-WM relies /heavily/ on its user init file. In fact, it won't
do anything on

    its own without one. The intention is to provide something 100%

    configurable."


Link: https://github.com/mwitmer/guile-wm


# The Deep Space Window Manager (Common Lisp)

From the README:
    "DSWM is a fork of StumpWM, so have most of all features, which have
StumpWM, but it designed for better usability and better integration with
emacs."

Link: https://github.com/dss-project/dswm


You can also read a discussion about those here:
https://news.ycombinator.com/item?id=8160968



2014-08-09 1:04 GMT+02:00 Feng Shu <tumashu@gmail.com>:

> John Yates <john@yates-sheets.org> writes:
>
> > Personally I regularly have the opposite itch: wanting to replace
> > emacs's frustrating window management with an external tiling WM (in
> > my case awesome).
>
> I use stumpwm, which is like emacs.
>
> >
> > /john
> >
> > On Fri, Aug 8, 2014 at 4:35 PM, Matthew Plant <maplant2@illinois.edu>
> > wrote:
> >
> >     I was curious about what people on this list thought about
> >     application
> >     embedding in Emacs. To a degree this is already supported with
> >     ansi
> >     term, but this obviously doesn't extend to GUI applications. For
> >     those
> >     of you familiar with Plan 9, think of how programs use the window
> >     the
> >     terminal they're launched in; embedding GUI apps in Emacs would
> >     force
> >     the program to run in a window owned by Emacs and fitted into a
> >     buffer.
> >
> >     The reason why I bring this up is because it would be relatively
> >     easy to
> >     do in a way that's not very platform agnostic. It's really easy to
> >     replace the X libarary (forgive me for not using proper
> >     nomenclature;
> >     it'd lengthen this email tenfold) window creation functions with
> >     one
> >     that extends contol over the window. The degree of integration can
> >     be
> >     controlled by the number of replaced functions. If drawn text
> >     wants to
> >     be handled specially, those functions would be replaced. Some
> >     method can
> >     be specified for switching between emacs and the application
> >     controlling
> >     user input.
> >
> >     This has some obvious advantages; for one, Emacs automatically
> >     subsumes
> >     all editors, including more WYSIWYG editors. Not only that, but
> >     Emacs
> >     essentially becomes a window manager, which I personally would
> >     love. Because some apps, particular web browsers, do not always
> >     require
> >     special handling of the keyboard, switching between regular Emacs
> >     buffers and the special app buffers would be generally seamless. I
> >     could
> >     imagine myself typing away in one Emacs buffer, momentarily moving
> >     to
> >     the mouse to click throught some online doxygen in my web browser
> >     in the
> >     buffer to the right.
> >
> >     There are also a lot of disadvantages to this. For one, the
> >     applications
> >     would be pretty buggy without some effort to re-implement X
> >     functions. Also, my co-worker points out that this would be
> >     incongrous
> >     with the current capabilities of Emacs, one of which is the easy
> >     transfer of text betwixt buffers. Getting these two features to
> >     work
> >     harmoniously would be kind of difficult; lots of wrappers to
> >     X/Gnome/whatever text writing functions would have to be made.
> >     However,
> >     copy and paste would work (I'm guessing) out of the box.
> >
> >     I suppose it all boils down to what people want with the future of
> >     Emacs. Personally, I would love to turn on my computer and have
> >     Emacs be
> >     there every step of the way. I genuinely think that Emacs is a
> >     great
> >     full interface to an OS. It is not a full OS however and never
> >     should
> >     be, which is why I like this idea as an in-between.
> >
> >     -M
>
> --
>
>
>