This tells git to checkout all .md and .json files with Unix line feeds,
even on Windows. This shouldn't be a problem for working with these
files on Windows, as all modern text editors and IDEs should be capable
of editing Unix files transparently; but it makes it possible to run
`go generate ./...` on Windows, which assumes Unix line feeds in a few
places.
On Windows, trying to use lazygit with a language other than English
would result in the error message `open translations\ja.json: file does
not exist`.
It seems that the embed.FS always uses foreward slashes, even on
Windows.
This not only affected generating the cheatsheets, but also loading a
translation file in production.
The default shortcut to open git difftool (`ctrl+t`) is not available on
the "Local Branches" window. It is available when selecting a commit
from a local branch, a remote branch, or a tag from the "Local Branches"
window.
This is inconsistent since branches or tags are also commits, the
shortcut should also work on them directly.
This commit remedies this inconsistency by allowing the use of the
shortcut directly on a branch or a tag. The shortcut works both in the
"standard" mode and the "diffing" mode.
The default shortcut to open git difftool (ctrl+t) is not available on
the "Local Branches" window. It is available when selecting a commit
from a local branch, a remote branch, or a tag from the "Local Branches"
window.
This is inconsistent since branches or tags are also commits, the
shortcut should also work on them directly.
This commit remedies this inconsistency by allowing the use of the
shortcut directly on a branch or a tag. The shortcut works both in the
"standard" mode and the "diffing" mode.
This reverts commit 3af545daf7cf6458e8efd324012047ce688f08e6, reversing
changes made to 629b7ba1b8f634c26adad43ffe44ed601d652f0c.
We changed our mind about this and want to provide different options for
achieving the same thing, but with more flexibility.
- **PR Description**
The highlight is normally turned off in HandleFocusLost, but that's not
called when using ReplaceContext (and changing this would be a lot of
work, it seems), so turn it off manually for now.
For a moment I considered whether we want to show the new inactive
highlight when switching from suggestions to the prompt (actually this
did happen on master), but I decided against it for several reasons:
- it's not quite the right concept (the suggestions view is not the
"parent" context of the prompt),
- there's no benefit from seeing one of the suggestions selected (and
the selection would change arbitrarily when changing the filter string)
- there would be visual problems when the suggestions become empty, in
which case we would still highlight the first empty row (which you can
only see if you set the gui.theme.inactiveViewSelectedLineBgColor config
to some color). Now this could be considered a bug in the focus
management of the suggestions panel, but it doesn't seem worth fixing
this; the problem goes away by turning off the highlight.
The highlight is normally turned off in HandleFocusLost, but that's not called
when using ReplaceContext (and changing this would be a lot of work, it seems),
so turn it off manually here for now.
- **PR Description**
A filtered view would show stale data when the model changes but the
view is inactive. I think this could only happen when changing some git
state outside of lazygit; for example, when creating a new branch while
the branches panel has a filter set, but doesn't have the focus. (See
the added test for an example.)
Probably not the most import feature in the world, but when resizing the
terminal window while multiple popup panels were open at the same time, we would
only resize the topmost one.
The main reason for changing this is because it makes the next commit easier to
implement.
This is how we do it for confirmation with suggestions too, so be consistent. It
will make things easier later in this branch if we only have one context per
"panel" on the stack, even if the panel consists of two views.
Concretely this means:
- only push the message context onto the stack when opening the panel (this
requires making the description view visible manually; we do the same for
suggestions)
- when switching between message and description, use ReplaceContext rather than
PushContext
We forgot to handle the "suggestions" and "commitDescription" view names.
Instead of listing all the names of views that can appear in popups though,
let's use the context kind for this, which feels more robust.
This is a change in behavior: previously, clicking outside of the search or
filter prompt would close the prompt, now it no longer does (because search has
a persistent popup kind, but it wasn't listed in the list of view names before).
We will have to do this regularly in order to upload it to Crowdin (or Weblate
or whatever translation system we are going to use).
Unlike the non-English JSON files, the en.json file is not committed to the git
repo.
We write a hacky, one-off script to do that. We need this script only once, so
we don't bother polishing it much. We'll re-purpose it later in the branch to
convert the English translation set to JSON; that is an operation that we need
to do regularly in the future.
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.
Fixes#3664
An inactive selection is one where the view is part of the context stack, but
not the active view. For example, the files view when you enter the staging
panel, or any view when you open a panel.
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.
- **PR Description**
Fix a performance regression that I introduced with v0.41: when entering
or leaving staging mode for a file, or when switching from a file that
has only unstaged changes to one that has both staged and unstaged
changes, there was a noticeable lag of about 500ms on my machine. With
the improvements in this PR we get this back down to about 20ms.
runewidth.StringWidth is an expensive call, even if the input string is pure
ASCII. Improve this by providing a wrapper that short-circuits the call to len
if the input is ASCII.
Benchmark results show that for non-ASCII strings it makes no noticable
difference, but for ASCII strings it provides a more than 200x speedup.
BenchmarkStringWidthAsciiOriginal-10 718135 1637 ns/op
BenchmarkStringWidthAsciiOptimized-10 159197538 7.545 ns/op
BenchmarkStringWidthNonAsciiOriginal-10 486290 2391 ns/op
BenchmarkStringWidthNonAsciiOptimized-10 502286 2383 ns/op
In d5b4f7bb3e and 58a83b0862 we introduced a combined mechanism for rerendering
views when either their width changes (needed for the branches view which
truncates long branch names), or the screen mode (needed for those views that
display more information in half or full screen mode, e.g. the commits view).
This was a bad idea, because it unnecessarily rerenders too many views when just
their width changes, which causes a noticable lag. This is a problem, for
example, when selecting a file in the files panel that has only unstaged
changes, and then going to one that has both staged and unstaged changes; this
splits the main view, causing the side panels to become a bit narrower, and
rerendering all those views took almost 500ms on my machine. Another similar
example is entering or leaving staging mode.
Fix this by being more specific about which views need rerendering under what
conditions; this improves the time it takes to rerender in the above scenarios
from 450-500s down to about 20ms.
This reintroduces the code that was removed in 58a83b0862, but in a slightly
different way.
The rendering of remote branches is in no way dependent on the width of the view
(or the screen mode). Unlike in the local branches view, we don't truncate long
branch names here (because there's no more information after them).
This is an error introduced in d5b4f7bb3e.
- **PR Description**
Some of our menus let you pick a value for some option (e.g. the sort
order menus for branches and commits). It's nice to see which one is the
current value when opening such a menu, so this PR implements that.
For menus that also have key bindings, the radio button goes between the
key and the label.
As an alternative, I considered selecting the current value when the
menu is opened; however, we currently have no menus where we select a
different entry than the first one, and it might be confusing for people
who are used to opening a menu and then pressing down-arrow a certain
number of times to get to a particular value.
- **Please check if the PR fulfills these requirements**
* [x] Cheatsheets are up-to-date (run `go generate ./...`)
* [x] Code has been formatted (see
[here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#code-formatting))
* [x] Tests have been added/updated (see
[here](https://github.com/jesseduffield/lazygit/blob/master/pkg/integration/README.md)
for the integration test guide)
* [ ] Text is internationalised (see
[here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#internationalisation))
* [ ] Docs have been updated if necessary
* [x] You've read through your own file changes for silly mistakes etc
For checkboxes it probably doesn't really make sense to use them yet, because
we'd have to find a way how you can toggle them without closing the dialog; but
we already provide rendering for them to lay the ground.
But radio buttons can be used already, because for those it is ok to close the
dialog when choosing a different option (as long as there is only one grounp of
radio buttons in the panel, that is).
Always show the "Discard unchanged changes" menu item in the Discard
menu, just strike it through if not applicable. This will hopefully help
with confusion about the meaning of "all" in the "Discard all changes"
entry; some people misunderstand this to mean all changes in the working
copy. Seeing the "Discard unstaged changes" item next to it hopefully
makes it clearer that "all" is meant in contrast to that.
Strike it through if not applicable. This will hopefully help with confusion
about the meaning of "all" in the "Discard all changes" entry; some people
misunderstand this to mean all changes in the working copy. Seeing the "Discard
unstaged changes" item next to it hopefully makes it clearer that "all" is meant
in contrast to that.
