1
0
mirror of https://github.com/jesseduffield/lazygit.git synced 2024-12-12 11:15:00 +02:00
Commit Graph

29 Commits

Author SHA1 Message Date
Jesse Duffield
7df4b736cf be a bit more lenient 2020-03-09 12:41:41 +11:00
Jesse Duffield
e47ad846c4 big golangci-lint cleanup 2020-03-09 12:23:13 +11:00
Jesse Duffield
355f1615ab supporing custom pagers step 1 2020-03-04 00:12:23 +11:00
Jesse Duffield
f94d0be2c9 refactor the way we render lists 2020-02-25 21:21:07 +11:00
Jesse Duffield
46be280c92 support searching in side panels
For now we're just doing side panels, because it will take more work
to support this in the various main panel contexts
2020-02-24 22:18:04 +11:00
Jesse Duffield
23bcc19180 allow fast flicking through any list panel
Up till now our approach to rendering things like file diffs, branch logs, and
commit patches, has been to run a command on the command line, wait for it to
complete, take its output as a string, and then write that string to the main
view (or secondary view e.g. when showing both staged and unstaged changes of a
file).

This has caused various issues. For once, if you are flicking through a list of
files and an untracked file is particularly large, not only will this require
lazygit to load that whole file into memory (or more accurately it's equally
large diff), it also will slow down the UI thread while loading that file, and
if the user continued down the list, the original command might eventually
resolve and replace whatever the diff is for the newly selected file.

Following what we've done in lazydocker, I've added a tasks package for when you
need something done but you want it to cancel as soon as something newer comes
up. Given this typically involves running a command to display to a view, I've
added a viewBufferManagerMap struct to the Gui struct which allows you to define
these tasks on a per-view basis.

viewBufferManagers can run files and directly write the output to their view,
meaning we no longer need to use so much memory.

In the tasks package there is a helper method called NewCmdTask which takes a
command, an initial amount of lines to read, and then runs that command, reads
that number of lines, and allows for a readLines channel to tell it to read more
lines. We read more lines when we scroll or resize the window.

There is an adapter for the tasks package in a file called tasks_adapter which
wraps the functions from the tasks package in gui-specific stuff like clearing
the main view before starting the next task that wants to write to the main
view.

I've removed some small features as part of this work, namely the little headers
that were at the top of the main view for some situations. For example, we no
longer show the upstream of a selected branch. I want to re-introduce this in
the future, but I didn't want to make this tasks system too complicated, and in
order to facilitate a header section in the main view we'd need to have a task
that gets the upstream for the current branch, writes it to the header, then
tells another task to write the branch log to the main view, but without
clearing inbetween. So it would get messy. I'm thinking instead of having a
separate 'header' view atop the main view to render that kind of thing (which
can happen in another PR)

I've also simplified the 'git show' to just call 'git show' and not do anything
fancy when it comes to merge commits.

I considered using this tasks approach whenever we write to a view. The only
thing is that the renderString method currently resets the origin of a view and
I don't want to lose that. So I've left some in there that I consider harmless,
but we should probably be just using tasks now for all rendering, even if it's
just strings we can instantly make.
2020-01-12 11:17:20 +11:00
Jesse Duffield
8aa1062e06 extract out some logic for list views 2019-11-21 22:07:14 +11:00
Jesse Duffield
12b84307ac specify upstream when pushing a branch for the first time 2019-11-11 23:30:30 +11:00
Jesse Duffield
e85310c0a9 add mouse support 2019-11-10 22:32:13 +11:00
Jesse Duffield
1a38bfb76d do not return focus to commitsFiles view after selecting to start a new patch 2019-11-05 19:22:01 +11:00
Jesse Duffield
beaebb7dc7 handling when to show the split panel 2019-11-05 19:22:01 +11:00
Jesse Duffield
0f0fda1660 allow stashing staged changes
reinstate old stash functionality with the 's' keybinding
2019-06-06 20:50:19 +10:00
Jesse Duffield
d84dfc23e7 Rely on model rather than view to focus a point
Currently when we want to focus a point on a view (i.e. highlight a
line and ensure it's within the bounds of a view's box, we use the
LinesHeight method on the view to work out how many lines in total
there are.

This is bad because for example if we come back from editing a file,
the view will have no contents so LinesHeight == 0, but we might
be trying to select line 10 because there are actual ten things we
expect to be rendered already. This causes a crash when e.g. 10 is
greater than the height of the view.

So we need to pass in to our FocusPoint method the actual number of
items we want to render, rather than having the method rely on the
LinesHeight, so that the method knows to scroll a bit before setting
the cursor's y position.

Unfortunately this makes for some awkward code with our current setup.
We don't have a good interface type on these state objects so we now
need to explicitly obtain the len() of whatever array we're rendering.

In the case of the menu panel this is even more awkward because the items
list is just an interface{} and it's not easy to get the list of that, so
now when we instantiate a menu we need to pass in the count of items
as well.

The better solution would be to define an interface with a getItems
and getLength method and have all these item arrays become structs
implementing the interface, but I am too lazy to do this right now :)
2019-03-23 11:54:25 +11:00
Jesse Duffield Duffield
8c0ea8f45f mouse support 2019-03-02 17:49:30 +11:00
Jesse Duffield
ad93b4c863 consider whether the view has focus when rendering the contents of a view 2019-02-16 15:17:44 +11:00
Jesse Duffield
9489a94473 Make merge panel its own panel 2018-12-11 22:02:12 +11:00
Jesse Duffield
ff856b7630 fetching branches without checking out 2018-12-08 11:51:47 +11:00
Jesse Duffield
ca3afa2a39 standardising how list panels deal with cursor movement 2018-12-08 11:51:47 +11:00
Jesse Duffield
99a8b1ae8b making a start on unidirectional data binding to fix these UI bugs 2018-12-08 11:51:47 +11:00
Jesse Duffield
c00c834b35 standardise rendering of lists in panels 2018-09-17 21:02:30 +10:00
Jesse Duffield
f8b484f638 don't use newlines at the end of panel buffers 2018-09-12 18:23:25 +10:00
Dawid Dziurla
e21f739f4f
add renderGlobalOptions
render only global options for all panels
2018-09-04 16:07:31 +02:00
Dawid Dziurla
97ad4a1643
delete options 2018-09-04 15:40:29 +02:00
Dawid Dziurla
20073d0293
don't panic
"panic: runtime error: index out of range"

when executing stash pop 'g' from help menu
2018-09-03 17:54:06 +02:00
Dawid Dziurla
cc3fa4b79d
make '?' key visible on every panel 2018-09-03 17:52:05 +02:00
Mark Kopenga
faf218f465 Fixed comments from jesseduffield on issue #137 2018-08-16 11:31:50 +02:00
Mark Kopenga
88e1a815fe Fixed comment on issue #137 from @jesseduffield 2018-08-16 07:16:32 +02:00
Mark Kopenga
295093a432 Translated pkg/gui/stash_panel.go 2018-08-15 11:12:46 +02:00
Mark Kopenga
dfafb98871 tried to update to latest master 2018-08-14 11:05:26 +02:00