[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs as WM

From: Samuel El-Borai
Subject: Re: Emacs as WM
Date: Mon, 11 Aug 2014 10:19:53 +0200

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%

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

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

You can also read a discussion about those here:

2014-08-09 1:04 GMT+02:00 Feng Shu <address@hidden>:
John Yates <address@hidden> 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 <address@hidden>
> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]