-
Notifications
You must be signed in to change notification settings - Fork 15
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.
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
exwm-workspace-show-all-buffers broken? #90
Comments
I've been using this feature since day one and haven't had any issues. What are you using for completion? |
@Stebalien What do you mean by completion? If I go to the buffer menu (C-x C-b) and press enter on an app, whether it takes me there depends on whether that app is running on this workspace (screen) or a different one. If its this one, it works. If it's a different one, it doesn't. Similarly to if I press C-x b, and choose an app. |
I mean icicles, fido, icomplete, helm, vertico, etc. I assume that means you use the default one. I can't seem to reproduce the issue. Do you have any other buffer management/workspace packages? |
I don't use any of those,, I don't even know what a buffer / workspace package is. I'm a pretty vanilla emacs user. To be sure I removed my init.el, so all I'm running is some basic exwm setup, and the buffer menu/ editor / list is completely non functional for buffers that are not in the current workspace / screen. That means that any of the normal keys in the buffer menu ... "f", "o", "1", "" only work if the app is running in the same workspace. If it isn't, it just drops you into some other buffer. |
Oh, now I see what you're doing. Unfortunately, it seems to work fine here for me (both with multiple monitors and with multiple workspaces on a single monitor). What Emacs version are you using? |
GNU Emacs 29.4 .... Whatever Arch Linux serves up as emacs. |
Did you also set EDIT: Notice the layout in the variable name instead of workspace.
|
Wow, I didn't even realize there were two variables here. I just always set both of them.
It looks like the intended behavior was: if |
@Stebalien So as far as I can tell, exwm-layout-show-all-buffers moves a selected buffer to your current workspace when selected. exwm-workspace-show-all-buffers lists all buffers in the buffer list. My gripe is that if the former is nil, and the latter is t, then selecting a buffer in the list does nothing. What I would hope it would do would be warp you to that workspace and make that window active (if it's visible), and and if it's not visible, possibly make it visible in the last active window? There's a few options on what it can do, but surely doing something interesting is appropriate. |
I agree, that's what it should do. The fact that it doesn't seems like a bug. |
@xpusostomos I feel like it's something to think through in details as enabling a different behavior for EXWM buffers might make buffer switching unpredictable and confusing. The fact that it "steals" the selected EXWM buffer from another workspace is AFAIK a limitation of xserver. Xserver is not capable of rendering the same window twice and since emacs workspaces are just multiple emacs windows/frames, this makes the "stealing" behavior the only resolution to opening a currently opened window. A workaround that I have for the "stealing" issue in my config is to use tab-bar-mode instead of workspaces. Exwm buffers as well as any other buffer can co-exist in multiple tabs simultaneously. As to the implementing the expected behavior you described, I would like to use something like that as well. Yet that is not directly related to EXWM, but rather a generic emacs buffer switching problem. There are following builtin functions available now: Maybe there could be a new function switch-to-buffer-anywhere, that is aware of what buffers are currently opened in assignment to frame/tab/window hierarchy and automatically focus that frame, tab and window then. |
@ezemstov I would be curious to know what exwm-layout-show-all-buffers as a name, intends to convey. The behavior seems to be to "steal" buffers, but the name seems to imply something else. It's fine to have a buffer stealing option, in case you want that. But if you just want to warp there, I think that should be an option. There's four possibilities, the app is already visible but on another screen ( a visible workspace ), the app is already visible but on a hidden workspace. Or the buffer "belongs" to another visible workspace, but doesn't have a window, or the buffer belongs another non visible workspace, but doesn't have a window. People might have differing opinions how to handle each of those situations. Like for example, if I have exwm-workspace-show-all-buffers turned on, and I select a buffer, my preference might be to go to where it is visible if it's visible, but if it's not, steal it. Someone else might have the preference to go to where it's visible if it's visible, else warp to the visible workspace attached to the same screen and steal it there. Someone else might want to go to where it's visible if it's visible, else make visible the appropriate workspace that it belongs to, on the appropriate screen, and open a new window there if necessary. |
According to the documentation, if I set exwm-workspace-show-all-buffers to t, it will show all workspace buffers in all workspace's buffer lists. This is true, but seemingly useless. While I can see that say, Chrome is running somewhere, if I use any of the usual buffer list keys to go there, it doesn't work. Worse, it does the operation on the buffer list. For example, if I have konsole running in another workspace, and I press "1" in the buffer list, which should make konsole full screen, it does nothing to take me to konsole, but it makes the buffer list full screen instead. If I press enter, it similarly doesn't help me.
Am I missing something in saying this feature is for now, completely broken?
The text was updated successfully, but these errors were encountered: