Eyebrowse integration enhancement (go to buffer vs. bring buffer)

[syl20bnr]

Now we have multiple workspaces support per perspective thanks to @bmag we need to support these two commands:

1. (go to buffer) switch to buffer in perspective and automatically switch to the workspace where the buffer is visible (in case of multiple workspaces switch to the first one)
2. (bring buffer) "bring" the buffer to the current workspace

2. is a fallback to 1. if the latter returns nil.

I propose that "go to buffer" is the default action bound to SPC l b and "bring buffer" is a secondary action which could be bound to SPC l B (we may have to find another binding for imenu-buffer under SPC b B).

[joehillen]

Sounds good to me. 👍

Should the behaviour of SPC b b change? Maybe change it to the current behaviour of SPC l b?

[syl20bnr]

I'm not for changing the behavior of SPC b b which display all the opened buffers no matter the current context:

• SPC b b is global scope
• SPC p b is project scope
• SPC l b is layout scope

I'm more in favor of changing the behavior of SPC b b to match SPC l b "go to buffer" (in this case, it would change the perspective and workspace) and SPC b B would import a buffer into current perspective/workspace.

[bmag]

Sounds good to me too. I think it will be quite helpful.
Please note there is no built-in functionality to search for a buffer in a workspace, but it's possible to write one. It requires analyzing a window-state-get object, though. Anyone heard of a library that analyzes window-state-get objects?
Also, obvious alternative mnemonic for ibuffer is SPC b i. Is the new SPC b B supposed to be the same as SPC l a, or will there be differences?

[bmag]

I wrote some code that makes it easy to implement a go-to-buffer function. Most of the code analyses window-state objects, so I'm considering publishing it as (a part of) an ELPA package, so it would take at least several more days until I upload it somewhere.
switch-to-buffer already acts as the described bring-buffer, so we can just use it as is.

@syl20bnr do we still want to implement this? If so, where should we put the go-to-buffer and bring-buffer commands? There were changes to the UX (as you know) since two months ago, and I'm not sure where to put the commands.

[bmag]

I have implemented a spacemacs/goto-buffer-workspace command in #5201. It addresses the part of the suggestion above. It's not clear to me how to continue from here, so I'm leaving it as is.

[TheBB]

#5201 is merged.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!