Assuming EXWM maintenance

[medranocalvo]

In these strange circunstances have I taken the decision to assume maintenance of EXWM.

I assume the maintenance at this moment for the reason that I was given access to ch11ng/exwm project page, and was given permission to commit and release. This access and permission were given in different circumstances, and I do not have permission from him to take over maintenance. I'm nevertheless taking this step in order to revitalize the project and keep users and contributors engaged until @ch11ng returns, hopefully soon.

My plan is to assume this role until @ch11ng is back, or up to July 2022, when there will have passed two years without news of him. I think that at that point the project shall be moved to a different location and it shall be decided whether I am to continue maintaining EXWM, especially attending to my availability then.

I'd like to make you aware of the following:

• I have little time in my hands. I expect I'll be able to dedicate max. a couple of hours per week.
• My focus will be on reviewing and merging PRs and releasing
• I'd like to enlist collaborators to help with testing PRs and debugging; I'd like to improve debuggability
• I doubt I'll be able to help users debug issues, though I'll try to help when I can.
• I doubt I'll be able to implement improvements, let alone big features.

Please, adjust your expectations.

---

Next steps for me are:

• Contact GNU ELPA maintainers
• Document development and maintainance processes in the Wiki; figure out how to release.
• Resurrect my savannah account
• Merge pending PRs & release
• Review and classify open issues.
• ...

Best regards,
Adrián.

[medranocalvo]

See also https://lists.gnu.org/archive/html/emacs-devel/2021-10/msg01377.html.

[enzuru]

Thank you for taking this step, @medranocalvo. I can offer you a few of my hours a week as well, so that we can hopefully help save this project. My workstation has been out of commission since my move, but I'll go ahead and install GNU Guix on it this week.

How would you like to coordinate? GitHub? IRC? Mailing list?

[medranocalvo]

Dear @enzuru,
thank you very much for your offer. I'm still figuring it out. (And have little time!). Roughly:

• Help with development
  • What I've done in the past is simply implement some features I wanted. Then I tried reproducing other's issues and asked for clarification or proposed patches.
  • I wish some parts of the codebase would be cleaner. It is difficult understand what is needed and what is obsolete.
  • I'd like to pinpoint EXWM longest-standing issues (e.g. the dreaded "Buffer is read-only") and somehow(TM) organize to tackle them
  • I'd like to improve debuggability, so that debugging issues becomes easier.
• Help with testing
  • Using master and reporting breakage
  • Testing pull requests
  • Help with reproducing/debugging other's issues
• Help with support
  • Just helping one another. Many of you have been doing that during the last months, thank you very much!

As for how to coordinate... I'd say GitHub is fine. (As mentioned above: expect slow replies.)

I'm not sure if this comment helps you. What did you had in mind?

[enzuru]

@medranocalvo this all gives me a good idea of how to help. I'll go ahead and setup a workstation with emacs master and exwm and xelb on master and go from there.

[elken]

Over the course of the next week or so, I'll be updating and migrating back to my exwm setup; after which point I'd also happily be available to help out :)

[medranocalvo]

Dear @elken,
thank you for your offer, it is appreciated. It would be especially helpful if you could run the master branch and report breakage: I don't use many EXWM features and it's hard to ascertain the impact of the changes. Case in point: fullscreen is broken since my last commit.

[minad]

@medranocalvo Thank you for maintaining EXWM all these years! I switched just recently from i3 and EXWM works exceptionally well.

My plan is to assume this role until @ch11ng is back, or up to July 2022, when there will have passed two years without news of him. I think that at that point the project shall be moved to a different location and it shall be decided whether I am to continue maintaining EXWM, especially attending to my availability then.

Do you still plan to move this project to a different location like a GH organization, like for example emacs-compat or emacs-gnplot? Would it make sense to distribute the maintenance load, depending on the activity here and your availability?

[Stebalien]

I'm also happy to help.

[Stebalien]

I also wonder, would it be possible to move development into the main Emacs codebase? We'd likely need several rounds of cleanup (e.g., #868) but it would be more stable in the long run.

[minad]

