| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
100 was an unrealistically narrow width; make it a little wider so that we will
have to truncate things less often.
|
|
We don't need this for production code, but it will be needed for tests in the
next commit.
|
|
This makes it possible to write deterministic tests for views that use it.
|
|
The previous commit handles this case too.
|
|
Situations where a view's width changes:
- changing screen modes
- enter staging or patch building
- resizing the terminal window
For the first of these we currently have special code to force a rerender, since
some views render different content depending on whether they are in full-screen
mode. We'll be able to remove that code now, since this new generic mechanism
takes care of that too.
But we will need this more general mechanism for cases where views truncate
their content to the view width; we'll add one example for that later in this
branch.
|
|
Add 'lvim' as a new standardTerminalEditorPreset, since lunarvim uses an alias for nvim.
|
|
|
|
This seems to be a left-over from an earlier iteration of the code. Removing it
fixes the crash.
|
|
|
|
Co-authored-by: Jesse Duffield <jessedduffield@gmail.com>
|
|
Treat <disabled> setting as equivalent to "null"
in keybindings user configs.
|
|
refreshWorktrees re-renders the branches view, because the branches view shows
worktrees against branches. This means that when both BRANCHES and WORKTREES are
requested to be refreshed, the branches view would be rendered twice in short
succession. This causes an ugly visual glitch when force-pushing a branch,
because when pushing is done, we would see the ↑4↓9 status come back from under
the Pushing status for a brief moment, to be replaced with a green checkmark a
moment later.
Fix this by including the worktree refresh in the branches refresh when both are
requested. This means that the two are no longer running in parallel for an
async refresh, but hopefully that's not so bad.
|
|
I'm pretty convinced we don't need it. Git itself does a good job of making sure
that concurrent operations don't corrupt anything.
|
|
|
|
|
|
|
|
When pulling/pushing/fast-forwarding a branch, show this state in the branches
list for that branch for as long as the operation takes, to make it easier to
see when it's done (without having to stare at the status bar in the lower
left).
This will hopefully help with making these operations feel more predictable, now
that we no longer show a loader panel for them.
|
|
Very similar to WithWaitingStatus, except that the status is shown in a view
next to the affected item, rather than in the status bar.
Not used by anything yet; again, committing separately to get smaller commits.
|
|
Not used by anything yet; committing this separately in the interest of having
smaller independent commits.
|
|
We can just return our error to WithWaitingStatus, it will take care of
reporting it.
|
|
From the Go specification [1]:
"3. If the map is nil, the number of iterations is 0."
`len` returns 0 if the map is nil [2]. Therefore, checking `len(v) > 0`
before a loop is unnecessary.
[1]: https://go.dev/ref/spec#For_range
[2]: https://pkg.go.dev/builtin#len
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
|
|
|
|
This is not a complete fix, but it's good enough to fix the spurious test
failures of submodule/reset.go. We have some vague hope to fix this in a more
sustainable way by somehow improving our concurrency model fundamentally, but
that's a more long-term undertaking, and it's annoying that this test fails so
often, so let's fix it in this way for now.
|
|
A new gui config flag 'portraitMode':<string> is added to influence when
LazyGit stacks its UI components on top of one another.
The accepted values are 'auto', 'always', 'never'.
'auto': enter portrait mode when terminal becomes narrow enough
'always': always use portrait mode unconditional of the terminal
dimensions
'never': never use portraid mode
Signed-off-by: Louis DeLosSantos <louis.delos@gmail.com>
|
|
|
|
We're going to make this user config struct a more authoritative source of truth.
Some of these fields weren't actually explained anywhere so I've added explanations.
In places where a lot of explanation is required I've linked to existing explanations in other docs.
|
|
It's confusing if the cheatsheet generator prints output but this one doesn't.
|
|
This has several benefits:
- it's less code
- we're using the same mechanism to generate all our auto-generated files, so if
someone wants to add a new one, it's clear which pattern to follow
- we can re-generate all generated files with a single command
("go generate ./...", or "make generate")
- we only need a single check on CI to check that all files are up to date (see
previous commit)
|
|
|
|
Pausing at breakpoints and stepping through code can often take longer than 40s,
so the timeout is annoying when debugging.
|
|
|
|
This makes the debugging experience better.
|
|
|
|
|
|
For the "cli" and "tui" modes of the test runner there's a "-race" parameter to
turn it on; for running tests on CI with go test, you turn it on by setting the
environment variable LAZYGIT_RACE_DETECTOR to a non-empty value.
|
|
We still want to close the pty if the command failed.
|
|
Previously there was no way to render a view's search status without also moving the cursor
to the current search match. This caused issues where we wanted to display the status
after leaving the view and coming back, or when beginning a new search from within the
view.
This commit separates the two use cases so we only move the cursor when we're actually
selecting the next search match
|
|
- **PR Description**
Should probably solve #2691
- **Please check if the PR fulfills these requirements**
* [x] Cheatsheets are up-to-date (run `go run scripts/cheatsheet/main.go
generate`)
* [x] Code has been formatted (see
[here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#code-formatting))
* [x] Tests have been added/updated (see
[here](https://github.com/jesseduffield/lazygit/blob/master/pkg/integration/README.md)
for the integration test guide)
* [x] Text is internationalised (see
[here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#internationalisation))
* [x] Docs (specifically `docs/Config.md`) have been updated if
necessary
* [x] You've read through your own file changes for silly mistakes etc
|
|
|
|
|
|
Now that we no longer show it in a loader panel, but in the app status view,
it's awkwardly long (the loading animation is much further to the right than for
other waiting status texts). Hopefully seeing just "Fast-forwarding <branch>" is
enough to be able to tell what's happening.
|
|
|
|
|
|
Since Loader and renderAppStatus need to agree on it, it helps for it to be a
constant in case we want to change it.
|
|
|
|
This test is interesting because it shows a credentials prompt inside a
WithWaitingStatus. Prior to this branch this test would have hung forever.
|
|
We do this for two reasons:
- when popping up a credentials prompt, it looks distracting if the waiting
status keeps spinning while the user is typing the password
- the task that updates the waiting status periodically would keep the program
busy, so integration tests would wait forever for the program to become idle
again
|
|
|
