Skip to content
New issue

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

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Merged
merged 27 commits into from
Apr 19, 2021
Merged

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

merged 27 commits into from
Apr 19, 2021

Conversation

CestDiego
Copy link
Contributor

@CestDiego CestDiego commented Oct 9, 2015 •
edited
Loading

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 :(

@zilongshanren
Copy link
Contributor

@CestDiego Does it work on MacOS X?

@CestDiego
Copy link
Contributor Author

@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 :(

@nashamri
Copy link
Contributor

hahaha Awesome @CestDiego !!

@CestDiego CestDiego force-pushed the SpacemacsOS branch 3 times, most recently from de3a9d3 to d20a7f4 Compare October 11, 2015 04:35
@robbyoconnor
Copy link
Contributor

such a meme-loving f*ck!

joehillen
joehillen reviewed Oct 14, 2015
View reviewed changes
layers/+window-management/exwm/config.el Outdated
(defvar exwm--terminal-command "xterm"
"Terminal command to run.")

(defvar exwm--locking-command "lock"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@joehillen
Copy link
Contributor

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.

@marcushg
Copy link

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....

@CestDiego
Copy link
Contributor Author

@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.

@marcushg
Copy link

@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 mentioned this pull request Oct 14, 2015
Closed
@CestDiego
Copy link
Contributor Author

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

@marcushg
Copy link

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.

@CestDiego
Copy link
Contributor Author

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

@marcushg
Copy link

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!

@marcushg
Copy link

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?!

@marcushg
Copy link

@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.

@CestDiego
Copy link
Contributor Author

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

@marcushg
Copy link

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.

@CestDiego CestDiego force-pushed the SpacemacsOS branch 2 times, most recently from e621ce8 to c0ee03f Compare October 16, 2015 16:55
@CestDiego
Copy link
Contributor Author

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 :)

@StreakyCobra StreakyCobra mentioned this pull request Oct 29, 2015
Closed
@a13ph
Copy link

a13ph commented Nov 22, 2015

There's also a https://github.com/flexibeast/ewmctrl

@linchen2chris
Copy link

cool, spacemacs + awesome/i3

@domenzain
Copy link
Contributor

To clarify these commits, the idea is to have the corresponding modes of EXWM mapped to Evil states with their visual feedback.
As well as integration of other useful things like the helm minibuffer including a relevant section.

Most of the keybindings are removed and left instead to the user, with a few extra (documentation coming) variables that allow for fine-tuning with sane defaults.

All comments are welcome.

@moritzschaefer
Copy link
Contributor

What stops merging? :)

@robbyoconnor
Copy link
Contributor

robbyoconnor commented Jan 9, 2019 via email

@robbyoconnor
Copy link
Contributor

Remember -- nothing stops you from pulling these changes in and cherry-picking them.

@kris7t
Copy link

kris7t commented Mar 12, 2019

Anyone having any luck cherry-picking this to their personal spacemacs now?

When I cherry-pick the commits on top of current spacemacs/master, I get an error regarding spacemacs/define-evail-state-face being undefined. Commenting out the two calls to this function from layers/+windows-management/exwm/packages.el lets Emacs load the config. However, the integration between EXWM and evil still seems broken, and I have no clue where to start debugging:

  • When launching an application, the modeline is grayed out (no text is shown, just a gray bar below the window, which slighly narrower than my usual spacemacs modeline). The modeline appears again when I press ESC while the window is focused, or focus a text buffer.
  • It seems evil modes and EXWM input modes can clash, e.g., it is possible to be simultaneously in insert mode and line input mode.
  • The input mode is not indicated by the color of the mode indicator (as I had to comment it out).

Moreover, if at least one window is open and I try to SPC b b or SPC W W, Emacs complains that
helm-buffers--pattern-sans-filters is of the wrong type. When only text buffers are open, Helm opens just fine. It is hard to debug this issue, because any mouse click or keypress will focus the X window instead of interacting with the Emacs debugger.

I also tried checking out the CestDiego/SpacemacsOS branch directly. The Helm issue is gone, but the evil-related issues above still persist.

Is there anyone currently using SpacemacsOS who could overcome these issues? Or is the project now abandoned?

@zabbal
Copy link

zabbal commented Apr 7, 2019 •
edited
Loading

If any has managed to port this on top of latest master, I'm interested as well.
I've found https://github.com/timor/spacemacsOS which looks promising but would love to learn about experience of others.

@robbyoconnor
Copy link
Contributor

robbyoconnor commented Apr 7, 2019 via email

@robbyoconnor
Copy link
Contributor

I'm not sure what we should do here...

@jdriordan
Copy link

https://github.com/timor/spacemacsOS seems to work happily on top of current develop in emacs 28, could it become a layer?

@paralin
Copy link

paralin commented Aug 31, 2020

image

I currently use exwm + spacemacs as my main workflow, across multiple architectures (arm, aarch64, arm64).

Can't vouch for this particular layer, but I have - added a .desktop with a shell script which starts "emacs" using dbus-launch, added exwm and xelb to dotspacemacs-additional-packages, and added the usual exwm startup lines and configurations to my user-config.

Very useful and would recommend 👍

@Antiarchitect
Copy link

A layer, please!

@smile13241324
Copy link
Collaborator

Looks promising I will have a look in the next view days and see where we can integrate it. Thanks for keeping this alive and the posted test results.

@smile13241324 smile13241324 self-assigned this Mar 14, 2021
@smile13241324 smile13241324 merged commit a664569 into syl20bnr:develop Apr 19, 2021
@smile13241324
Copy link
Collaborator

Thank you for contributing to spacemacs 💜, I have cherry picked your commit into develop.

@be11ng be11ng mentioned this pull request Apr 26, 2021
Merged
@lebensterben
Copy link
Collaborator

lebensterben commented Apr 30, 2021 •
edited
Loading

When reviewing another PR, I've found multiple serious issues of this PR.

README.org is poorly written:

  1. Description is too subjective. This is a README, not a manifesto of fanboys. You don't need to thank anyone. Just describe what the layer does. https://github.com/CestDiego/spacemacs/tree/19568a99f8fb23bd75a00917dc0086b745414bf8/layers/%2Bwindow-management/exwm#description
  2. Spacemacs is distribution-agnostic. It's okay to refer to external sources for setting up on a particular system, but we SHOULD NOT ship any distribution specific scripts. https://github.com/CestDiego/spacemacs/blob/19568a99f8fb23bd75a00917dc0086b745414bf8/layers/%2Bwindow-management/exwm/README.org#note-about-display-managers
  3. https://github.com/CestDiego/spacemacs/blob/19568a99f8fb23bd75a00917dc0086b745414bf8/layers/%2Bwindow-management/exwm/packages.el#L120-L128 These bindings require external dependencies not mentioned anywhere in the README. Actually these bindings should be removed. They are completely subjective.
  4. https://github.com/CestDiego/spacemacs/blob/19568a99f8fb23bd75a00917dc0086b745414bf8/layers/%2Bwindow-management/exwm/packages.el#L137-L171 These bindings are not mentioned in README.org.

funcs.el is poorly written:

  1. Private functions are not named correctly according to naming convention.
  2. https://github.com/CestDiego/spacemacs/blob/19568a99f8fb23bd75a00917dc0086b745414bf8/layers/%2Bwindow-management/exwm/funcs.el#L5-L8 there's no need to use backquote here.
  3. https://github.com/CestDiego/spacemacs/blob/19568a99f8fb23bd75a00917dc0086b745414bf8/layers/%2Bwindow-management/exwm/funcs.el#L9-L11
    • first this is not aligned correctly.
    • second, if you expect bindings have the form (KEY COMMAND), mention it in documentation.
    • This entire function is a poorly written loop. Not idiomatic.
  4. https://github.com/CestDiego/spacemacs/blob/19568a99f8fb23bd75a00917dc0086b745414bf8/layers/%2Bwindow-management/exwm/funcs.el#L13-L33 Such basic functionality should be provided by the EXWM package itself. If it's a real window manager, you don't need to implement them.
  5. https://github.com/CestDiego/spacemacs/blob/19568a99f8fb23bd75a00917dc0086b745414bf8/layers/%2Bwindow-management/exwm/funcs.el#L60-L61 Mysterious "utility" function. If something is pooly written and has no documentation or comments, it's of no utility.

lebensterben pushed a commit that referenced this pull request Apr 30, 2021
@be11ng @timor
SpacemacsOS: provide new layer variables for systray and autostart (#…
4e5a723 
…14714)

I'm not sure how best to start doing this, but the branch over at
timor:spacemacsOS has moved ahead a bit.  I've grown used to a lot of these
changes, and would like to see them moved to the main develop branch.  But, the
pull request (formed by merging in CestDiego:spacemacs/SpacemacsOS in #3321)
started diverging.

Again, I'm not sure how to approach moving together these two changes.  Maybe
@timor can help somehow??

This at the least moves in some little things from Timor's branch:

- Can enable exwm-systemtray with `exwm-enable-systray`
- Can enable running XDG autostart applications (only in XDG_USER_HOME/autostart
  for now) with `exwm-autostart-xdg-applications`
- Support for reading `.desktop` files and XDG autostart.
- Can specify additional code appended to exwm-init hook with `exwm-custom-init`

---

This PR also fixed some other existing issues, and improved documentation.

Co-authored-by: timor <timor.dd@googlemail.com>
Co-authored-by: Benjamin Yang <be11ng@users.noreply.github.com>
@be11ng
Copy link
Contributor

be11ng commented May 2, 2021 •
edited
Loading

Most of that criticism is on point. Two things though:

@lebensterben
Copy link
Collaborator

Some issues are already fixed.
Others will be fixed or the portion of codes will be removed in a review.

wang-d pushed a commit to wang-d/spacemacs that referenced this pull request Jul 22, 2021
@CestDiego @domenzain @wang-d
Add Emacs Window Manager (EXWM) Layer AKA SpacemacsOS (syl20bnr#3321)
110cd90 
* Add Emacs Window Manager (EXWM) Layer

The time has come of SpacemacsOS

* set window manager name to EXWM

* update copyright notice

* start server when EXWM is active

When using EXWM, Emacs should be ready to receive clients but the final choice
should be the user's in their shell configuration.

* respect Spacemacs naming conventions and layer organization

* leave keyboard remapping to users

* add EXWM states for Evil

* add support for helm-exwm when helm is in use

* use both exwm-randr and exwm-systemtray

* set up workspaces to match displays by default

* use ido-config instead of the deprecated workaround

When using helm-exwm, its sources distinguish title and class automatically. It
is only necessary to keep the buffer name updated when the window title changes.
When using ido, rename differently for different applications.

* add bindings for common X keys

* use standard prefix commands where available

Spacemacs already has prefix commands for controlling windows.
These are directly available in exwm-state as well as in exwm-insert-state
through leader

* remove most keybindings as they are available directly in exwm-state

* enable exwm directly in the layer configuration

It is safe to enable it here as an existing window manager will simply fail with
a warning.

* add user-configurable variables for RandR and workspaces

By default, create as many workspaces as there are displays and assign them in
RandR order.

* fix naming convention for variables

* use helm for launching applications when possible

* fix conditional helm-exwm leader keys

* remove redundant function

EXWM provides the equivalent

* conform to naming convention for Spacemacs

* separate prefix commands into those for major mode and global

* remove all default bindings

* improve readability

* clean up bindings

* remove obsolete comments

Co-authored-by: M. Domenzain <luis.domenzain@parrot.com>
wang-d pushed a commit to wang-d/spacemacs that referenced this pull request Jul 22, 2021
@be11ng @timor @wang-d
SpacemacsOS: provide new layer variables for systray and autostart (s…
f8aeb1f 
…yl20bnr#14714)

I'm not sure how best to start doing this, but the branch over at
timor:spacemacsOS has moved ahead a bit.  I've grown used to a lot of these
changes, and would like to see them moved to the main develop branch.  But, the
pull request (formed by merging in CestDiego:spacemacs/SpacemacsOS in syl20bnr#3321)
started diverging.

Again, I'm not sure how to approach moving together these two changes.  Maybe
@timor can help somehow??

This at the least moves in some little things from Timor's branch:

- Can enable exwm-systemtray with `exwm-enable-systray`
- Can enable running XDG autostart applications (only in XDG_USER_HOME/autostart
  for now) with `exwm-autostart-xdg-applications`
- Support for reading `.desktop` files and XDG autostart.
- Can specify additional code appended to exwm-init hook with `exwm-custom-init`

---

This PR also fixed some other existing issues, and improved documentation.

Co-authored-by: timor <timor.dd@googlemail.com>
Co-authored-by: Benjamin Yang <be11ng@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@jdriordan jdriordan jdriordan approved these changes

Assignees

@smile13241324 smile13241324

Labels
¯\_(ツ)_/¯
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.