@Stebalien I don't think that moving EXWM to the Emacs repository would be ideal. The package is not "core functionality" and probably not used by sufficiently many users. Furthermore in the longer term, we may need an alternative for Wayland.

[Stebalien]

The package is not "core functionality" and probably not used by sufficiently many users.

Well... I'd say the same about the two IRC clients and 3(?) email clients. But you're probably right.

Furthermore in the longer term, we may need an alternative for Wayland.

We will. But, IMO, that likely will be builtin as we'll probably want to make Emacs a wayland compositor.

[minad]

Well... I'd say the same about the two IRC clients and 3(?) email clients. But you're probably right.

Yes, it may make sense to even move out some of the packages to GNU ELPA, e.g., rcirc, erc, mpc, ... and many others.

But, IMO, that likely will be builtin as we'll probably want to make Emacs a wayland compositor.

Why? Right now I can restart my Emacs with restart-emacs and all the X windows stay alive. If I understand correctly, the Wayland compositor cannot be restarted. Therefore the better design would be to have a separate tiny native wlroots-based server, which is started first (and never restarted). Emacs can be started later and communicate with this server to control window management. It won't work to make the compositor part of the Emacs process (neither built-in nor dynamic module).

[Stebalien]

Yeah, you're probably right. I'm just dreaming of replacing xwidgets with a wayland compositor (e.g., to embed a video player into a buffer) then using that feature to implement a full window manager with fewer hacks around detecting buffer/window changes (99% of EXWM bugs come from input focus issues).

[minad]

I'm just dreaming of replacing xwidgets with a wayland compositor (e.g., to embed a video player into a buffer) then using that feature to implement a full window manager with fewer hacks around detecting buffer/window changes (99% of EXWM bugs come from input focus issues).

For now, I think one could also implement such embedding for EXWM. The buffer should include a blank image (via display property) and EXWM could be informed via an additional property that a widget should go there. The question is how to handle cropping when scrolling.

[gdindi]

Hi.
About Wayland, I guess you are aware of this https://emacsconf.org/2022/talks/wayland/. Unfortunately, I have not been able to find the code for the talk.

[nagy]

Unfortunately, I have not been able to find the code for the talk.

http://perma-curious.eu/repo-ewx/

[medranocalvo]

@medranocalvo Thank you for maintaining EXWM all these years! I switched just recently from i3 and EXWM works exceptionally well.

My plan is to assume this role until @ch11ng is back, or up to July 2022, when there will have passed two years without news of him. I think that at that point the project shall be moved to a different location and it shall be decided whether I am to continue maintaining EXWM, especially attending to my availability then.

Do you still plan to move this project to a different location like a GH organization, like for example emacs-compat or emacs-gnplot? Would it make sense to distribute the maintenance load, depending on the activity here and your availability?

What a great way to start the year with renewed energy on EXWM!

I appreciate your gratitude. I have reread my initial post and I can say that I definitely did not exceed expectations ;-). The candle is still on, though. I extend your thanks to each EXWM contributor, both those proposing changes and those helping each other on the tickets and on the web.

---

Yes, of course EXWM should be moved out. I've been wishing some energy to build up around maintenance, but wasn't even sure how it would manifest or whether I should try to catalyze it. Here we are :-).

The maintenance load should definitely be distributed, or otherwise taken from my only hands. Would you be interested in helping maintaining EXWM, @minad? How about you, @Stebalien? I would appreciate feedback from you and other users and contributors on how to proceed with this.

Some years ago I registered https://github.com/emacs-exwm (inspired by https://github.com/emacs-evil/evil). Would it be OK? (I'm not married to the name.)

[Sbozzolo]

I don't want to interject in this discussion, but as long-time EXWM user (since 2016), I want to give my most heartfelt thank you to everyone here and everyone who has volunteered their time and energy over the years. And, as someone involved in maintaining vterm (and failing to do so properly), I strongly support any effort that would reduce burden on a single person: it makes a huge difference in terms of project sustainability.

Thank you!

[minad]

@medranocalvo

