-
Notifications
You must be signed in to change notification settings - Fork 167
configurable keymaps #136
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
configurable keymaps #136
Conversation
@kujtimiihoxha I just ran the test suite locally and realised this has broken a test or two - will fix these up and ping you when the PR is actually ready for review, but will do this tomorrow! |
@jesses-code-adventures What i have to actually change in this? or will you help me by this ? |
@jesses-code-adventures might be that the tests that are failing are not related to your PR just so you know, I have not really done a good job maintaining the tests. @ritikpal1122 I think you can close your old PR for now seems like this implements the necessary keymaps using the current config, thanks a lot for the effort you have put into this feature. |
Ok nice one @kujtimiihoxha, I'll have a quick look today and see if it's anything my PR touches and let you know |
Hey @kujtimiihoxha, the failing test is in t.Run("handles empty path parameter", func(t *testing.T) {
// For this test, we need to mock the config.WorkingDirectory function
// Since we can't easily do that, we'll just check that the response doesn't contain an error message
tool := NewLsTool()
params := LSParams{
Path: "",
}
paramsJSON, err := json.Marshal(params)
require.NoError(t, err)
call := ToolCall{
Name: LSToolName,
Input: string(paramsJSON),
}
response, err := tool.Run(context.Background(), call)
require.NoError(t, err)
// The response should either contain a valid directory listing or an error
// We'll just check that it's not empty
assert.NotEmpty(t, response.Content)
}) Let me know your preference, happy to try get the test working, remove it, or just leave as-is. Cheers! |
Maybe unrelated, but I also noticed when testing on a new machine that on both Would you like me to add the creation of a default config file if the user doesn't have one, or is this by design? Happy to add that in this PR or a separate one if desired. |
Ok @kujtimiihoxha will revert or cancel my PR but i want to contribute in more with @jesses-code-adventures Let ME know if i can join you |
This is probably a bug, we should not require that. |
@jesses-code-adventures I think for now just remove the failing tests, I will need to do real testing of everything soon. |
no worries @kujtimiihoxha, have removed them now |
@jesses-code-adventures looks like this needs a rebase, and there is a new global keymap |
4d46a00
to
d8ebc74
Compare
d8ebc74
to
fbe3fda
Compare
@kujtimiihoxha no worries, changes have been applied |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small suggestion and I think this needs a rebase again.
"keymap_display": "ctrl+w/e", | ||
"command_display": "look at my logs" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"keymap_display": "ctrl+w/e", | |
"command_display": "look at my logs" | |
"help_key": "ctrl+w/e", | |
"help_description": "look at my logs" |
I believe using help_*
is a bit more descriptive here?
Configurable Keymaps
This PR allows users to configure keymaps in the
.opencode.json
file withthe following layout:
Although the configuration's a little verbose, it does allow users to
customize to their heart's content - happy to get rid of the display
configuration if it's unnecessary though.
I have ensured the same keys are displayed in the help window, but the
undisplayed keys are also configurable.
This PR was started after looking through @ritikpal1122 s work in #112, so
thanks to Ritik for getting started on this one.