Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Add Emacs Window Manager (EXWM) Layer AKA SpacemacsOS #3321

Open
wants to merge 1 commit into
from

Conversation

Projects
None yet
Contributor

CestDiego commented Oct 9, 2015

It's Happening

alt

SpacemacsOS

For those of you who want to use Spacemacs as your Operating System, this is the closest you'll ever be, by using Spacemacs to manage your windows.

Looks like this:
alt

This is basically just part of the configuration found in the wiki page from EXWM project, it's great, currently one has to restart Spacemacs twice, because I can't make external dependencies install in a diferent order, @syl20bnr (I need XELB installed before EXWM) but that doesn't seem to work like that :(

Contributor

zilongshanren commented Oct 10, 2015

@CestDiego Does it work on MacOS X?

Contributor

CestDiego commented Oct 10, 2015

@zilongshanren I don't know. Someone will have to try it with x Quartz and also would only work with x widgets I guess... So there are not many uses I guess :(

Contributor

nashamri commented Oct 10, 2015

hahaha Awesome @CestDiego !!

Contributor

robbyoconnor commented Oct 13, 2015

such a meme-loving f*ck!

@joehillen joehillen commented on the diff Oct 14, 2015

layers/+window-management/exwm/config.el
@@ -0,0 +1,11 @@
+(defvar exwm--terminal-command "xterm"
+ "Terminal command to run.")
+
+(defvar exwm--locking-command "lock"
@joehillen

joehillen Oct 14, 2015

Contributor

I don't think lock makes sense as a default, but I don't know what would be a good default value.

Contributor

joehillen commented Oct 14, 2015

I tried this out and I ran into some issues.

First was that, xelb failed to install during first startup.

The app launcher doesn't open helm until you hit TAB and then you have to press ENTER twice.

The SPC workflow is pretty much incompatible with EXWM, and the M-m binding gets intercepted by any GUI app. Same goes for resizing.

The SPC workflow is pretty much incompatible with EXWM, and the M-m binding gets intercepted by any GUI app. Same goes for resizing.

I agree.... but exwm essentially provides two input modes quite similar to vim's/spacemacs input and normal mode: char and line mode (borrowed from ansi-mode). Oversimplified, char mode = input mode and line mode = normal mode in that char mode sends all keys to the X window while line mode currently sends most key sequences to the X-window but also enables some Emacs keybindings. That's why I forked exwm and made exwm send all key sequences to Emacs in line mode, essentially behaving similar to normal mode. EDIT got it backwards, fixed it wrt line/char mode

Now I am able to continue using SPC as my leader and all other Emacs keybindings and switch to input/char mode whenever I want to interact with my X-window/program. At first it was kinda tedious but with help from xcape I am now using the left and right Super key to switch between input/char and normal/line mode and it already feels like all the other editing done in vim/spacemacs....

I don't know if it makes sense and it would require a change within exwm but for me it's working just fine right now, preserving all features of spacemacs while adding the niceties of emacs being my WM :-) Unfortunately my elisp-fu is too weak to go beyond this shoddy hack....

Contributor

CestDiego commented Oct 14, 2015

@marcushg can you share the setup you have for your fork? I would totally try to implement it in Spacemacs. so that we have normal and insert mode in XWindows as well it sounds like a great choice.

@CestDiego sure, but I am a little embarrassed how much of a hack it really is 😄 Actually I got it backwards in my comment above (I will correct it afterwards) -- it is the line mode that essentially sends some keys to the X-window but also binds some standard Emacs keys - and I modified it to not send any keys to the X-window, so it behaves more like normal mode in Spacemacs. It's essentially just this commit.

@marcushg marcushg referenced this pull request in ch11ng/exwm Oct 14, 2015

Closed

Mode where nothing is sent to xwindow #83

Contributor

CestDiego commented Oct 14, 2015

I would love to know what @ch11ng thinks of having this separation though, I don't know if it will break stuff D:

so far @ch11ng has been very receptive and fast to respond to issues. I believe for someone more knowledgeable in elisp than myself it would be kind of trivial to either add a new mode (which would behave like normal mode, i.e. not sending any keys to the X-window) or make line mode configurable to achieve the same....

Then, to make it consistent with spacemacs, we would somehow need a way to integrate it with evil's input and normal mode switching, though I don't know if that would have any other side effects for the X-window buffer.

Contributor

CestDiego commented Oct 14, 2015