The maintenance load should definitely be distributed, or otherwise taken from my only hands. Would you be interested in helping maintaining EXWM, @minad? How about you, @Stebalien? I would appreciate feedback from you and other users and contributors on how to proceed with this.

I am happy to help. I should note that my familiarity with the code base is fairly limited given that my conversion to EXWM is not too far back. I already maintain a bunch of my own packages on GNU ELPA, so I cannot promise much time for EXWM.

Anyway, EXWM already seems quite solid and I think maintenance will be limited to bug fixes, ensuring that things continue to work with new Emacs releases, code base cleanups and maybe filling some smaller gaps (e.g. @Stebalien's xsettings patch).

Some years ago I registered https://github.com/emacs-exwm (inspired by https://github.com/emacs-evil/evil). Would it be OK? (I'm not married to the name.)

Sounds good to me!

[Stebalien]

Again, I'm happy to help maintain it. But yeah, I don't really think it needs any more major features (although that minor mode patch you have would be nice).

[Stebalien]

I've been using it for almost 7 years now, so I'm pretty comfortable with how it works internally...

[medranocalvo]

@Stebalien, you don't need to show your credentials: I know you by your contributions and I enjoy and am grateful for your long time involvement. I hereby name you EXWM Maintainer.

@minad, EXWM works great when it works, but when it doesn't finding the issue is difficult and time consuming. (@ch11ng, I miss you.) An extra hand and mind involved will surely help. I hereby name you EXWM Maintainer.

I disagree feature completion. I have the following in mind:

• Support an exwm-mode buffer in multiple Emacs windows (there's been some discussion recently, I'll expand there when I have some time)
• Improve floating with decorations and buttons. Make restacking more intuitive (?). Integrate with tab-mode (or support floating over multiple workspaces). Support floating regular, non exwm-mode buffers.
• Use regular keymaps for exwm-input keys (simulation and global, if I recall correctly).
• Support using EXWM on multiple DISPLAYs/window systems at once.
• Can we abstract the high level concepts and Emacs integration so that EXWM could be used on Wayland?
• Improve debugging and reporting, both documenting tools and procedures and support for them in EXWM.
• There's surely more I don't recall right now.

Most of these I had already in mind in 2021...

I have invited you to be owners of https://github.com/orgs/emacs-exwm. I'll open a ticket for the migration to the org. Let's kick it from there.

By the way

        Thank you.

[minad]

@medranocalvo Thank you!

I disagree feature completion. I have the following in mind:

The points you mentioned all make sense. Hopefully we can tackle a few of them in the future.

I'll open a ticket for the migration to the org. Let's kick it from there.

I'll comment over there.

[medranocalvo]

I opened a new ticket to celebrate your appointment. I'm very happy :-).

I noted down some information when I became maintainer in 2021: https://github.com/ch11ng/exwm/wiki/Maintenance. The idea was to make it easier for someone to ramp up, though it might be somewhat caotic. Some project conventions and workflows are documented there (these are @ch11ng's conventions, which I respected, but can now be changed if we determine).

[minad]

https://github.com/ch11ng/exwm/wiki/Maintenance

Thanks, the information in the wiki is helpful. Both @Stebalien and I should be familiar with the ELPA processes. I'd say we continue to follow the conventions for the time being or do you have some specific things in mind which should better be changed?

[Stebalien]

Use regular keymaps for exwm-input keys (simulation and global, if I recall correctly).

This, 100x.

[buhtz]

Have you considered using a hoster and server software respecting privacy of users and FOSS principals?
A Gitea/Forgejo based hoster for example?

You are a big project on a big topic. Visibility of a FOSS project IMHO do not depend on the hoster used. But you could become a good role model when migrating to a real FOSS hoster.

[hab25]

Have you considered using a hoster and server software respecting privacy of users and FOSS principals? A Gitea/Forgejo based hoster for example?

You are a big project on a big topic. Visibility of a FOSS project IMHO do not depend on the hoster used. But you could become a good role model when migrating to a real FOSS hoster.

#942 is a better place to discuss this, however n.b. #942 (comment)

[medranocalvo]

Well, I think we can close this ticket as we have advanced to a new phase. I'm very happy.