Command palette

[pluiedev]

Discussed in #4195

^{Originally posted by Xophmeister December 31, 2024}
In tmux, Prefix+: will open a command line input to allow you to enter arbitrary tmux commands. This is similar to Vim, where : enters command line mode.

It would be useful to have such a feature in Ghostty to try out actions, without having to define a keybinding for them.

Maintainer's Note: Instead of a text interface with commands, it would be perhaps more idiomatic for a GUI application to display a pop up command palette instead, à la VS Code, IntelliJ IDEA, Blender, etc. There, we can also display default keybindings, which can be more easily learned by new users.

[tristan957]

I agree with what you said. Have you looked at GNOME Builder's UX for this for the GTK apprt? I'm hoping this is something libadwaita will provide in the future, but should not block an initial implementation.

[pluiedev]

Prior art:

• VS Code's command palette: https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette
• Superhuman's blog post on how they designed their command palette: https://blog.superhuman.com/how-to-build-a-remarkable-command-palette/

Working demo (GTK):

2025-02-07_02-43-47.mp4

[pluiedev]

Have you looked at GNOME Builder's UX for this for the GTK apprt?

I haven't — there are some technical issues behind this that would make its inclusion in libadwaita somewhat difficult. (Essentially libadwaita doesn't support ListViews for its boxed list pattern, and ListBoxes don't really react dynamically enough to updating queries or are scalable enough for potentially a large number of entries.)

[jcollie]

Working demo (GTK):
2025-02-07_02-43-47.mp4

Can we fix the width of the window? I find the changing size as the results are narrowed down distracting.

[mitchellh]

Great work on the GTK side, looks good!

How would parameterized commands work with this? I suggest we just keep it simple and follow the same format as expected for keybind because that is also the underlying core API we invoke. But how should we show it in the palette?

It'd be great to comptime generate a lot of the metadata that this uses (if we aren't already).

[jcollie]

How would parameterized commands work with this? I suggest we just keep it simple and follow the same format as expected for keybind because that is also the underlying core API we invoke. But how should we show it in the palette?

Maybe show it with a trailing : to indicate that it needs a parameter of some sort.

[pluiedev]

I went with the approach to have separate commands for each parameterized keybind.

We need some sort of manual list of commands anyway, since autogenerating from either apprt.Action or input.binding.Action isn't really wise — there are some actions in both tagged unions that just don't make sense for a GUI context. (For instance, all the text input binds for input.binding.Action, and the internal apprt actions like renderer_health or render_inspector.)

It even supports showing the custom keybinds the user has set, because this is actually reusing the same key.accelFromTrigger mechanism we already have. (Below is default settings)

[mitchellh]

We need some sort of manual list of commands anyway, since autogenerating from either apprt.Action or input.binding.Action isn't really wise — there are some actions in both tagged unions that just don't make sense for a GUI context.

I haven't thought much about it but the premise makes sense, I do challenge how to manually specify though. I think it could make sense to do a comptime enum subset in src/input/Binding.zig similar to how do for src/apprt/action.zig. It's a little crazy but it enforces a bunch of compiler safety that helps make this a reasonable endeavor.

We could then expose this data via libghostty as well (for macOS and future embedder).

[pluiedev]

That wouldn't really work that well... Say we have new_split. To parametrize it would mean to split it into five brand new ones: one for each cardinal direction and one for auto split. That would mean we need to add four new entries to the enum.

(From the implementor's perspective, on GTK at least it would be much easier if commands are just enums, since that means we can use AdwEnumListModel and avoid adding data to the list model ourselves. We can then map each command to the corresponding parametrized action, and the human-readable command name.)

[jcollie]

With comptime it's easy enough to generate enums, at least for things that have a bounded set of choices. Things like text:, increase_font_size and decrease_font_size would be more problematic.

Maybe a hybrid approach? comptime generate what we can and then augment with some curated manual additions.

[pluiedev]

We just shouldn't allow stuff like csi or text. The terminal is right there. For {in,de}crease_font_size we can just set the increment/decrement to 1, which works pretty well for me. An alternative idea is to spawn a new dialog with a counter that the user can input into, though that sounds very much overkill.

[jcollie]

Yeah csi and text (and esc) should not be included. Basically any action that has an unbounded set of parameters like that should be disallowed. Yeah, for the font size we'd manually add increment/decrement by one (and any others that make sense).

[mitchellh]

That wouldn't really work that well... Say we have new_split. To parametrize it would mean to split it into five brand new ones: one for each cardinal direction and one for auto split. That would mean we need to add four new entries to the enum.

Hm, not exactly what I'm thinking. I mean there would be a subset enum that has the subset of tags we support for the command palette. That subset enum then would fan out to the support command palette entries (either manually or automatically).

Rough pseudo-code:

pub const CommandPaletteEntry = struct {
    name: [:0]const u8,
    description: [:0]const u8,
    action: Action,
};

pub const Action = union(Tag) { 
    // existing input.Binding.Action
};

pub const Tag = enum {
    ...

    // Can return null to indicate the tag doesn't support command palettes.
    pub fn commandPalette(comptime self: Tag) ?[]const CommandPaletteEntry {
        ...

        // We wouldn't have to make this fully manual. Things like `new_split` could
        // call something like `CommandPaletteEntry.generate(...)` to inspect that
        // its a non-exhaustive enum value and generate all the combinations.
    }
};

pub const command_palette: []const CommandPaletteEntry = comptime { };

I'm not sure that's exactly the right shape.

In any case, the goal would be, if we add a new action to Action, we'd get a compiler error telling us we need to ensure we add our commandPalette entry (which may be null). And the full list of entries would be available for all apprts so we can easily export via libghostty and so on.