21 Commits
Author SHA1 Message Date
Stefan Haller b3491f4e37 Cleanup: filter out empty keybindings earlier
This doesn't make a difference for the behavior, it just looks strange to
include the empty bindings first and then filter them out in the next statement.
2026-05-28 19:26:43 +02:00
Stefan Haller 76d0dc15ca Fix crash when keybindings are disabled that we want to show in the status bar
If a keybinding that we want to display in the options bar was set to <disabled>
by the user, in pre-0.62 versions we would still display the command, but with
no keybinding. This was arguably not very useful before, but now it actually
crashes because we would now try to display the first key of the slice of
configured keys (crash introduced in 3d18ee8f91). Fix the crash by not showing
those commands at all.
2026-05-28 19:26:43 +02:00
Stefan Haller 5748d82073 Convert keybinding fields to Keybinding
Until now every keybinding config field was a plain string. That meant a user
couldn't ask for two keys to invoke a command — the config silently accepted
only one form.

Convert every string-typed field across all 13 KeybindingXxxConfig structs to
Keybinding so the union type extends to every command. Defaults wrap their
single-key value in Keybinding{...} so the generated Config.md still renders one
scalar key per binding.

The alt fields keep their separate Binding registrations for now: this commit
does not yet introduce the merge mechanism that folds them into the main field —
that comes in a follow-up. Consumers previously calling opts.GetKeys on a string
field now call opts.GetKeys on the Keybinding, or take .String() / Keys[0] where
a single value is needed.

Adds a Keybinding.String helper for rendering, schema-generator work that
inlines the Keybinding union into each consuming property, and a unit test
covering the user-facing scalar/sequence YAML forms for quit.
2026-05-25 15:32:47 +02:00
Stefan Haller 26366641c0 Rename Key to Keys in Binding, KeybindingsOpts, and MenuItem
This is a straight rename with no other code changes. Doing it in a separate
commit to keep the diff of the previous one somewhat readable.
2026-05-25 15:18:18 +02:00
Stefan Haller 3d18ee8f91 Use a slice of keys for each binding
This is a pure refactor in preparation for letting users configure multiple
alternate bindings for a single command. Every Binding still has exactly one
key, so nothing changes visibly: the cheatsheet, the on-screen options bar,
and the keybindings menu all render identically.

When a Binding ends up with multiple keys, the on-screen options bar will
show only the first (to avoid clutter); the cheatsheet will show all of them (in
a later commit). For now both paths take Key[0].

MenuItem.Key is changed in the same way, it also has a slice of keys now.

In this commit we keep the name `Key` in Binding, KeybindingOpts and MenuItem,
instead of renaming them to `Keys` right away, in order to keep the diff a bit
more readable. We'll do the rename separately in the next commit.
2026-05-25 15:18:18 +02:00
Stefan Haller 69e99ffd64 Move keybindings.LabelFromKey to config package
So that it is next to KeyFromLabel.
2026-04-30 22:22:53 +02:00
Stefan Haller 64996d12d9 Add Key type
This bundles the keyName and a rune, so that we don't have to pass these around
separately everywhere. This should make it easier to swap out the rune for a
string when we upgrade to tcell v3.
2026-04-30 22:14:26 +02:00
Stefan Haller ff58687b68 Cleanup: remove unnecessary function Label()
It's a no-op. (I think this might not have been the case in the past, where
Label() was needed to "normalize" a keybinding or something.)
2026-04-30 22:14:26 +02:00
Stefan Haller 4961c4b678 Avoid duplicate key bindings in options map
Sometimes there is a local and a global keybinding for the same key; if both are
configured to be shown in the options map, we should only show the local one
because it takes precedence. This happens for example for <esc> in a popup, or
for <esc> in the focused main view.

Note that this is also a problem in the keybindings menu, and we don't solve
that here.
2025-08-14 17:59:38 +02:00
Stefan Haller 9eb1e3a729 Add a GetShortDescription() method to Binding 2025-08-01 10:35:16 +02:00
Stefan Haller 542525743c Make WorkingTreeState a struct, and add cherry-picking and reverting states 2025-04-20 15:53:17 +02:00
Stefan Haller b31607250d Fix layout of options view for non-english languages
The width calculations didn't take multi-byte characters into account.
2025-03-06 08:19:35 +01:00
Stefan Haller f6f2a52dee Bump gocui and adapt lazygit code
Original commit message of the gocui change:

