In ff4ae4a544 we changed the order of the calls to render before
selecting the branch. This was done only to save an extra call to
ReApplyFilter, which is done by refreshView; I claimed that the order of
refreshView vs. SetSelectedLineIdx doesn't matter here. I guess I was
wrong about that, it makes the integration test
custom_commands/suggestions_preset.go flaky. To fix this, put the
refreshView call back to where it was (after the SetSelectedLineIdx
call), and instead insert an extra call to ReApplyFilter where necessary
to fix the bug that ff4ae4a544 was trying to fix.
I still don't think there was any user facing problem caused by this
(@ChrisMcD1 correct me if I'm wrong), so I don't think we need to cut a
0.46.1 release with the fix (otherwise it would have been a regression
in 0.46), and I only label it as `maintenance` because it only fixes CI.
Fixes#4267.
In ff4ae4a544 we changed the order of the calls to render before selecting the
branch. This was done only to save an extra call to ReApplyFilter, which is done
by refreshView; I claimed that the order of refreshView vs. SetSelectedLineIdx
doesn't matter here. I guess I was wrong about that, it makes the integration
test custom_commands/suggestions_preset.go flaky. To fix this, put the
refreshView call back to where it was (after the SetSelectedLineIdx call), and
instead insert an extra call to ReApplyFilter where necessary to fix the bug
that ff4ae4a544 was trying to fix.
- **PR Description**
This improves the user experience when users try to use an invalid key
name in their config, either for one of our standard keybindings or for
the key of a custom command.
Fixes half of #4256 (only the keybindings aspect of it, not the context
names).
- **PR Description**
This adds a config `gui.tabWidth` that can be used to change the tab
width from the default of 4 to a different number. It affects everything
that's shown in the main view, but is probably mostly relevant for
diffs.
When using a pager, the pager needs to be configured separately for the
same tab width.
This may often be different for different repos, so it may make sense to
put it in a repo-local config file.
In some cases this may still not be flexible enough, e.g. in
multi-language projects that use different tab widths for the different
file types; but it's better than before and was easy to do...
Addresses #4290.
- **PR Description**
Add a "Copy to clipboard" menu to the Commit Files panel
This is very similar to the same menu in the Files panel, except that it
works on whatever diff is currently shown in the main view, including
range diffs either in diffing mode (shift-W), or from a range selection
of commits.
The menu has some code duplication with the existing menu in the Files
panel, but actually not so much. The first two menu items could be
unified once we have generalized the filetrees, but these are pretty
trivial; the other two menu items are sufficiently different that
unifying them is not practical, I think.
Fixes#4254.
This is very similar to the same menu in the Files panel, except that it works
on whatever diff is currently shown in the main view, including range diffs
either in diffing mode (shift-W), or from a range selection of commits.
Change our fake clipboard command to not append a linefeed; that's closer to
what the production code does.
This allows us to use Equals instead of Contains for checking the clipboard
contents.
Finally, use FileSystem().FileContent() to assert the clipboard contents,
instead of selecting the clipboard file and then checking the diff view.
Github actions refuses to trigger a workflow from another workflow, but
if you use your own personal access token (in this case,
GITHUB_API_TOKEN), it should work.
This may lead to unrelated processes being killed on Windows (https://github.com/jesseduffield/lazygit/issues/3008). Imagine:
1. lazygit is started and runs git diff in process X which completes immediately and exits.
2. lazygit is left in the background for several hours by which process X pid is reused by an unrelated process.
3. lazygit is focused back on and runs another git diff. It first runs this stop logic which will kill process X and its children.
- **PR Description**
Fix ugly error squiggles in VS Code when using a custom command with a
context of e.g. "commits, subCommits".
Previously the schema only allowed a single value for the context field;
however, it is now possible to specify multiple values separated by
comma (see #3784).
The only solution that I can see is to get rid of the "enum"
specification, and mention the valid values only in the description. Add
examples too so that you get at least auto-completion.
Previously the schema only allowed a single value; however, it is now possible
to specify multiple values separated by comma, and you would get very ugly red
error squiggles in VS Code when you did that.
The only solution that I can see is to get rid of the "enum" specification, and
mention the valid values only in the description. Add examples too so that you
get at least auto-completion.
- **PR Description**
When pasting a multi-line commit message into the subject field of the
commit editor, we would interpret the first newline as the confirmation
for closing the editor, and then all remaining characters as whatever
command they are bound to, resulting in executing all sorts of arbitrary
commands.
Now we recognize this being a paste, and interpret the first newline as
moving to the description.
Also, prevent tabs in the pasted content from switching to the
respective other panel; simply insert four spaces instead, which should
be good enough for the leading indentation in pasted code snippets, for
example.
Finally, disable pasting text into non-editable views; my assumption is
that this is always a mistake, as it would execute arbitrary commands
depending on what's in the clipboard.
This depends on the terminal emulator supporting bracketed paste; I
didn't find one on Mac that doesn't (I tested with Terminal.app, iTerm2,
Ghostty, kitty, Alacritty, WezTerm, and VSCode's builtin terminal. It
works well in all of them).
I couldn't get it to work in Windows Terminal though, and I don't
understand why, as it does seem to support bracketed paste (it works in
bash).
Fixes#3151Fixes#4066Fixes#4216
When pasting a multi-line commit message into the subject field of the commit
editor, we would interpret the first newline as the confirmation for closing the
editor, and then all remaining characters as whatever command they are bound to,
resulting in executing all sorts of arbitrary commands.
Now we recognize this being a paste, and interpret the first newline as moving
to the description.
Also, prevent tabs in the pasted content from switching to the respective other
panel; simply insert four spaces instead, which should be good enough for the
leading indentation in pasted code snippets, for example.
