Add dock state to workspace context

[FloppyDisco]

I love keybindings.

I spend way to much time thinking about them.

I also REALLY like working in Zed.

so far, however, I have found the key context system in Zed to be less flexible than in VSCode.
the HUGE context that is available in VSCode helps you create keybindings for very specific targeted scenarios.

the tree like structure of the Zed key context means you loose some information as focus moves throughout the application.
For example, it is not currently possible to create a keybinding in the editor that will only work when one of the Docks is open, or if a specific dock is open.

this would be useful in implementing solutions to ideas like #24222
we already have an action for moving focus to the dock, and we have an action for opening/closing the dock, but to my knowledge (very limited lol) we cannot determine if that dock is open unless we are focused on it.

I think it is possible to create a more flexible key binding system by adding more context information to the higher up context ancestors.
while:

Workspace right_dock=GitPanel
    Dock
        GitPanel
            Editor

may seem redundant, it actually communicates fundamentally different information than:

Workspace right_dock=GitPanel
    Pane
        Editor

the first says "the GitPanel is in the right hand dock AND IT IS FOCUSED",
while the second means "Focus is on the Editor, and the GitPanel just happens to be open in the right hand dock"

This change adds a new set of identifiers to the Workspace key_context that will indicate which docks are open and what is the specific panel that is currently visible in that dock.

examples:

• left_dock=ProjectPanel
• bottom_dock=TerminalPanel
• right_dock=GitPanel

in my testing the following types of keybindings seem to be supported with this change:

// match for any value of the identifier
"context": "Workspace && bottom_dock"
"context": "Workspace && !bottom_dock"
// match only a specific value to an identifier
"context": "Workspace && bottom_dock=TerminalPanel"
// match only in a child context if the ancestor workspace has the correct identifier
"context": "Workspace && !bottom_dock=DebugPanel > Editor"

some screen shots of the context matching in different circumstances:

the persistent_name values for ProjectPanel and OutlinePanel needed to be updated to not have a space in them in order to pass the Identifier check. all the other Panels already had names that did not include spaces, so it just makes these conform with the other ones.

I think this is a great place to start with adding more context identifiers and i think this type of additional information will make it possible to create really dynamic keybindings!

Release Notes:

• Workspace key context now includes the state of the 3 docks

[SomeoneToIgnore]

Note: those 2 persistent_name changes spoil the DB restoration, at least the first time the new version is out.

Seems redundant to do?

[ConradIrwin]

This makes sense to me, but as Kirill points out we can't change the persistant_name. I'd suggest adding a second method (that can default to the first) for this identifier.

[FloppyDisco]

@ConradIrwin
If I'm understanding the feedback here and I have read the docs correctly:

There is a SQLite DB that handles the session restoration when the app is opened, and the table that refers to these panels uses persistent_name as the identifier?

What sort of session information is tied the Project Panel and the Outline Panel?

Wouldn't it just be like the display width?

Is there no way of running migrations on this DB?

I'm just thinking out loud here.

I contemplated creating a new method on the Panels, but changing these two to match all the other panels seemed like the smaller change.

I can create a new method that will just return a key context identifier for the Panel. Give me a bit to work on it.

[FloppyDisco]

@ConradIrwin

alrighty,

this PR now includes a new method panel_key()

this returns the *_PANEL_KEY const for each of the Panels.
this feels more appropriate than using the persistent_name()

let me know what you think.

[ConradIrwin]

Sounds good! It would also be possible to write a migration to do this, but I think there are two different things happening here.

[FloppyDisco]

@ConradIrwin
sorry. i saw some tests didn't pass for formatting so i pushed a commit for cargo fmt and it removed auto-merge.

[FloppyDisco]

Release Notes:

• Workspace key context now includes the state of the 3 docks

[ConradIrwin]

thanks for fixing it!