-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
debug: configurable key mappings #3035
Conversation
autoload/go/debug.vim
Outdated
\["nmap", "<F5>", "<Plug>(go-debug-continue)"], | ||
\["nmap", "<F6>", "<Plug>(go-debug-print)"], | ||
\["nmap", "<F9>", "<Plug>(go-debug-breakpoint)"], | ||
\["nmap", "<F10>", "<Plug>(go-debug-next)"], | ||
\["nmap", "<F11>", "<Plug>(go-debug-step)"], |
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.
This slightly differs from the default. I tested it with <buffer>
but when I step into some file the buffer changes and the mappings are no longer active, thus I decided to leave it without the buffer attribute
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.
Ideally, IMO, the behavior should be that these mappings will be active only in a certain tab or split. E.g. I have the n key mapped to step over in debug mode and I usually have the n key mapped to next search result, I would like the semantics of n in other tabs to be those from my normal config, so I could search for things.
Unfortunately I don't see a way of doing this. WDYT?
The CI fails with:
At a first glance this doesn't seem related to the changes in the PR EDIT: Is there a way to restart the CI? It passed the first time. |
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.
Making the mappings local to the buffer is critical.
Thanks for contributing @kernel-panic96 🙇
Can you put the debug_mode.vim contents into debug.vim
and make the public functions script-scoped functions instead?
Please don't change the location of where the mappings are applied and cleared; debugging is surprisingly finicky, and the placement of those operations has been a deliberate choice to make sure that mappings are available at the right times in the debugging lifecycle. I suspect this means that the mappings list will need converted to a dictionary where each operations' name is used as a key (e.g. {'go-debug-continue': ["nmap", "<F5>"]}
, though I think that the value may be able to just be the keybindings; I can't think of a reason to use anything other than nmap).
The problems that you had with using buffer-local mappings is because the doautocmd
is no longer applied. If you'll make the changes I requested in the previous paragraph, we should be able to make the changes buffer-local when the user's preferred keys are processed.
Also, please do not remove the autogroup. Instead, leverage it as it was leveraged before, just with with customizations.
Please use execute()
instead of :execute
in VimL.
If you'd prefer to be done with this PR, I can take over and make the changes I've requested.
autoload/go/debug_mode.vim
Outdated
function! go#debug_mode#Restore(...) abort | ||
for [lhs, save] in items(s:mappings_save) | ||
let command = s:restore_mapping(lhs, save) | ||
silent! execute command |
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.
use execute()
here instead of normal mode commands.
Those failures seem unrelated to your changes so far. That failing test has been flaky recently. I thought I'd resolved it in a recent PR, though; perhaps you're work is based on an older commit? If so, that's ok, there's no need to rebase or merge master into your branch. |
I'm fine with you finishing it up. I tried and ran into some race conditions where the backing of user mappings happens twice and when you try to restore them they get restored to the debugger mappings which is not what you would want. Currently the code is structured with the assumption that the setup & teardown would be executed only once. Making |
Ok, I'll take over from here and make some changes. Are you ok if I push to your branch? |
Yes. |
I'm willing to give it another try. Do you have unpushed code? |
I just finished up the major refactor last night. I need to do some testing locally, and then I'll push changes; I'll likely do that today or tomorrow. Thank you for offering to test; that will be very helpful. |
@kernel-panic96 I've created a pull request against your branch. Please don't merge it to your branch regardless of your testing results. After you test, I can push directly to your branch instead and then merge this if your testing is successful. |
@kernel-panic96 I'm going to rebase this onto master to resolve conflicts and push to your branch before I merge. |
Move the modeline to the end of the file and add expandtab. Add the usual header for vim-go.
Update docs for g:go_debug_mappings to reflect the desired state.
Refactor debug mapping to be normal mode buffer-local mappings only. Restore mappings in go#debug#Stop instead of s:stop() for consistency of purpose.
Fix unmapping of a long-standing unreported bug where the debugging mappings were not being unmapped when debugging stops.
Move debug mapping functions into debug.vim and change their names appropriately. No functional changes were made.
Remove <Plug> mapping on stop. This was mistakenly removed in a recent comment that changed the code that removes mapping so that only the key mappings were removed. Add a test to ensure <Plug> mappings are removed. It turns out that the previous commit should have added the removal of key mappings and kept the removal of the <Plug> mappings. This also fixes a bug with the previous implementation of removal of <Plug> mappings to ensure that the first <Plug> mapping is also removed.
Copy g:go_debug_mappings before extending it so that the extension merge with the user's value.
Do not reset s:mappings on each call to s:configureMappings so that opening a new file doesn't reset the value.
The FileType events are not buffer-local events, so in order to reset them, the autocmd! command must not be restricted to buffer-local events.
Set the arguments before lhs.
Thank you @kernel-panic96 ! |
Thank you for the collaboration @bhcleek . It was awesome 👍 . |
Closes #3012 #1788