When opening a PR, a "git ls-remote" call would appear in the Command
log. This is confusing, it's an internal detail that is not interesting
for the user to see.
When opening a PR, a "git ls-remote" call would appear in the Command log. This
is confusing, it's an internal detail that is not interesting for the user to
see.
This provides two fixes:
- proper handling of keypad keys on certain terminals (e.g. iTerm2)
- fix problems pasting certain emojis or east asian text on Windows
Terminal
Fixes#5171Fixes#5173
This provides two fixes:
- proper handling of keypad keys on certain terminals (e.g. iTerm2)
- fix problems pasting certain emojis or east asian text on Windows Terminal
When searching (not filtering) in a list view using `/`, moving the
selection now updates the "x of y" indicator of the search results to
the last one before the selection. Pressing `n` again searches from
there rather than from the previously shown result.
Also see corresponding gocui PR at
https://github.com/jesseduffield/gocui/pull/95.
Checking out a file discards all local modifications to that file;
checking out a directory discards modifications to all files in that
directory. This can result in lost work if the user isn't aware of this.
Instead of showing a confirmation (to which the user might press enter
too hastily, still losing their work), or showing a menu with
auto-stash/discard options, we simply show an error. The assumption is
that this is an unusual situation that users won't run into often, and
if they do, it's easy enough to manually address it by stashing or
discarding the changes as appropriate.
Fixes#5142.
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.
