As a followup to #5571, improve performance for inline spinners too.
This requires a bit of preparation; in particular, we change
ListContextTrait.HandleRender to no longer force a UI layout/redraw, so
callers need to take care of this themselves where needed. This requires
careful testing to see that we didn't miss any situation where redrawing
only worked by accident; see the first commit of the branch for an
example.
Now that HandleRender no longer does an implicit Render(), we can use it inside
OnUIThreadContentOnly to save performance, on the assumption that rerendering a
view that contains an inline spinner never changes the layout.
self.c.Render() at the end of HandleRender was there to schedule a gocui Update
tick so the view content modified above would actually get drawn. For UI-thread
callers (the great majority -- keybinding handlers, the layout function itself,
popup resize, etc.) this was unnecessary work, since gocui already runs a
layout/redraw cycle after every event. SimpleContext.HandleRender doesn't call
Render() either, so this aligns the two implementations.
The few callers that drove HandleRender from a worker goroutine and relied on
Render() for the flush were wrapped in OnUIThread in the preceding commits, so
the implicit Render is no longer needed.
Also, Render() being called *before* setFooter() looks like it might have been a
theoretical race; this is no longer an issue now.
SetSuggestions has two callers: prepareConfirmationPanel calls it directly on
the UI thread, while editors.promptEditor and
SuggestionsContext.RefreshSuggestions call it via AsyncHandler, which runs the
result closure on a worker goroutine. The worker path currently relies on
HandleRender's self.c.Render() to flush the view update. Wrap the body in
OnUIThread so the worker path stays correct when Render() is removed; for the
UI-thread caller the extra bounce is harmless.
refreshBranches runs on a worker goroutine and re-renders the commits view
directly to refresh the branch-head visualization. As with refreshView, this
currently only flushes because HandleRender ends with self.c.Render(). Wrap the
explicit HandleRender call (along with the LocalCommitsMutex pair around it) in
OnUIThread so it keeps working once Render() is removed.
An async refresh dispatches refreshXyz on a worker goroutine, which then calls
refreshView -> PostRefreshUpdate -> HandleRender. Today the final
self.c.Render() inside ListContextTrait.HandleRender is what triggers a UI flush
from the worker. We're going to remove that Render() call, so prepare by
wrapping refreshView's body in OnUIThread.
This moves the entire rendering of the view (and the ReApplyFilter/ReApplySearch
stuff) to the UI thread, not just the layout. I don't expect this to make a
difference in practice, and it is already one step towards my long-term goal of
moving all view rendering to the UI thread (see
https://github.com/jesseduffield/lazygit/issues/2974#issuecomment-1729154768).
Unrelated to this branch, just because we're touching this code: there's little
reason to set the color on the background thread but the text on the UI thread.
Set them both together on the UI thread. Avoids a data race (unlikely to be a
problem in practice, we're talking about a 64-bit int, but still).
In 0d195077e4 we improved the performance of the status bar spinner by
avoiding a layout. This is fine from one spinner tick to the next, but it's a
problem when spinning starts or ends (or in the hypothetical case that the
status text changes in the middle of the operation, which we never do in
lazygit, but theoretically could). In this case a layout is needed so that the
rest of the status bar gets pushed over appropriately (or moves back to the left
when the spinner ends), and also so that the bottom line is shown or hidden
properly for users who set gui.showBottomLine to false.
To fix this, keep track of the status string width and force a layout whenever
it changes. This includes the beginning and end of an operation when it changes
from empty to non-empty or vice versa.
There is currently no observable misbehavior from this bug, but that's only
because we must have a HandleRender call somewhere that forces a full layout
when an operation starts or ends. We will remove the Render() call from
HandleRender at the end of this branch, at which point the misbehavior would be
visible if we didn't fix it here.
With a very slow spinner rate (seconds), you can see that at the beginning of an
operation the bottom line leaves a gap for where the status will go, but the
status (and spinner) is only drawn the first time the spinner ticks. The reason
is that layout looks at GetStatusString to decide how much room to leave, rather
than at the actual content of the AppStatus view; the view content is only set
by renderAppStatus the first time the spinner ticks.
Fix this by making layout look at the actual content of the view so that the
layout is in sync with what is drawn. This also avoids flicker if an operation
is so fast that it finishes before the spinner ticks for the first time,
especially for users who set gui.showBottomLine to false.
### PR Description
This fixes#4734, where lazygit would use a lot of CPU when the spinner
was shown due to redrawing the entire screen every time the spinner
needed a redraw.
The change adds the ability to request a UI redraw without invalidating
the full UI, thus only redrawing the spinner, re-routing the spinner to
this new flow.
CPU usage on a chromebook went from 60% to 5% when the spinner is shown.
Changing the refresh rate of the spinner from 50ms to 200ms brings it
down from 5% to 1% if ever we would like to change the default,
personally I prefer the slower moving spinner, but that's subjective.
This didn't cause a bug so far because switching repos always happens from
within an OnWaitingStatus, so the spinner would take care of calling layout and
draw. However, later in this branch we are going to optimize the spinner so that
it no longer calls layout, at which point this would break, so make sure we
rerender at the point where it's needed.
Our most recent change to the script (58309b02a9) broke it because the
anchored regex's no longer match the beginning of the subject. Fix this
by omitting the hash, which is a bit unfortunate but probably acceptable
(I rarely look at the output of the script anyway).
Our most recent change to the script (58309b02a9) broke it because the
anchored regex's no longer match the beginning of the subject. Fix this by
omitting the hash, which is a bit unfortunate but probably acceptable (I rarely
look at the output of the script anyway).
Modifiers were moved into Key in 22169e22f, but the separate Modifier field
on types.Binding and gocui.keybinding was left behind. The keypress matcher
already compares modifiers via Key.Equals, so the old field is never read on
the dispatch path; it just got passed through SetKeybinding and stored.
Drop it from gocui.keybinding, types.Binding, and the SetKeybinding /
DeleteKeybinding signatures, and remove every now-redundant Modifier:
gocui.ModNone struct field. Mouse bindings keep their own Modifier (on
ViewMouseBinding) since that path still consults it.
I noticed that it compares key.keyName and key.str separately instead of calling
key.Equals, but instead of deciding whether that's a problem, just delete the
function when nobody needs it.
While I strongly prefer the alt-arrow bindings myself, I'm worried that
existing users might not be happy about the change, so I'm reverting it.
I'm working on supporting multiple keybindings for every command, so
once that's in, we can change the default to include both.
While I strongly prefer the alt-arrow bindings myself, I'm worried that existing
users might not be happy about the change, so I'm reverting it.
I'm working on supporting multiple keybindings for every command, so once that's
in, we can change the default to include both.
In the Remotes panel, when selecting a remote that has push URLs, show
them in the main view in addition to the fetch URL(s).
Addresses half of #5566 (just the showing part, not the editing).
The commit graph used '⏣' (U+23E3 BENZENE RING WITH CIRCLE) for merge
commits and '◯' (U+25EF LARGE CIRCLE) for regular commits. Both have
very poor coverage in popular monospace fonts:
- '⏣' lives in the Misc Technical block and is essentially absent from
every common monospace font (Source Code Pro, JetBrains Mono, Fira Code,
Cascadia Code, Hack, Iosevka, Menlo, Consolas, Monaco, IBM Plex Mono,
Ubuntu Mono, Noto Sans Mono, Inconsolata). It is always drawn from a
system fallback font.
- '◯' is the late-addition LARGE CIRCLE codepoint. It is present in some
fonts (Cascadia, Fira Code, Hack, Iosevka, Menlo, Noto Sans Mono) but
missing from many others, including Source Code Pro and most Nerd Font
derivatives based on it.
This is why the graph renders inconsistently across platforms even when
the same monospace font is configured: each OS picks a different
fallback font (Apple Symbols on macOS, Segoe UI Symbol on Windows,
Noto/DejaVu/Symbola on Linux), and the substituted glyphs differ in
shape, weight, and advance width. '◯' is also East Asian Ambiguous
width, so some terminals render it wider than one cell, exaggerating the
misalignment.
Replace the symbols with codepoints from the foundational 1991 Geometric
Shapes block, which has far broader font coverage:
- Merge: '◎' U+25CE BULLSEYE -- concentric circles, the visually closest
cousin to the previous benzene-ring glyph.
- Commit: '○' U+25CB WHITE CIRCLE -- the same hollow-circle silhouette
as before, just a more universally available codepoint.
The new symbols are present in the font directly in significantly more
cases; and when fallback is still required, they are universally
well-drawn (unlike '⏣', which many fallback fonts also lack).
I also considered choosing suitable nerd font symbols for those who are
using nerd fonts, on the assumption that these must work better because
they are guaranteed to be in the font and no fallback font substitution
is necessary; several suitable icons could be considered, e.g.
`nf-cod-circle_large` or `nf-md-circle_double`. Surprisingly, these
didn't work well, and the reason is that (at least in the font I am
using) these are defined with a glyph width that is wider than their
advance width, which means they draw in different sizes depending on
whether they are followed by a space or not. The glyphs we picked above
don't have this problem.
And finally, I considered adding config options so that users with weird
fonts can pick symbols that work well for them. I would like to avoid
having to do this though; ideally we should be able to make a choice
that works well for everybody.
The commit graph used '⏣' (U+23E3 BENZENE RING WITH CIRCLE) for merge
commits and '◯' (U+25EF LARGE CIRCLE) for regular commits. Both have
very poor coverage in popular monospace fonts:
- '⏣' lives in the Misc Technical block and is essentially absent from
every common monospace font (Source Code Pro, JetBrains Mono, Fira
Code, Cascadia Code, Hack, Iosevka, Menlo, Consolas, Monaco, IBM
Plex Mono, Ubuntu Mono, Noto Sans Mono, Inconsolata). It is always
drawn from a system fallback font.
- '◯' is the late-addition LARGE CIRCLE codepoint. It is present in
some fonts (Cascadia, Fira Code, Hack, Iosevka, Menlo, Noto Sans
Mono) but missing from many others, including Source Code Pro and
most Nerd Font derivatives based on it.
This is why the graph renders inconsistently across platforms even
when the same monospace font is configured: each OS picks a different
fallback font (Apple Symbols on macOS, Segoe UI Symbol on Windows,
Noto/DejaVu/Symbola on Linux), and the substituted glyphs differ in
shape, weight, and advance width. '◯' is also East Asian Ambiguous
width, so some terminals render it wider than one cell, exaggerating
the misalignment.
Replace the symbols with codepoints from the foundational 1991
Geometric Shapes block, which has far broader font coverage:
- Merge: '◎' U+25CE BULLSEYE -- concentric circles, the visually
closest cousin to the previous benzene-ring glyph.
- Commit: '○' U+25CB WHITE CIRCLE -- the same hollow-circle silhouette
as before, just a more universally available codepoint.
The new symbols are present in the font directly in significantly
more cases; and when fallback is still required, they are universally
well-drawn (unlike '⏣', which many fallback fonts also lack).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
In the event that LC_ALL was set, for example, the tests would fail as
it takes precedence over LANG.
Tiny change that prevents language tests from failing if LC_ALL is set
(I also added LC_MESSAGES but I am not sure if that's also needed, from
what I read it also takes precedence) so I did not open an issue prior,
hopefully that's ok!
These have alternate keys (`<ctrl+h>` for backspace, and `<ctrl+f>` for
move-cursor-right). Both of these broke with commit 22169e22ffc46c5; the
first because it was accidentally omitted, the second because of a
stupid copy/paste mistake.
These have alternate keys (<ctrl+h> for backspace, and <ctrl+f> for
move-cursor-right). Both of these broke with commit 22169e22ffc46c5; the first
because it was accidentally omitted, the second because of a stupid copy/paste
mistake.
In #5563 we started to support an alternative syntax for keybindings:
instead of `<c-a>` you could say `<ctrl+a>`, which is easier to read
especially when there are multiple modifiers (`<ctrl+shift+x>` instead
of `<c-s-x>`). In this PR we make this new syntax the default.
Make the edit keybindings for "move-by-word" and "backspace-word"
platform-dependent so that they are with ctrl on Windows and Linux, but
alt on Mac. These are the common conventions on these platforms. Also,
make them configurable so that user who can't get used to the change can
map it back to what they were.
Add a "forward-delete-word" keybinding, bound to alt-delete on Mac, and
ctrl-delete on Windows and Linux.
Revamp lazygit's keybinding mechanism to support richer keybindings for
those terminals that support the newer keyboard protocols. This makes it
possible to use keybindings such as `ctrl-alt-shift-x`.
Change the default keybindings for moving commits up and down from
`ctrl-k`/`ctrl-j` to `alt-up`/`alt-down`; this is mostly for personal
preference, I find them easier to remember, and they are nicely similar
to moving a line of code up and down in many code editors. Also, change
the default binding for submitting a commit from the commit description
editor from `alt-enter` to `command-enter` on Mac, or `ctrl-enter` on
Linux and Windows; these are the same bindings that are used in many
multi-line edit field situations, e.g. in GitHub comments.
See docs/keybindings/Custom_Keybindings.md for caveats about terminal
compatibility.
The previous version only enumerated the supported (non-rune) bindings.
Replace it with a description of the syntax: how to spell single-rune
keys, special keys, and modified keys; how to combine modifiers; the
keyword forms for `<space>`, `<minus>`, `<plus>`; and which combinations
are rejected because terminals can't deliver them.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This changes not only how we store modifiers (inside of Key instead of passing
it separately), but also how we parse keybinding strings: it supports all
combinations of modifiers now (if the terminal supports it, that is).
An uppercase letter is not valid with ctrl, and only works because we lowercase
the string before parsing it. This will change later in this branch when we
start supporting bindings like <c-s-r>.
Refactor code to introduce a Key type in gocui that bundles the keyName
and a rune, so that we don't have to pass these around separately
everywhere.
This, and updating tcell to v3 lays the ground for supporting more
keybindings in terminals that support the CSIu keyboard protocol.
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.
Over the past few months or even years, [Jesse's gocui
fork](https://github.com/jesseduffield/gocui) has become more and more
tied to lazygit; I have repeatedly made API-breaking changes to it
without caring much about what this means for other clients like
lazydocker or lazynpm (and Jesse was ok with that).
Given that situation, it no longer makes much sense to maintain it in a
standalone repo, so copy it into lazygit; this will greatly reduce the
friction of making changes to it. If/when the time comes to update those
other clients to also benefit from the improvements we make here, we can
always copy the files back to the gocui fork and resume it there.
I copied all files except dot files (.github and .gitignore), the _examples
folder, and go.mod/go.sum.
At some point we may want to copy the files back to the gocui repo when other
clients (e.g. lazydocker) want to use the newer versions of them.
### PR Description
Instead of manually figuring out how much ahead each branch is from it's
upstream branch, use [for-each-ref
ahead-behind](https://git-scm.com/docs/git-for-each-ref/2.41.0#Documentation/git-for-each-ref.txt-ahead-behindcommittish)
if supported by the git binary.
On my Windows machine, using the lazygit repo with all 61 branches
created locally, it goes from ~8.5s to ~200ms.
It was also able to find a base branch for `assets` which the previous
iteration did not.
Fixes#5532
This is so that they look the same no matter what color palette the
terminal is using. (One user complained that the text for the Open state
is barely readable, because they are using a palette that has a very
pale green.)
GitHub uses slightly different colors depending on light vs. dark mode;
fortunately they are very close, so hopefully we can ignore this. I
picked the ones for dark mode here, on the assumption that this is more
common.
Also, not all terminals support true hex colors; for example,
Terminal.app on macOS doesn't, so it maps the colors to the closest ones
in the Xterm-256 palette. This shouldn't be a huge problem, but for some
reason it displays draft PRs as something closer to Cyan than grey, and
I don't understand why.
This is so that they look the same no matter what color palette the terminal is
using. (One user complained that the text for the Open state is barely readable,
because they are using a palette that has a very pale green.)
GitHub uses slightly different colors depending on light vs. dark mode;
fortunately they are very close, so hopefully we can ignore this. I picked the
ones for dark mode here, on the assumption that this is more common.
Also, not all terminals support true hex colors; for example, Terminal.app on
macOS doesn't, so it maps the colors to the closest ones in the Xterm-256
palette. This shouldn't be a huge problem, but for some reason it displays draft
PRs as something closer to Cyan than grey, and I don't understand why.
If the repo has multiple remotes, but only one of them is on Github (the
others might for example point to a self-hosted Critic server or
something like that), lazygit would still present a menu to choose the
remote for pull requests, but it would contain only that single entry.
That's pointless, pick it automatically without prompting.
If the repo has multiple remotes, but only one of them is on Github (the others
might for example point to a self-hosted Critic server or something like that),
lazygit would still present a menu to choose the remote for pull requests, but
it would contain only that single entry. That's pointless, pick it automatically
without prompting.
We add some tests while we're at it; these wouldn't have caught the problem,
because they only test getGithubBaseRemote which already takes the filtered
github remotes. It's still better than not having any tests; the real issue
could only have been caught with an integration test, which we don't bother
adding.
If we used to have a base remote (e.g. because there was only one), but
now we don't (e.g. because the user has added a second one, and we don't
know yet which one is the base), stop showing the cached PRs. This is
especially important in the case that the user cancels the prompt, in
which case we don't have a base remote for the rest of the session, but
would keep showing the (potentially stale) cached PRs forever.
You might ask why we don't retain the previous base remote in the case
that we used to have one but no longer do; this may be possible, but
it's error-prone because the user might have shuffled their remotes
around and changed their names. I don't think it's worth the risk.
If we used to have a base remote (e.g. because there was only one), but now we
don't (e.g. because the user has added a second one, and we don't know yet which
one is the base), stop showing the cached PRs. This is especially important in
the case that the user cancels the prompt, in which case we don't have a base
remote for the rest of the session, but would keep showing the (potentially
stale) cached PRs forever.
This is useful when cancelling out of the commit panel mid-sentence
(after having typed the space for the next word); when entering the
commit message panel again, the space was gone and you had to type it
again. Small thing, but it just seems better to resume the panel in
exactly the state that you left it in. (Which we actually don't do; we
don't remember the cursor position, or which of the subject/description
panels was active. That would be a separate improvement.)
Fixes#5519.
This is useful when cancelling out of the commit panel mid-sentence (after
having typed the space for the next word); when entering the commit message
panel again, the space was gone and you had to type it again. Small thing, but
it just seems better to resume the panel in exactly the state that you left it
in. (Which we actually don't do; we don't remember the cursor position, or which
of the subject/description panels was active. That would be a separate
improvement.)
The save path and the load path used to be asymmetric. On save, the textarea
getters applied strings.TrimSpace, which stripped any leading blank lines, a
trailing newline after the cursor, or indentation on the very first line of the
description — all of which are legitimate user content. On load,
SplitCommitMessageAndDescription did TrimSpace on the description as well, and
the preserved message was routed through that same git-format split because
HandleCommitPress passed it as OpenCommitMessagePanel's InitialMessage. The
result: every round-trip through "escape and reopen" silently mutated the
message.
The fix is to treat our own preservation file as its own format, distinct from
git's canonical "summary\n\nbody" format:
- The textarea getters return raw content. strings.TrimSpace moves to the one
place that still needs it: the empty-summary check in HandleCommitConfirm (git
itself strips trailing whitespace and blank lines, so no pre-trim is needed
before -m).
- SplitPreservedCommitMessage / SetPreservedMessageInView split on the single
"\n" our Join uses, without any trimming — truly lossless.
- SplitCommitMessageAndDescription keeps its git-format behavior but replaces
TrimSpace with TrimPrefix("\n"), so it strips only the blank-line separator
and leaves body indentation intact.
- HandleCommitPress now mirrors HandleWIPCommitPress: it no longer passes the
preserved message as InitialMessage. OpenCommitMessagePanel resolves the
preserved content itself, uses it for display via the preservation-format
setter, and stores it as the initial message so the close-time "did the user
change anything?" check still correctly detects a cleared panel.
- GetInitialMessage no longer trims. With raw getters on both sides of the
comparison, trimming here caused spurious non-matches (e.g. for preserved
content with trailing whitespace). The original motivation — matching a
"WIP: " prefix with trailing space — works unchanged.
- UpdateCommitPanelView becomes dead code and is removed; its one remaining
caller (history cycling, always git-format) goes directly through
SetMessageAndDescriptionInView.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Callers currently hand this function a trimmed description, so the output is
always clean. An upcoming change to the commit-panel getters will stop trimming
at the callsite (so that whitespace typed by the user round-trips through the
preservation file exactly), at which point the description can end with one or
more newlines. Without this change, a user who presses Enter after their
description body and then invokes "Add co-author" would end up with two blank
lines between the body and the trailer instead of the expected one.
Git's --grep option uses Basic Regular Expression syntax by default, which means
that the `[^\n]*` didn't do what was intended; it means "any character except
`\` or the literal letter `n`" — not "any character except newline."
Besides, `^` matched any line start, not only the start of the entire message,
so "any character except newline" would have been wrong anyway. Given this, the
script matched commits that have WIP or DROPME in the body, which is not what we
want. (The last commit of this branch is an example for that.)
Fix this by listing only the subject lines and grepping them outside of git;
this also lets us use a slightly simpler regex (we want to match WIP anywhere in
the subject).
This isn't possible with the default quit binding ('q'), but there's an
alternative binding (ctrl-c) that does work while the panel is open;
also, users can rebind quit to something like ctrl-q.
Fixes#5513.
This isn't possible with the default quit binding ('q'), but there's an
alternative binding (ctrl-c) that does work while the panel is open; also, users
can rebind quit to something like ctrl-q.
We'll want to call just the preservation step when the app is quitting
with the commit message panel open: at that point the view-hiding and
context-popping in CloseCommitMessagePanel are pointless (the app is
about to exit), and some of the focus-lost side effects could be
surprising during teardown.
There's no reason for this; when opening the panel next time, it will be
populated again. Also, it doesn't make sense to do this only when not preserving
the message.
Related to #5124
## Changes
- Extended existing retry logic to handle transient ref lock errors
- Added retry for "cannot lock ref" and "cannot update ref" error
messages
- Extracted retryable error check into helper function for clarity
These errors can occur intermittently during fetch/pull operations on
large repositories and typically succeed on retry.
Stefan Haller
