1
0
mirror of https://github.com/jesseduffield/lazygit.git synced 2025-04-19 17:02:18 +03:00

11 Commits

Author SHA1 Message Date
Stefan Haller
2828fb94fb Rewrap patch when view width changes
This makes it so that when the staging view is resized, we keep the same patch
line selected (as opposed to the same view line, which may correspond to a
different patch line after resizing). It doesn't seem like a terribly important
feature for resizing the window, but it is essential when initially entering the
staging view: we select the first line of the first hunk in this case, but we do
that before layout runs. At layout time the view is then split into
unstaged/staged changes, and if this split is horizontal, the view gets narrower
and may be wrapped in a different way. With this commit we ensure that the first
line of the first hunk is still selected after that.
2024-12-23 12:24:09 +01:00
Stefan Haller
8302575078 Remove return value of Focus-related functions 2024-09-06 08:45:48 +02:00
Stefan Haller
5446683881 Remove return value of RenderToMainViews and some related functions 2024-09-06 08:45:48 +02:00
Stefan Haller
b91beb68e1 Remove return value of HandleRender 2024-09-06 08:45:48 +02:00
Stefan Haller
5659f1f3e9 Bump gocui
And adapt client code.
2024-09-06 08:45:48 +02:00
Stefan Haller
4e441127f3 Clear highlight in HandleFocusLost
Remove the old mechanism of clearing the highlight in Layout.

This fixes a problem with a wrong highlight showing up in the staging panel when
entering a file with only staged changes.

Reproduction recipe:
1. stage all changes in a file by pressing space on it in the files panel
2. enter the staged changes panel by pressing enter
3. unstage one of the changes
This makes the unstaged changes panel visible, but keeps the focus in the staged
changes panel. However, the highlight in the unstaged changes view becomes
visible, as if it were focused.

To explain why this happens, you need to know how the selection highlighting of
a view is turned on or off. It is turned on when it gains the focus, i.e. when
ActivateFocus is called on it, which in turn happens when PushContext is called.
It is turned off in Layout when gocui sees that the current view is no longer
the same as last time, in which case it calls onViewFocusLost on the previous
current view.

This mechanism only works reliably when there is at most one PushContext call
per event handler. If there is more than one, then the first one gets its
highlight turned on, then the second one, but since gocui has never seen the
first one as the active view in Layout, it doesn't get the highlight turned off
again even though it should.

And this happens in the above scenario. When pressing enter on a file with only
staged changes, we first push the staging context (in
FilesController.EnterFile), and then later we push the stagingSecondary context
when we realize we only have staged changes. This leaves the highlight of the
staging context on.
2024-06-23 13:21:49 +02:00
Jesse Duffield
e2db6a1732 remove context callback opts 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
Jesse Duffield
c517d1e0a2 update view cursor when selecting new line in patch explorer view 2023-02-18 10:19:34 +11:00
Jesse Duffield
524bf83a4a refactor to only have one context per view 2022-08-06 13:49:11 +10:00
Jesse Duffield
d82f175e79 refactor contexts 2022-03-17 19:13:40 +11:00