I'm fine currently switching between windows with super-[hjkl], and i don't really need space to do stuff, I'm pretty used to using M-m now, this is because I am using Vimium, and if I wanted to go into insert mode in some text field I would have to go in insert mode twice? per xWindow and input field..doesn't really add up, but the full screen apps should still obey global bindings like fullscreen toggle, or changing volume of brightness

I truely believe you're comfortable with your setup, but I also believe we should stay in line with spacemacs philosophy and change as little as possible of its current workflow, i.e. use SPC as leader (or whatever you've configured in your .spacemacs personally) and make X-windows behave according to normal and input mode. By enabling this layer in its current form the we would change something that should remain user configurable (i.e. the evil leader key sequence).

I think the key idea behind spacemacs and its success (besides evil mode and sane configurability) is its consistency and making it behave the same across different parts of emacs.

EDIT that sounded way too negative ;-) I am certain we can make it work (with a little help from exwm) so that this great layer stays in tune with spacemacs philosophy!

I forgot about the additional editing styles which make the matter (of sending keys to either the x-window or emacs) a bit more complicated?!

@ch11ng suggested the following over at the exwm issue

It seems spacemacs uses SPC as a prefix key. So would it be enough to just add this key (and perhaps other extra prefix keys, if any) to exwm-input-prefix-keys?

Sounds like a reasonable approach to not have to modify exwm. Don't know though which keys besides the leader key we would have to add and we also would have to be careful about the selected editing style.

Contributor

CestDiego commented Oct 15, 2015

but about the style, how would one then send the space key to an X Window?

IIRC exwm-input-prefix-keys is limited to line mode, you would switch to char a.k.a. input mode to send space to the X-window.

Add Emacs Window Manager (EXWM) Layer
The time has come of SpacemacsOS
Contributor

CestDiego commented Oct 17, 2015

