Behaviour of workspaces that have both a number and a name

[rsgowman]

I'm submitting a…

[ ] Bug
[x] Feature Request
[ ] Documentation Request
[ ] Other (Please describe in detail)

Current Behavior

When using workspaces that contain both a number and a name (eg 5:a), I've observed:

• Creating a new workspace with the same number (but different name) results in that workspace being added before the existing one. (e.g. creating workspaces named 1, 2:a, 2:b, 3 in that order, results in workspaces 1, 2:b, 2:a, 3.)
• 'workspace next' skips over workspaces with the same number. e.g. if you have workspaces: { 1, 2:a, 2:b, 3} and are on workspace 1, then 'workspace next' traverses 1 -> 2:a -> 3 -> 1, skipping 2:b entirely.

Desired Behavior

• New workspaces with the same number (but different name) should go to the right of existing workspaces with the same number, similar to how named workspaces operate today.
• 'workspace next' (and prev, and next-on-output) should not skip these workspaces.

Impact

[ ] This feature requires new configuration and/or commands

Environment

Output of i3 --moreversion 2>&-:

i3 version: 
Binary i3 version:  4.19.2-135-g761e322c © 2009 Michael Stapelberg and contributors
Running i3 version: 4.19.2-133-geada44be+ (pid 3394018)
Loaded i3 config:
  /home/rich/.config/i3/config (main) (last modified: Tue 05 Oct 2021 12:53:34 PM, 39904 seconds ago)

The i3 binary you just called: /home/rich/devel/github/i3/i3/build/i3
RUNNING BINARY DIFFERENT FROM BINARY ON DISK!
The i3 binary you are running: /home/rich/devel/github/i3/i3/build/i3 (deleted)

(Yeah, I've been playing around with this a bit. But tl;dr: this is origin/next.)

- Linux Distribution & Version: ubuntu 20.04
- Are you using a compositor (e.g., xcompmgr or compton): Yup; compton.

I've already got a patch prep'd and ready to go for both of these; I'll create a PR shortly. (That should clear up anything I've been vague about above.)

Thanks for considering this feature request!

[i3bot]

Please note that new features which require additional configuration will usually not be considered. We are happy with the feature set of i3 and want to focus in fixing bugs instead. We do accept feature requests, however, and will evaluate whether the added benefit (clearly) outweighs the complexity it adds to i3.

Keep in mind that i3 provides a powerful way to interact with it through its IPC interface: https://i3wm.org/docs/ipc.html.

[Airblader]

The second part here is a duplicate of #4452 which is a bug.

The second part, if to be changed at all, should probably also be seen as a bug and not a new feature. However, here it doesn't seem obvious to me that the new behavior is clearly better in a way that is enough to justify potentially breaking someone's setup.

[rsgowman]

The second part here is a duplicate of #4452 which is a bug.

Ah, OK! I didn't check the existing issues; guess I should've. :)

The second part, if to be changed at all, should probably also be seen as a bug and not a new feature. However, here it doesn't seem obvious to me that the new behavior is clearly better in a way that is enough to justify potentially breaking someone's setup.

(I assume you mean "first part")

I could argue that this is a bug... The current behaviour is inconsistent with how named workspaces work, and also a little unintuitive. (In absence of any other sorting criteria, adding new things to a list usually causes them to go to the end of the list, not the beginning.) It's certainly true that this could break someone's setup, but... https://xkcd.com/1172/

In any case, if you only want the second part, then I'm happy to re-work the PR to only do that. Just let me know.

Thanks again!

[Airblader]

At the very least it'd be good to split this into two separate PRs since they are separate issues. We can still discuss the other one then (sorry, fresh back from vacation and only quickly scanning things right now).

[rsgowman]

Ok, here's the second part first as it seems to be uncontroversial: #4578.

And here's the first part second: rsgowman#1. It's based on ^ since the order that numbered+named workspaces are created in obviously plays a role in the tests. (I'll retarget it at origin/next when/if ^ lands.)