- **PR Description**
Fix some linter warnings that I keep getting locally because I'm running
a newer version of golangci-lint than the pinned version we use on CI.
Also, update the pinned version in CI to 1.60 so that we are in sync
again.
Finally, upgrade the golangci-lint-action version to the latest,
although I'm not sure what difference this makes. The linting step runs
faster now, maybe because of better caching -- I noticed that
previously, loading and saving the cache took a very long time, which
often made the lint step the slowest of all.
- **PR Description**
When switching branches, there is a "Checking out" inline status
displayed next to the branch (but only sometimes? I think if the action
completes too quickly there is no status). If it does get displayed and
the checkout results in an autostash confirmation prompt, pressing
escape to cancel the action will cancel the checkout and close the
prompt. However, the inline status will still be displayed next to the
branch and doesn't go away by itself. Performing a manual UI refresh
(`R`) fixes the state.
If the prompt was confirmed instead, then this issue would not happen.
Reproduction:
```bash
git init
echo -e "a\n\nb" > file
git add .
git commit -m "add file"
echo -e "a\n\nc" > file
git add .
git commit -m "edit last line"
git checkout -b dev HEAD~
echo -e "b\n\nb" > file
lazygit
```
Switch to the other branch in the branches panel and press escape on the
prompt. The "Checking out" inline status should be stuck.
- **PR Description**
Followup to #3825: we decided there that we don't want to underline
links in delta diffs by default, but only on mouse hover. This PR does
that; it makes it possible to decide per view whether links should be
underlined always, or only on hover. We set this to only on hover for
the main views, so that links in diffs are not underlined (also affects
the status view though), but all other links we want to underline always
for better discoverability.
Note that this doesn't only affect the diff views, which are the ones where we
want this, but also the status view, where the plan was to keep them underlined
always for better discoverability. We could make this configurable dynamically
(by adding another flag to ViewUpdateOpts), but actually I think it's fine this
way.
- **PR Description**
Any newly loaded custom command coming from the per-repo config file should add
to the global ones (or override an existing one in the global one), rather than
replace all global ones.
Any newly loaded custom command coming from the per-repo config file should add
to the global ones (or override an existing one in the global one), rather than
replace all global ones.
We can achieve this by simply prepending the newly loaded commands to the
existing ones. We don't have to take care of removing duplicate key assignments;
it is already possible to add two custom commands with the same key to the
global config file, the first one wins.
If a `t.FileSystem().FileContent("file.txt", Equals("bla"))` assertion fails
because the file doesn't exist, the error would say
Expected path 'file.txt' to not exist, but it does
which is very confusing.
- **PR Description**
Don't cancel sticky range select when pressing `<`/`>`, `,`/`.` in the
patch explorer view. This was already working correctly in list views.
Fixes#3823.
- **PR Description**
First we fix the crash reported in #3812 (see there for reproduction
recipe), and then we add a more general fix for avoiding crashes in
similar situations that we don't know about yet.
I'm not really happy with the brittleness of all this (the
interdependency between rendering and updating search results, that is),
but I haven't found a good way to untangle this yet.
Fixes#3812.
We fixed one specific scenario where this happened ealier in this branch, but in
case there are more that we don't know about yet, at least make sure we don't
crash.
I don't know what this condition is supposed to guard against, or whether we
really need it (it was added in 06ca71e955, and the commit message of that
commit only says "fix bug"). But if we do need it, then it seems that `>=` is
more correct than `>`.
It is already possible to search a filtered list by searching first, and then
enabling a filter, so I found it inconsistent to not allow searching when you
are already filtering. One reason for not allowing this might be that the search
status (on the left) hides the filter status (on the right), but if we think
that's enough reason to not allow both at the same time, then we should cancel a
search when we enter filtering.
- **PR Description**
There are many situations where this can arise. Some examples are:
- the terminal window is small, and you are showing a view that shows more
content than fits into the view port, and the view is scrolled all the way
down; now you resize the terminal window to a taller size. Previously, the
scroll position of the view would stay the same, so it would add blank space
at the bottom; now it will scroll to fill that blank space with content
- expandFocusedSidePanel is on, you go to the bottom of a list view, now switch
to a different panel, then scroll that (now unfocused) panel all the way down
with the scroll wheel; now you focus that panel again. It becomes larger
because of the accordion behavior, but would show blank space at the
bottom.
And probably others that I can't remember right now. I only remember that I
always found it confusing to look at a view that had blank space at the bottom
even though it had more content to scroll into view.
There are many situations where this can arise. Some examples are:
- the terminal window is small, and you are showing a view that shows more
content than fits into the view port, and the view is scrolled all the way
down; now you resize the terminal window to a taller size. Previously, the
scroll position of the view would stay the same, so it would add blank space
at the bottom; now it will scroll to fill that blank space with content
- expandFocusedSidePanel is on, you go to the bottom of a list view, now switch
to a different panel, then scroll that (now unfocused) panel all the way down
with the scroll wheel; now you focus that panel again. It becomes larger
because of the accordion behavior, but would show blank space at the bottom.
And probably others that I can't remember right now. I only remember that I
always found it confusing to look at a view that had blank space at the bottom
even though it had more content to scroll into view.
- **PR Description**
Allows to use `delta --hyperlinks` as a pager, which turns line numbers
in the diff into clickable links that take you to the respective file.
For VS Code users, I recommend to combine this with
`--hyperlinks-file-link-format="vscode://file/{path}:{line}"`
so that it jumps to the right line.
In addition, I added a few commits that replaces our old, manual ad-hoc
handling of links in various places (status view, confirmation panels,
information view) with the new hyperlinks feature, which cleans up the
code a bit.
Fixes#3817.
It might seem cleaner to integrate this into the text style system, so that you
could say `ts := ts.Url("some link")` and then `ts.Sprint("my text")`. However,
this would require adding a new field to TextStyle, which I didn't want to do.
#### PR Description
* Fix some minor problems related to cursor movement in an auto-wrapped
commit message
* Allow clicking in an editable view to set the cursor (most useful in
longer commit descriptions)
* Allow switching between commit message and description by clicking
It is just unexpected and confusing when it isn't.
There's something weird about the cursor position when scrolling it out of view;
it will be shown clamped to the visible area of the view (as if it had moved in
the opposite direction than the scroll direction), but then when you type
something again, or just move the cursor with the arrow keys, the view will jump
back to where the cursor really was. This looks confusing, and it might be
reason enough not to allow scrolling the view at all.
It doesn't seem to be used by anything, it looks like we only need to implement
the method so that the IController interface is satisfied. But still, it doesn't
hurt to be correct here, and might avoid confusion in the future when somebody
does try to use the method.