I think this has many drawbacks now. For example having multiple workspaces makes Emacs too long in changing stuff and updating many things unbearably slow( See ch11ng/exwm#84 ) I will have to device a way that uses the Super+[1-9] kebindings in a better way, and maybe with perspectives or something. right now I think eyebrowse might be the best alternative and easiest one as well. But I'm a fan of the new perspectives layer so I can't promise anything, If someone is using EXWM and this PR please keep on commenting with issues so we can make this work :)

cool, spacemacs + awesome/i3

Contributor

carbohydratesn commented May 11, 2016

I've been using this layer for a few months now - and it's been great!

It seems natural to me that X windows don't fit perfectly into the modal editing that permeates the rest of Spacemacs. X windows exist outside of emacs, char mode puts you in that context and line mode brings you back to emacs.

Making char mode more like 'insert' would be great, but until then, I've been using the powerline to switch contexts. Just having a way to get from char- to line-mode reliably would work, I've been having trouble figuring something out for that. exwm-input-release-keyboard does not seem to work from within X windows, even when configured properly (I think) - something to do with emacs window focus.

Super is a great key for EXWM bindings, I am a big fan of that.

This layer does not play well with persp-mode; this will take some configuration changes. For now I've excluded persp-mode in my .spacemacs

persp-mode tries to 'restore' irrelevant layouts to new floating windows

I look forward to working on this as I get more comfortable with elisp!

Contributor

CestDiego commented May 11, 2016

Please do! I'm glad this is useful to people. :D I have gone away from
Linux as my OS for work related purposes. But I would be glad to keep
working on it once I get the chance to have a laptop of my own.

Everyone please feel free to make pull request to the branch in my fork so
that we can have a giant pull request for a EXWM layer

On Wed, May 11, 2016, 3:43 PM carbohydratesn notifications@github.com
wrote:

I've been using this layer for a few months now - and it's been great!

It seems natural to me that X windows don't fit perfectly into the modal
editing that permeates the rest of Spacemacs. X windows exist outside of
emacs, char mode puts you in that context and line mode brings you back to
emacs.

Making char mode more like 'insert' would be great, but until then, I've
been using the powerline to switch contexts. Just having a way to get from
char- to line-mode reliably would work, I've been having trouble figuring
something out for that. exwm-input-release-keyboard does not seem to work
from within X windows, even when configured properly (I think) - something
to do with emacs window focus.

Super is a great key for EXWM bindings, I am a big fan of that.

This layer does not play well with persp-mode; this will take some
configuration changes. For now I've excluded persp-mode in my .spacemacs

persp-mode tries to 'restore' irrelevant layouts to new floating windows
Bad-ptr/persp-mode.el#36 (comment)

I look forward to working on this as I get more comfortable with elisp!


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#3321 (comment)

Diego Berrocal
http://cestdiego.github.io

agzam commented Oct 25, 2016

@zilongshanren for OSX, not too long ago I started Spacemacs inspired Hammerspoon config github.com/agzam/spacehammer.

Contributor

zilongshanren commented Oct 25, 2016

@agzam
It looks promising, I will give your Hammerspoon config a try, thanks. 👍

Contributor

CestDiego commented Oct 25, 2016 edited

@agzam I'm going to try to use this. But if it doesn't work. I'm running NixOS as a virtual machine on my mac and have the full SpacemacsOS Experience there.

tidux commented Feb 1, 2017

What's the status on this PR?

Contributor

robbyoconnor commented Feb 1, 2017

@tidux you can always pull this locally...It probably fell through the cracks...

Contributor

CestDiego commented Feb 1, 2017

Contributor

robbyoconnor commented Feb 1, 2017

Did you switch to mac @CestDiego?! Come back to Linux...we have 🍪's -- but those mac people have 🍰 AND 🍪's -- I'm gonna make better 🍰

tidux commented Feb 2, 2017 edited

Contributor

robbyoconnor commented Feb 2, 2017

👍

Contributor

CestDiego commented Feb 2, 2017

oh my.... exwm looks much more stable.. Maybe I'll give this another try and install a VM or something

Contributor

robbyoconnor commented Feb 2, 2017

@CestDiego -- I ran into a guy at Hackers on Planet Earth who was using exwm!

What is the status of this PR? Its been open for over a year without being accepted. Is it stable to use this EXWM layer or not?

Contributor

carbohydratesn commented Mar 17, 2017 edited

Hey all, I have made some progress in making this all more usable within Spacemacs!

As of a month ago @ch11ng and @Stebalien have implemented an option to make line mode pass all input to emacs; ch11ng/exwm#83 (comment)

This works perfectly!

And that, along with a exwm-input-toggle-mode function I wrote (the built-in EXWM function exwm-input-toggle-keyboard doesn't seem to work for this) makes everything work like a dream. One hotkey switches between line/char mode, and it also hides/shows the modeline, which increases 'immersion' and makes it very clear which mode you're in, and whether emacs or the X window will be receiving input. This also saves a little screen space ;)

I have also added a hook to make exwm windows default to char-mode with the mode line hidden, this is a matter of personal preference - it would be a good option to provide, though.

(add-hook 'exwm-manage-finish-hook (lambda () (call-interactively #'exwm-input-release-keyboard) (exwm-layout-hide-mode-line)))

carbohydratesn#1

I'll leave it to someone else to implement some vim-like behavior for manipulating X windows, I've been very happy simply having an 'insert mode' and 'emacs mode'. The distinction is an easy one to grasp, and I mostly just use qutebrowser, which already uses vim keys.

And @rushsteve1 - yes, this layer is extremely stable and effective. I've been using it daily for many, many months. Couldn't be happier with it, after making these modifications!

Contributor

Stebalien commented Mar 31, 2017

Warning: Meandering reflection on using EXWM follows...

So, I've been using EXWM for a while now and it's really awesome (except when Emacs freezes at which point one starts wondering if using a single-threaded lisp interpreter as ones desktop environment reflects on ones sanity). Anyways...

At first I tried using multiple evil modes (custom exwm-insert and exwm-normal modes) but it always felt awkward. In order to make exwm-normal mode useful, I mapped as many of vim's normal mode keys as possible by emulating key presses ("hjkl" to arrow keys, gg to <home>, G to <end>, etc.). I even mapped some evil commands to emacs keys as quite a few applications support a subset of emacs key bindings for text editing (e.g., dw to C-<delete>). However, normal mode always felt a bit inconsistent and flaky. For example, "hjkl" would move the cursor when a textarea was focused but scroll the page otherwise, the text operations never worked quite right (it's not even possible to support most of them), and I kept having trouble remembering which mode I was in (the cursor is always an I-bar).

