| Age | Commit message (Collapse) | Author |
|---|
|
We've been sometimes using lo and sometimes using my slices package, and we need to pick one
for consistency. Lo is more extensive and better maintained so we're going with that.
My slices package was a superset of go's own slices package so in some places I've just used
the official one (the methods were just wrappers anyway).
I've also moved the remaining methods into the utils package.
|
|
|
|
We have a use-case to rebind 'm' to the merge action in the branches panel. There's three ways to handle this:
1) For all global keybindings, define a per-panel key that invokes it
2) Give a name to all controller actions and allow them to be invoked in custom commands
3) Allow checking for merge conflicts after running a custom command so that users can add their own 'git merge' custom command
that matches the in-built action
Option 1 is hairy, Option 2 though good for users introduces new backwards compatibility issues that I don't want to do
right now, and option 3 is trivially easy to implement so that's what I'm doing.
I've put this under an 'after' key so that we can add more things later. I'm imagining other things like being able to
move the cursor to a newly added item etc.
I considered always running this hook by default but I'd rather not: it's matching on the output text and I'd rather something
like that be explicitly opted-into to avoid cases where we erroneously believe that there are conflicts.
|
|
By using an interface for tasks we can use a fake implementation in tests with extra methods
|
|
The global counter approach is easy to understand but it's brittle and depends on implicit behaviour that is not very discoverable.
With a global counter, if any goroutine accidentally decrements the counter twice, we'll think lazygit is idle when it's actually busy.
Likewise if a goroutine accidentally increments the counter twice we'll think lazygit is busy when it's actually idle.
With the new approach we have a map of tasks where each task can either be busy or not. We create a new task and add it to the map
when we spawn a worker goroutine (among other things) and we remove it once the task is done.
The task can also be paused and continued for situations where we switch back and forth between running a program and asking for user
input.
In order for this to work with `git push` (and other commands that require credentials) we need to obtain the task from gocui when
we create the worker goroutine, and then pass it along to the commands package to pause/continue the task as required. This is
MUCH more discoverable than the old approach which just decremented and incremented the global counter from within the commands package,
but it's at the cost of expanding some function signatures (arguably a good thing).
Likewise, whenever you want to call WithWaitingStatus or WithLoaderPanel the callback will now have access to the task for pausing/
continuing. We only need to actually make use of this functionality in a couple of places so it's a high price to pay, but I don't
know if I want to introduce a WithWaitingStatusTask and WithLoaderPanelTask function (open to suggestions).
|
|
|
|
The menuFromCommand option is a little complicated, so I'm adding an easy way to just use the command output directly,
where each line becomes a suggestion, as-is.
Now that we support suggestions in the input prompt, there's less of a need for menuFromCommand, but it probably still
serves some purpose.
In future I want to support this filter/valueFormat/labelFormat thing for suggestions too. I would like to think a little more
about the interface though: is using a regex like we currently do really the simplest approach?
|
|
This changes the interface a bit but it was only added earlier today so I doubt anybody is dependent on it yet.
I'm also updating the docs.
|
|
|
|
We have not been good at consistent casing so far. Now we use 'Sentence case' everywhere. EVERYWHERE.
Also Removing 'Lc' prefix from i18n field names: the 'Lc' stood for lowercase but now that everything
is in 'Sentence case' there's no need for the distinction.
I've got a couple lower case things I've kept: namely, things that show up in parentheses.
|
|
|
|
|
|
|
|
In case a later command depends on a prompt input from a previous one we
need to evaluate it only after the previous prompt has been confirmed.
|
|
functions
|
|
|
|
Add Form field to CustomCommandObjects struct
Write user prompts responses to Form field
Ensure that map keys exists
Add form prompts integration test
Remove redundant index
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Supports configuring a custom confirmation prompt via `config.yml` for
custom keybindings. A new `CustomCommandPrompt.Body` field is
used to store the immutable body text of the confirmation popup.
- Adds a sample 'confirm' prompt to the example `config.yml`.
- Updates the `Prompts` section of the documentation to include
'confirm' prompt type and also describe which fields pertain to it
(i.e. `initialValue`).
Closes: https://github.com/jesseduffield/lazygit/issues/1858
Signed-off-by: Michael Mead <mmead.developer@gmail.com>
|
|
|
|
|
|
|
|
|
|
more custom command refactoring
|
