[1.21 Canary] User actions have IDs added to them in the JSON about terminal HOT 11 CLOSED

This is by design and mentioned in Pankaj's action IDs spec. This is the way that we will give durable IDs to user-originated actions so that we can pull apart key/button/menu bindings and actual commands.

If you're expecting something different, we should have a team sync about it!

PR #16904, spec #16816

from terminal.

As for user-specified commands, if no id is set, we will auto-generate one for that command based on the action and any additional arguments. For example, the split pane right command above might result in an autogenerated id User.SplitPaneRight.

Ah, so, this might be under spec'd? I'd assume that we generate IDs for those commands, but not reserialize those "generated" IDs. So that people don't need to know anything about the existence of IDs, unless they want to add the action to {{menu}}

from terminal.

We will then restructure ... users' settings files ...:

• ...
  • There will now be one json block ... which will also contain the id.

from terminal.

I think it's important for the IDs to become stable at the first opportunity, otherwise somebody could add an action to the menu with its internal ID, and then change something about it (which generates a new ID) and break the link with the one in the menu.

from terminal.

otherwise somebody could add an action to the menu with its internal ID

How? If we don't give the action an ID in the json, then how would they be using that action's internally generated ID somewhere else in the settings?

(unless you're assuming that there's some UI-based way of doing that sometime in the next 10 years)

from terminal.

The reason we're tackling action things now is to enable UI-based stuff in 1.21. Is there a problem with writing IDs to the user's settings?

from terminal.

Is there a problem with writing IDs to the user's settings

It's extremely noisy, if users aren't using that feature (which none will be in 1.21)

(unless actions in the new tab menu et. al will actually be landing in 1.21, which seems like a lot of a lift in the next 7 days)

from terminal.

I've got a couple thoughts...

• The JSON file is much less of a "UI" than it used to be, which frees us up to do things like this. That's not to say it's not a UI.
• Getting to the ideal form of the settings file early is fine, if we're going to get there eventually.
• It's like profiles that only have names: we always serialize GUIDs for them, because that's the only durable way to refer to them.
• We made a mistake making action names or values into the hash keys, because it is complicated when you're using a resource or when you want to bind an entire action to multiple keys¹ and stuff like that. Putting the durable ID up front immediately eliminates all of those concerns.

from terminal.

Right now, I think you need N copies of the action (one per key) and if you want to change what it does you need to update all N copies (right?)

We don't allow for actions anywhere other than in actions right now, actually. We've been holding off adding support for actions literally anywhere else until we got action IDs. New Tab Menu? We explicitly skipped actions in the v1 PR for that, because this wasn't done yet.

It feels like the point in the Command Palette spec where we were thinking "Okay, all actions need to be given a name if they want to show up in the command palette", and we decided immediately after: "what if we could just generate names for everything"?

Users don't need to known about the action IDs, certainly not in 1.21. And if we do add a "new tab menu" SUI page in 1.22, and a user wants to add one of their custom actions then - we can always decide to commit that ID to the file then.

from terminal.

We don't allow for actions anywhere other than in actions right now, actually.

That's not required for my scenario to exist!

What if I want to make alt-shift-d/e/l split: left instead? Gotta edit all three.

If you want to change the spec, propose it and talk to @PankajBhojwani about it. We're going to have action IDs eventually, so why pull them now?

from terminal.

The thing is, the immediate next PR is going to degranulate the actions from the key bindings in the settings file, so there's a map of keys to actions and a map of actions to their actual commands. That practically requires action IDs as the linkage token between them. We should meet to go over the final goal of the spec if we're misaligned on that!

from terminal.