This bumps our gocui dependency, which recently learned to render
multi-rune grapheme clusters properly. This fixes rendering of a lot of
emojis such as ⚡️ or 🏴.
Fixes#4854Fixes#4347Fixes#3811Fixes#3711Fixes#3606Fixes#3514Fixes#2702Fixes#2409
Draw only the visible lines of the reflogs panel, like we do for
commits.
Since the reflog can get very long, this saves some memory but
especially some UI thread lag. In one of my repos I had over 11'000
reflog entries (I guess I should prune them more regularly...), and
rendering them took ~600ms; since this happens on the UI thread, there
was an annoying stall for half a second after every background fetch,
for example (even if the reflog panel is not visible).
Since the reflog can get very long, this saves some memory but especially some
UI thread lag. In one of my repos I had over 11'000 reflog entries (I guess I
should prune them more regularly...), and rendering them took ~600ms; since this
happens on the UI thread, there was an annoying stall for half a second after
every background fetch, for example.
This fixes a bug in ListContextTrait.FocusLine whereby the view would go blank
when scrolling by page (using ',' or '.') in views that have
renderOnlyVisibleLines set to true but refreshViewportOnChange set to false.
Currently we don't have any such views; the only ones who use
renderOnlyVisibleLines are commits and subcommits, and they also use
refreshViewportOnChange. However, we are going to add one in the next commit,
and eventually it might be a good idea to convert all our list views to that by
default, and get rid of the renderOnlyVisibleLines flag.
Move SetContentLineCount into OverwriteLinesAndClearEverythingElse. Calling it
separately beforehand is not concurrency safe; we need both to happen
when the view's writeMutex is locked.
It is possible to scroll the selection out of view using the mouse
wheel; after doing this, it would sometimes scroll into view by itself
again, for example when a background fetch occurred. In the files panel
this would even happen every 10s with every regular files refresh.
Fix this by adding a scrollIntoView parameter to HandleFocus, which is
false by default, and is only set to true from controllers that change
the selection.
Fixes#5097.
We have this logic to avoid constantly rerendering the main view when hitting
up-arrow when you are already at the top of the list. That's good, but we do
want to scroll the selection into view if it is outside and you hit up or down,
no matter if it changed.
It is possible to scroll the selection out of view using the mouse wheel; after
doing this, it would sometimes scroll into view by itself again, for example
when a background fetch occurred. In the files panel this would even happen
every 10s with every regular files refresh.
Fix this by adding a scrollIntoView parameter to HandleFocus, which is false by
default, and is only set to true from controllers that change the selection.
We want to do this whenever we switch branches; it wasn't done consistently
though. There are many different ways to switch branches, and only some of these
would reset the selection of all three panels (branches, commits, and reflog).
We move the selection down by the number of commits that were reverted (to keep
the same commits selected). However, this only happens after refreshing, which
has rendered the main view with the wrong commit, so we need to render it again
after moving the selection.
There are many other callers of MoveSelection in LocalCommitsController, but all
of them happen before the refresh. Revert is special because it needs to move
the selection after refreshing, e.g. when reverting the only commit of a branch.
Now that we can use 'k' as a menu item binding (this was fixed in
#5131), use it for the "keep" entry in the merge menu. I don't think
this will be a problem for people's muscle memory, given that this menu
is not encountered every day; and it's simply the better keybinding.
This reverts commit b32b55201e.
Now that we can use 'k' as a menu item binding (this was fixed in #5131), use it
for the "keep" entry in the merge menu. I don't think this will be a problem for
people's muscle memory, given that this menu is not encountered every day; and
it's simply the better keybinding.
This reverts commit b32b55201e.
Previously they would be shown as keybindings in the menu, but they
didn't work because their builtin functionality (select next/prev line,
scroll view left/right) would take precedence.
This will allow us to revert #4934; doing that in a separate PR, see
#5132.
This is not really super important because we are very unlikely to assign a key
such as esc or up/down to a menu item. However, users might do this in a custom
commands menu, and in that case it is important that the builtin keys still
work; or they might remap those builtin commands to other keys, in which case
they might conflict with single-letter keys in normal menus.
The test shows two problems: a <down> keybinding is not removed from a menu item
(the 'y' binding is removed though, which is correct), and keybindings such as
'j' and 'H' don't work. We will fix both of these separately in the following
commits.
Thank you for an awesome tool. I wanted to add support for codeberg.
Tested locally that opening pull-request works
### PR Description
Codeberg is a Gitea-based git hosting service that uses the same URL
patterns for pull requests and commits but differs on its hostname
Codeberg is a Gitea-based git hosting service that uses the same URL
patterns for pull requests and commits. This adds native support so
users don't need to manually configure it.
The confirmation used to make sense back when the Open MergeTool command
was its own top-level command; however, that command was changed in
#4889 to open a menu instead, and Open MergeTool is now just a submenu
entry in that menu, so it no longer needs a confirmation.
Fixes#5093.
The confirmation used to make sense back when the Open MergeTool command was its
own top-level command; however, that command was changed in 703f053a7e to open a
menu instead, and Open MergeTool is now just a submenu entry in that menu, so it
no longer needs a confirmation.
### PR Description
Use case: some repositories are cloned with a full SSH alias (without a
user). E.g. in `.ssh/config` you have
```
Host gitlab
HostName gitlab.com
User git
IdentityFile ...
```
and then you clone with `git clone gitlab:foo/bar`
According to the docs, you can add a service to `config.yaml` and it
should work:
```yaml
services:
gitlab: 'gitlab:gitlab.com'
```
But currently it doesn't because lazygit expects all remote URLs to have
a user. This can be fixed by the user by changing the URL to e.g.
`git@gitlab:foo/bar`, but it breaks the user flow and is quite
unexpected.
This PR changes `defaultUrlRegexStrings` and makes the `user@` part of
the remote URL optional. Fixes the issue for Github and Gitlab which use
the default regexes.
