Restricting applications to window they were launched in

[walseb]

Hello!

When launching an application that takes a while to start up, it will be placed in the currently selected window when it eventually launches.

Oftentimes, while it's launching I'm working on something else to fill out the time, and when it's done loading it interrupts my work elsewhere which is pretty annoying.

I think a superior solution would be to somehow restrict it to the window I had selected when it was launched. And if that window is gone, it would be great if it could just be placed at the top of the buffer list instead of switching the active window.

Does anyone know whether something like this is already implemented elsewhere? If not, any thoughts on how to implement it?

Thanks!

[ethanmoss1]

My thoughts go to one of two things, should EXWM manage the loading of applications or should there be a seperate package that loads applications which manages how they are loaded. Such as a Emacs Application Manager (think dmenu?).

As such as your example where if the application takes time to load you dont want it taking over the current window you are active in. My assumption is youre using async command to load an application or the default config example of 's-&' lamda. I would wonder if there is a way create a buffer and have the x application take over that buffer. Maybe someone who knows more than me can add to this.

Apologies if I have any details wrong, I am fairly new to EXWM but want to help where I can.

[minad]

My thoughts go to one of two things, should EXWM manage the loading of applications or should there be a seperate package that loads applications which manages how they are loaded. Such as a Emacs Application Manager (think dmenu?).

I use a small launcher which uses completion (completing-read). With Vertico or similar completion UIs the behavior is similar to dmenu. I am very happy with this setup.

In my opinion EXWM should stay limited to core wm-related functionality, and not include features like a launcher and a system status bar. Such features can be published as decoupled separate packages. Most other tiling window managers follow a similar approach, and focus on wm functionality.

However it is reasonable to offer integration points in EXWM which allow launchers to control window placement.

[ethanmoss1]

I use a small launcher which uses completion (completing-read). With Vertico or similar completion UIs the behavior is similar to dmenu. I am very happy with this setup.

Thanks for this information, is this a package that is available? I would be happy to make a wiki page regarding application launchers that are built in elisp. It could also link to external examples with a warning that intergration may not be as good as emacs implementations but this is beyond the scope of this current issue/discussion.

In my opinion EXWM should stay limited to core wm-related functionality, and not include features like a launcher and a system status bar. Such features can be published as decoupled separate packages. Most other tiling window managers follow a similar approach, and focus on wm functionality.
However it is reasonable to offer integration points in EXWM which allow launchers to control window placement.

I very much agree with both these points, it may be reasonable to have a section that introduces packages that are closely followed and have tighter integration without overlapping, with further documentation (again, I am willing to help here) we can have information on how to make your own implementations.

[minad]

Thanks for this information, is this a package that is available?

Not yet. It is part of my private Emacs configuration but I may publish it when I find the time to polish it a bit more. As far as I know multiple launcher packages exist already, e.g., https://github.com/SebastienWae/app-launcher. Also status bars: https://github.com/jollm/exlybar and https://github.com/zk-phi/symon.

I would be happy to make a wiki page regarding application launchers that are built in elisp. It could also link to external examples with a warning that intergration may not be as good as emacs implementations but this is beyond the scope of this current issue/discussion.

Please go ahead creating such a wiki page. Maybe document addons which work well (or not so well) with EXWM, e.g., xmobar, polybar, dmenu, albert, ...

So far there exists the page https://github.com/emacs-exwm/exwm/wiki/The-Emacs-Operating-System, which is about Emacs packages providing desktop features. The aforementioned packages app-launcher, symon, exlybar should also be mentioned there. It would help a lot to conduct a survey of the existing package landscape.

[Stebalien]

See #17 (comment), ch11ng/exwm#245.

The solution here is, IMO, to:

1. Watch for "startup" notifications. I think these come from the launcher itself and may require a compatible launcher? I'm not sure.
2. Create a blank buffer for the application.
3. Eventually load the application into that buffer.

[ethanmoss1]

1. Watch for "startup" notifications...

It seems though that not all applications respect this protocol which is annoying.

For example, Alacritty made a point about the protocols pitfalls. This may be a YMMV situation.

I'm wondering if there a way you can use the applications class name? I dont think you can determine this before loading the application however.

[Stebalien]

For example, alacritty/alacritty#2824 made a point about the protocols pitfalls. This may be a YMMV situation.

It won't work for everything, but I expect the "problem" applications are usually pretty fast to start in the first place (they tend to be small projects). IIRC, Firefox etc. supports this.

I'm wondering if there a way you can use the applications class name? I dont think you can determine this before loading the application however.

Not reliably.

[Stebalien]

Not reliably.

Basically, the issue is, there's no great way to know:

1. How many windows will be spawned.
2. Will any windows be spawned.
3. Are we spawning a new process, a window in an open application?

Etc...

---

However, one step forward would be some way to tell EXWM to map a specific X window to a specific existing buffer (instead of creating a new buffer as it usually does). This would let users fix issues with specific applications where they know how the application behaves by:

1. Creating a buffer for the target application.
2. Installing a manage hook (or maybe some kind of "exwm-manage-existing-buffer" hook) that waits for an application with a known class, title, etc.
3. Having the hook tell EXWM to use the buffer created in step 1.

[walseb]

Thanks for the comments!

I see now that this is a harder problem than I thought. Starting a process can result in any number of x windows, and it's hard to determine what command launched them.

I think the smallest step towards this could be to simply stop new x windows from replacing the currently selected buffer. Warning as I haven't tried the following code yet:

(add-hook 'exwm-manage-finish-hook (defun my/lambda-1708984220 ()
                                     (when (string-match-p "NAME" exwm-class-name)
                                       (switch-to-buffer (cadr (buffer-list))))))

One could also enable it for all x windows and make it toggleable, so you can enable it when launching troubling applications.

[Stebalien]

I think that'll be even more annoying, TBH. For fast-starting X windows, you want to take over the current window (or at least I do). I just don't want random popup windows taking over my main window when I'm typing.