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

24 Commits

Author SHA1 Message Date
Stefan Haller
4adca84d68 Make sure scrollbars have the right size initially
We refresh the view after reading just enough to fill it, so that we see the
initial content as quickly as possible, but then we continue reading enough
lines so that we can tell how long the scrollbar needs to be, and then we
refresh again. This can result in slight flicker of the scrollbar when it is
first drawn with a bigger size and then jumps to a smaller size; however, that's
a good tradeoff for a solution that provides both good speed and accuracy.
2023-03-21 18:26:18 +01:00
Jesse Duffield
7410acd1aa move merge conflicts code into controller 2022-08-07 11:16:03 +10:00
Jesse Duffield
524bf83a4a refactor to only have one context per view 2022-08-06 13:49:11 +10:00
Jesse Duffield
e68093fe99 add scrollbars 2022-04-16 17:29:17 +10:00
Jesse Duffield
1dd7307fde start moving commit panel handlers into controller
more

and more

move rebase commit refreshing into existing abstraction

and more

and more

WIP

and more

handling clicks

properly fix merge conflicts

update cheatsheet

lots more preparation to start moving things into controllers

WIP

better typing

expand on remotes controller

moving more code into controllers
2022-03-17 19:13:40 +11:00
Jesse Duffield
cdcfeb396f stop refreshing the screen so much 2022-01-15 14:15:41 +11:00
Jesse Duffield
802cfb1a04 render commit graph 2021-11-05 07:58:21 +11:00
Jesse Duffield
2fc1498517 some refactoring in anticipation of the graph feature 2021-11-01 10:03:49 +11:00
Jesse Duffield
80a8e9b04d fix merge conflict scrolling 2021-10-22 22:16:52 +11:00
Jesse Duffield
d672b7342f stop resetting scroll all the time 2021-10-17 19:45:57 +11:00
Jesse Duffield
93fac1f312 reduce flicker without worrying about carriage returns 2021-04-09 22:50:55 +10:00
Jesse Duffield
b03e2270a0 revert no-flicker due to carriage return weirdness 2021-04-08 23:17:27 +10:00
Jesse Duffield
8eb802d3a0 fix flicker issue in main view 2021-04-06 19:34:32 +10:00
Jesse Duffield
39ae122304 more refactoring 2021-04-06 19:34:32 +10:00
Jesse Duffield
da3e00823f allow submodule init and show submodule diff with a prefix 2020-10-02 08:09:42 +10:00
Jesse Duffield
f0a1544ebd more logging 2020-09-26 11:00:50 +10:00
Jesse Duffield
d9fa02c53b clean up interface for popup panels 2020-08-15 18:01:43 +10:00
Jesse Duffield
36ac764133 fix race condition when scrolling to merge conflict 2020-05-19 18:05:14 +10:00
Jesse Duffield
f80d15062b use reflog undo history pointer 2020-03-25 09:39:04 +11:00
Jesse Duffield
e47ad846c4 big golangci-lint cleanup 2020-03-09 12:23:13 +11:00
Jesse Duffield
b3522c48d9 refactor 2020-03-04 00:12:23 +11:00
Jesse Duffield
54241d8ab9 more generic way of supporting custom pagers 2020-03-04 00:12:23 +11:00
Jesse Duffield
355f1615ab supporing custom pagers step 1 2020-03-04 00:12:23 +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