feat(custom command): support multiple contexts within one command

[yam-liu]

• PR Description

For some custom commands, they can be used in multiple contexts. But for now, if we want to do this, we should copy and paste the same config times and times with just a different context.

Related issue: #3759

This PR changes the context of customCommand to contexts.

There are at least 3 solutions for this:
1: make a breaking change to context completely.
2: keep the context and add a new contexts key, only one of them can be configured at the same command. contexts has a higher priority if both are present.
3: keep the context key but support both string and array types.

The current implementation is 1. Maybe 3 is better? Any advice is appreciated.

• Please check if the PR fulfills these requirements

• Cheatsheets are up-to-date (run go generate ./...)
• Code has been formatted (see here)
• Tests have been added/updated (see here for the integration test guide)
• Text is internationalised (see here)
• Docs have been updated if necessary
• You've read through your own file changes for silly mistakes etc

[stefanhaller]

Nice, thanks for working on this.

A fourth solution could be to keep the config as a string, and simply support a comma-separated list of contexts, e.g.

  - key: X
    context: commits,branches

I think I would be in favor of this, I find this pretty intuitive, it's simple to implement, and it's not a breaking change.

[yam-liu]

@stefanhaller Great advice, I have done the modification. Docs will be updated later.

[stefanhaller]

Great work, we're almost there. There's one bug and a minor style thing, see below.

Apart from that, it would be great if we could add an integration test for the case where there's more than one context (in addition to a test for "global" as suggested below). It should be easy to do given the existing examples that we already have.

[stefanhaller]

This is a bug, it breaks custom commands for the "global" context. You need to change this to return []string{""} to fix that.

Unfortunately we don't have a test that catches this; it would be great to add one. We have several existing tests for custom commands, you could pick one of those as an example to follow, e.g. pkg/integration/tests/custom_commands/show_output_in_panel.go.

[stefanhaller]

Matter of taste, probably, but I'd write this block as

	return lo.Map(viewNames, func(viewName string, _ int) *types.Binding {
		return &types.Binding{
			ViewName:    viewName,
			Key:         keybindings.GetKey(customCommand.Key),
			Modifier:    gocui.ModNone,
			Handler:     handler,
			Description: description,
		}
	}), nil

[stefanhaller]

Very nice, good work on the tests. Just one small suggestion for one of the tests below.

Now the only complaint I have left is the commit history. My suggestion for structuring the commits would be:

• a commit that adds the test for the global context
• all the other changes (the implementation, the other test, and the docs) as a single, second commit.

Also, I find your use of "feat" in the commit messages questionable. I'm not a fan of conventional commits myself, I'd rather omit that entirely, but if you do want to use it, please do it consistently. A commit that adds a test shouldn't be labelled with "feat".

[yam-liu]

@stefanhaller Done, I followed the commit message convention/style of this repo.

[stefanhaller]

Nice, thanks. I took the liberty of making the remaining commit history changes that I suggested myself.

[stefanhaller]

I would drop these two lines; they are unnecessary because no file was actually created in this case.

[stefanhaller]

I'd squash this change into the commit that implements the feature.