This fixes View.Size, Width and Height to be the correct (outer) size of a view
including its frame, and InnerSize/InnerWidth/InnerHeight to be the usable
client area exluding the frame. Previously, Size was actually the InnerSize (and
a lot of client code used it as such, so these need to be changed to InnerSize).
InnerSize, on the other hand, was *one* less than Size (not two, as you would
have expected), and in many cases this was made up for at call sites by adding 1
(e.g. in calcRealScrollbarStartEnd, parseInput, and many other places in the
lazygit code).

There are still some weird things left that I didn't address here:
- a view's lower-right coordinates (x1/y1) are one less than you would expect.
  For example, a view with a 2x2 client area like this:
    ╭──╮
    │ab│
    │cd│
    ╰──╯
  in the top-left corner of the screen (x0 and y0 both zero) has x1/xy at 3, not
  4 as would be more natural.
- a view without a frame has its coordinates extended by 1 on all sides; to
  illustrate, the same 2x2 view as before but without a frame, sitting in the
  top-left corder of the screen, has coordinates x0=-1, y0=-1, x1=2, y1=2. This
  is highly confusing and unexpected.

I left these as they are because they would be even more of a breaking change,
and also because they don't have quite as much of an impact on general app code.
2024-12-01 10:40:08 +01:00
Stefan Haller 7ed94c0410 Replace CurrentContext() with Context().Current() 2024-08-17 11:14:51 +02:00
Jesse Duffield 0f9d9e13d1 Show mode-specific keybinding suggestions
As part of making lazygit more discoverable, there are certain keys which you almost certainly
need to press when you're in a given mode e.g. 'v' to paste commits when cherry-picking. This
commit prominently shows these keybinding suggestions alongside the others in the option view.

I'm using the same colours for these keybindings as is associated with the mode elsewhere e.g.
yellow for rebasing and cyan for cherry-picking. The cherry-picking one is a bit weird because
we also use cyan text to show loaders and app status at the bottom left so it may be confusing,
but I haven't personally found it awkward from having tested it out myself.

Previously we would render these options whenever a new context was activated, but now that we
need to re-render options whenever a mode changes, I'm instead rendering them on each screen
re-render (i.e. in the layout function). Given how cheap it is to render this text, I think
it's fine performance-wise.
2024-01-28 08:33:13 +11:00
Jesse Duffield 9cc1d65280 Add demo test variant
We're piggybacking on our existing integration test framework to record  demos that we can include in our docs
2023-07-31 22:33:04 +10:00
Jesse Duffield d772c9f1d4 Use sentence case everywhere
We have not been good at consistent casing so far. Now we use 'Sentence case' everywhere. EVERYWHERE.

Also Removing 'Lc' prefix from i18n field names: the 'Lc' stood for lowercase but now that everything
is in 'Sentence case' there's no need for the distinction.

I've got a couple lower case things I've kept: namely, things that show up in parentheses.
2023-05-25 23:52:19 +10:00
Jesse Duffield 460a166e16 Stop displaying navigation keybinding at bottom of screen
The reason for this is that now our labels for navigation keybindings are larger so they
take up more realestate. It's not the kind of thing a user needs to be told anyway,
anybody is going to try out hjkl and the arrow keys when a TUI opens up.

We could map from <up> to the single character up unicode rune but given you can rebind this stuff
I'd rather keep it simple
2023-05-21 11:01:15 +10:00
Jesse Duffield 43251e7275 split context common from helper common 2023-04-30 13:19:53 +10:00
Jesse Duffield 509e3efa70 lots more refactoring 2023-04-30 13:19:53 +10:00
Jesse Duffield 8edad826ca Begin refactoring gui
This begins a big refactor of moving more code out of the Gui struct into contexts, controllers, and helpers. We also move some code into structs in the
gui package purely for the sake of better encapsulation
2023-04-30 13:19:52 +10:00