i3 workspace/bindsym ordering

[arcnmx]

The order that keybinds appear in i3's config file is relied on by i3 to make a decision of what workspaces to use at startup. keybindings being an attrset doesn't allow for explicit ordering to control or fix this.

I'm running into this while adding a tenth 0 -> 10 workspace bind, which ends up sorted in the config file before 1/2/3 that I want it to start with. A solution is to remove all the default workspace bindings and reset them with an explicit order in extraConfig - I'm mostly just filing this issue to record the need for ordering and see if there may be any other solutions. Perhaps an improvement to keybindings could change the type to accept more than just a plain string as an action - it's currently missing the ability to properly specify release keybindings - and allow order customization?

[uvNikita]

Nice catch @arcnmx, thanks for reporting the issue!

If I'm not mistaken, a common way to solve such issue in nix is to transform keybindings type from types.attrsOf to types.loaOf which will allow specifying keybindings either as an ordered list or unordered attributes.

[arcnmx]

Hm, I'm not sure? loaOf seems to result in an attrset rather than an ordered list, and although it does seem to preserve ordering for "unnamed" list items, it will intermingle them with named keys that were specified via an attrset, so the final sort won't be what you want. The keybind data type (string) also only includes the action and not the binding, which is currently determined from the attr key, so unnamed bindings would be incomplete without a keybind submodule type.

A list could however work with a type like listOf (attrsOf str) and coercedTo singleton or something? I certainly do like the idea of a list and mkBefore working over something silly like a .sortOrder attribute.

[uvNikita]

I was thinking to do something similar to the matchBlocks option in the ssh module which gives you a possibility to specify blocks as an ordered list:
https://github.com/rycee/home-manager/blob/f99d4ba7c4d02a2b46c45ec3ee1f0d3112a51dd8/modules/programs/ssh.nix#L285

I guess one way to achieve this would be to set the keybindings type to something like this:

coercedTo
  (attrsOf (nullOr str))
  (mapAttrsToList (k: a: { binding = k; action = a;))
  (listOf keybindingsModule)

keybindingsModule would then have corresponding binding and action options.

This will allow to pass either unordered attributes that will be converted to a list of keybindings module or an ordered list right away.

[arcnmx]

I was thinking to do something similar to the matchBlocks option in the ssh module which gives you a possibility to specify blocks as an ordered list:

It does kind of do that, though "Note, if the order of rules matter then this must be a list" means that specifying even a single block as a named attr can break the expected ordering. The point here I guess though is specifically only the workspace bindings are important to order, so that's fine as long as the default also specifies those as a list I think?

Also: the use of a list will inhibit default overrides and null being used to unset them etc. The code flattening to the config file will probably need to have a pass that removes duplicates beyond the first to allow default/mkDefault/mkOverride/etc. to work properly?

keybindingsModule would then have corresponding binding and action options

I was going to suggest that, but thought it may not be worth it over just using something closer to the existing type:

let keybind = attrsOf (nullOr str); in coercedTo keybind singleton (listOf keybind)

and

{
  config.keybindings = [
    { "a" = "b"; }
    etc
  ];
}

In which case you don't really have to worry about the inconsistency of the "action = " syntax only being usable in list form. There are a few ways to accomplish this though, and a keybindingsModule type may be good to have anyway so release = true; can also be supported properly.

This probably makes the default overriding problem even worse, though, hm... Anywhere a list is introduced, whether it's loaOf, my variant or yours... Interacting with the defaults and overriding parts of them becomes messy, I think?

[ghost]

This is also an issue for sway.

[thiagokokada]

Could we maybe use the hm.types.dagOf? In this case, the problem probably can solved with:

xsession.windowManager.i3 = {
  "${modifier}+Shift+1" = "...";
  "${modifier}+Shift+0" = hm.dag.entryAfter [ "${modifier}+Shift+1" ] "...";
}

[stale]

Thank you for your contribution! I marked this issue as stale due to inactivity. If this remains inactive for another 7 days, I will close this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

• If this is resolved, please consider closing it so that the maintainers know not to focus on this.
• If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

• If you are also experiencing this issue, please add details of your situation to help with the debugging process.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

If you have nothing of substance to add, please refrain from commenting and allow the bot close the issue. Also, don't be afraid to manually close an issue, even if it holds valuable information.

Closed issues stay in the system for people to search, read, cross-reference, or even reopen--nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

[arcnmx]

Mean bot, afaik this is still a relevant issue.

[sumnerevans]

Maybe we can change the keybinding type from:

type = types.attrsOf (types.nullOr types.str);

to

type = with types; attrsOf (either (nullOr str) (submodule {
  options = {
    command = mkOption { type = str; };
    sortOrder = mkOption { type = int; default = 0; };
  };
}));

(I know that's not the exact syntax, just trying to get an idea out there.)

Then, we can convert all of the ones that are nullOr str to the attrset version, and then if people want to specify the order of certain keybindings, they can.

[SebTM]

I can't find use-cases other then the default workspace where the order of keybindings is relevant, so with the merge of a few days ago, this can maybe be closed?

[arcnmx]

I believe the ordering of all workspace keybindings still matter, I'm not sure whether a singular "default workspace" is enough? Certainly not for multiple monitor setups.

[tejing1]

It seems like the thing for multi-monitor users would be to extend the defaultWorkspace idea, and just allow specifying a list of workspace numbers/names and put those keybindings, in order, at the beginning of the keybinding list, leaving the rest after. The default value for this option could be a singleton list containing the value of defaultWorkspace, so single-monitor users don't have to think about it.

[SebTM]

I maybe found something interesting, which could maybe a workaround:

We have workspaceOutputAssign, and in my case the default workspace on multi-monitor setup is the first workspace configured for the output. As this option is a list my entries are sorted like I gave it in the config. this means I can configure Workspace X on Output Y to be the default. Can you confirm this?

[DCsunset]

I believe this is still an issue for users with multiple monitors. It should work if we can make the defaultWorkspaces accept a list of workspaces. Any update on this issue?