In the end, I started using CapsLock as my spacemacs leader key (by remapping CapsLock to Menu and setting Menu as my spacemacs leader key). This has worked out great so far except that I constantly lose track of where my pinky is (Shift, CapsLock, or Tab) which can make typing ~ a bit of a trial (I now have a tendency to hit <CapsLock-`>


More on topic, if you use EXWM and transient states (hydras), you'll probably want the following advice to allow hydras to capture all key presses (in line-mode, at least).

      (define-advice hydra-set-transient-map (:around (fun keymap on-exit &optional foreign-keys) exwm-passthrough)
        (setq exwm-input-line-mode-passthrough t)
        (let ((on-exit (lexical-let ((on-exit on-exit))
                         (lambda ()
                           (setq exwm-input-line-mode-passthrough nil)
                           (when on-exit (funcall on-exit))))))
          (funcall fun keymap on-exit foreign-keys)))

taohansen commented Jun 13, 2017 edited

With @carbohydratesn's pull request (with my suggested edit), this layer is fully functional. I use it as my daily driver.

There are two issues that have nothing to do with the pull request and that is temporary lock-ups, which is a fundamental flaw of Emacs and it's single-threaded nature, and window blocking, which can happen when applications close or try to open windows that EXWM doesn't know how to handle. Despite these issues, this is still the best layer available for Spacemacs, period.

taohansen commented Jun 22, 2017 edited

i suggest we extend and rework the PR around EXWM-X (for app shortcuts and drun) and Ivy (for speed). i have a working daily driver with shortcuts to Firefox, my file manager, and URxvt. i just swapped a few shortcuts to Helm for Ivy making just about any interaction with Spacemacs fast and fluent.

Sent from my Samsung SM-G930F using FastHub

IQubic commented Jun 23, 2017

Why is it that this hasn't merged yet? This layer looks to be working just fine. I'm not seeing any issue with it. Are there any issues that I'm unaware of?

@IQubic i’ve been using this as my daily driver for the past week and, well, it’s not all wine and roses. you can’t play any Steam games because the game windows spawn into some ungraspable ether, sometimes when you open an application you won’t be able to grab focus because Emacs will complain it is read-only, there are focusing issues in general, especially surrounding child windows of applications, and sometimes closing applications will freeze all user input for half a minute, though i seem to have solved this by switching my completion framework to Ivy.

Sent from my Samsung SM-G930F using FastHub

@akirakyle akirakyle referenced this pull request in ch11ng/exwm Jul 1, 2017

Open

Maintaining the leader key-binding in EXWM #268

unjordy commented Jul 2, 2017

Is anyone else having an issue where line mode stops working? Specifically, all EXWM buffers act like they're in char mode, and the toggle hotkey still updates the modeline to display 'line' or 'char', but has no effect on how the buffers actually receive keys. Line mode stays broken until I restart emacs, even if I kill all my EXWM buffers, and nothing is logged in Messages with exwm-debug-on set to t. I believe I've had this happen in varying circumstances, but I can trigger it consistently by switching to a new EXWM workspace, creating a new spacemacs layout, and adding an EXWM buffer to that layout. This seems like an incompatibility between spacemacs layouts and EXWM -- maybe layouts throw out a bit of state that EXWM uses to manage line mode keybindings? I'll gladly write a patch to fix this, if anyone can point me in the right direction to start understanding how layouts affect buffer state, and where EXWM keeps its state. It turns out EXWM + qutebrowser is surprisingly usable, and I'd love to be able to use this daily!

unjordy commented Jul 2, 2017

Actually, experimenting a little more, it seems like if you've ever switched layouts during your emacs session, line mode will be broken until you restart emacs, regardless of whether or not you even have any EXWM buffers open. It definitely seems like layouts switching is destroying some of EXWM's keybinding state.

paralin commented Jul 5, 2017

I see the same as @unjordy

paralin commented Jul 5, 2017

To be honest, I don't know quite what this layer adds. Here's all I need in my user-config to get everything working nicely:

  (require 'exwm)
  (require 'exwm-config)
  (setq exwm-input--line-mode-passthrough t)

  ;; Set the initial workspace number.
  (setq exwm-workspace-number 2)
  ;; Make class name the buffer name
  (add-hook 'exwm-update-class-hook
            (lambda ()
              (setq exwm-input--line-mode-passthrough t)
              (exwm-workspace-rename-buffer exwm-class-name)
              ))

  ;; 's-w': Switch workspace
  ; (exwm-input-set-key (kbd "s-w") #'exwm-workspace-switch)
  (exwm-input-set-key (kbd "s-w") #'spacemacs/workspaces-transient-state/body)
  ;; s-h, s-j, s-k, s-l: move around
  (exwm-input-set-key (kbd "s-h") #'evil-window-left)
  (exwm-input-set-key (kbd "s-j") #'evil-window-down)
  (exwm-input-set-key (kbd "s-k") #'evil-window-up)
  (exwm-input-set-key (kbd "s-l") #'evil-window-right)
  ;; lock screen
  (exwm-input-set-key (kbd "C-M-l") #'lock-screen)
  (define-key global-map (kbd "C-M-l") #'lock-screen)
  (push ?\s-\  exwm-input-prefix-keys)

  ;; fn key bindings
  (exwm-input-set-key (kbd "<XF86AudioRaiseVolume>") #'turn-volume-up)
  (exwm-input-set-key (kbd "<XF86AudioLowerVolume>") #'turn-volume-down)
  (exwm-input-set-key (kbd "<XF86AudioMute>") #'toggle-volume-mute)
  (exwm-input-set-key (kbd "<XF86AudioPlay>") #'spotify-playpause)
  (exwm-input-set-key (kbd "<XF86AudioNext>") #'spotify-next)
  (exwm-input-set-key (kbd "<XF86AudioPrev>") #'spotify-previous)
  (exwm-input-set-key (kbd "<XF86KbdBrightnessUp>") #'kbd-brightness-up)
  (exwm-input-set-key (kbd "<XF86KbdBrightnessDown>") #'kbd-brightness-down)
  (exwm-input-set-key (kbd "<XF86LaunchA>") #'lock-screen)
  (exwm-input-set-key (kbd "<XF86LaunchB>") #'spacemacs/toggle-maximize-buffer)

  ;; 's-&': Launch application
  (exwm-input-set-key (kbd "s-&")
                     (lambda (command)
                      (interactive (list (read-shell-command "$ ")))
                     (start-process-shell-command command nil command)))
  ;; Enable EXWM
  (exwm-enable)
  ;; Configure Ido
  (exwm-config-ido)
  ;; Other configurations
  (exwm-config-misc)

The layer broke a lot of stuff and most of the keybindings don't work. I'd say we should probably just rewrite it in a simpler way, and include these little customization tips in the readme in case users want them.

paralin commented Jul 5, 2017

Another issue I've noticed is that temporary windows (like alerts, file browsers when opening files, etc) open in a floating window with several splits. I need to find a way to make Spacemacs not open the split layout automatically in a new frame.

unjordy commented Jul 6, 2017

@paralin Do you encounter the line mode/layouts issues when you use your config instead of the layer? If not, that would go a long way toward figuring out what's causing the bug.

The layer's keybindings all seem to be working for me, but are a bit less than ideal for my purposes -- I'm planning on binding s-S-[0-9] so that they move windows to workspaces [0-9], similar to xmonad, bind the app launcher to s-x, and rebind s-SPC to be the leader key. It's strange that the layer includes workspace switching bindings, but exwm-workspace-move-window keeps its default binding and isn't mentioned anywhere in the layer readme. I've also started on some sensible evil mode bindings for exwm-mode buffers; I'm not expecting a perfect mapping, just something rough and usable like Spacemacs' bindings for dired and similar modes.

@unjordy @paralin i’ve pared down my configuration to just the essentials and everything works just dandy, even Steam but EXWM will still lose focus if i close an X window and it’s always a varying degree of pain to get focus back. do either of you have these issues?

taohansen commented Jul 9, 2017 edited

any time i close an X window, EXWM will freeze for up to 30 seconds.

see this issue:
ch11ng/exwm#260

it appears to only effect Spacemacs users.

unjordy commented Jul 11, 2017

@taohansen I do have an issue with EXWM losing focus whenever I use my exwm-workspace-move-window keybindings (IE s-! is bound to (lambda () (interactive) (exwm-workspace-move-window 0))). I'm able to recover focus consistently by clicking on any of the mode lines on my screen with the mouse, but that isn't the best solution. I can't figure out if the issue is that no window has focus, or that the EXWM frame has lost focus. As a workaround, is it possible to force focus via emacs lisp?

deech commented Oct 25, 2017

I've applied this PR as a patch to a local copy of master and it works really well. I'm not seeing the X freeze that others are talking about.

tidux commented Oct 30, 2017

I don't see the X freeze either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment