T O P I C R E V I E W |
kcbanner |
Posted - Oct 28 2024 : 3:29:39 PM I am a user of VsVim, and I have defined the following commands in my .vsvimrc:
nnoremap gd :vsc VAssistX.GotoImplementation<CR> nnoremap gi :vsc VAssistX.GotoImplementation<CR> vnoremap gd :vsc VAssistX.GotoImplementation<CR> vnoremap gi :vsc VAssistX.GotoImplementation<CR>
This works well, and allows navigation with standard vim bindings. However, upon navigating to the symbol, it it selected. Selections like this cause VsVim to enter Visual mode (which is Vim's mode for selection editing) which requires an extra keystroke to leave. This means whenever I navigate somewhere using these bindings I need to hit Esc to enter Normal mode and resume navigating around the file.
My request is for an option to not select the symbol upon navigating to it via VAssistX commands.
Thanks!
|
13 L A T E S T R E P L I E S (Newest First) |
feline |
Posted - Nov 13 2024 : 06:57:19 AM One of my ideas was to try a swap file command, followed by a swap back again, on the theory that VsVim would know to wait for the swap file command to finish before moving forward. But the next buffer command didn't work, and relying on Alt-O or a similar command starts to make assumptions I don't want to rely on in a keyboard mapped macro.
It does feel like there should be a solution here, but I am not sure where to look for it. |
kcbanner |
Posted - Nov 12 2024 : 1:20:58 PM Thanks!
Yes, it's possible that a sleep command could be useful here (or perhaps, run some command after all current queued commands). |
feline |
Posted - Nov 12 2024 : 12:58:31 PM I am just going round and round in circles here. I have put in a feature request for VA not to select the text, to see how easy it would be:
case=165165
although I do have a concern that there might be edge cases where text is still selected.
I still suspect we would have more luck if the sleep command was implemented in VsVim, so we could add a delay before trying to clear the selected text. Perhaps worth asking if that could be added to VsVim? |
feline |
Posted - Nov 12 2024 : 12:13:39 PM I do still sometimes miss the powerful movement commands in Vim. I remember bouncing around a file with great speed back in the day
Lets see if I can get anywhere with this...
As for VA, since we have to handle multiple IDE's, sometimes things aren't as "just done once" as we would like. Things have to be done rather differently in VS2010 than VS2022, and that's before you get into the fact that VS2022 is 64bit and VS2019 is 32bit. So if I can find a solution that doesn't require a code change in VA, this would be faster and easier. And I was so pleased when that worked in my simple tests to! |
kcbanner |
Posted - Nov 12 2024 : 11:54:48 AM Interesting idea, this does seem to work for navigations within the same file - but if the navigation takes me to another file then the selection persists.
Yes, move by subword is quite useful (bound to `b` in vim, `e` moves forward) for moving quickly on a line.
|
feline |
Posted - Nov 11 2024 : 10:34:44 AM I was thinking about this, and wondered if getting another movement command in, before trying the escape would help. The hope being that movement would disrupt the selection. Can you please try the following mapping:
nnoremap gd :vsc VAssistX.GotoImplementation<CR>:vsc Edit.PreviousSubword<ESC>
I have only tried a couple of simple tests so far, since VsVim is still making my head hurt, but this is working for me. I can do Vim, and I can do Visual Studio, just not together
For me, the interesting part of this is discovering the move by previous subword command, which I can see being rather useful once I get used to it. Just surprised I didn't already know about it. Always something new to learn |
kcbanner |
Posted - Nov 08 2024 : 10:57:38 AM Thanks for the reply! Delay is an interesting idea, unfortunately not implemented like you say - however even if that did work - at this point hitting ESC (which I've mapped caps lock to) is part of my muscle memory that I hit automatically after any VA command - so I think that probably happens faster than any delay even if it did solve it :D
When I made this ticket I had assumed that VA had some internal common flow for navigating to a symbol / location, and somewhere in that flow would be a call to the MSVC API to select the text - my assumption was this feature request could be implemented by wrapping that common selection logic in a conditional that checked the state of this new preference. It sounds like this isn't the case?
Cheers! |
feline |
Posted - Nov 08 2024 : 06:56:01 AM Apologies for the delay. I have had another look at this. A quick search got me to the page:
https://vi.stackexchange.com/questions/5649/can-i-add-a-delay-wait-to-a-key-mapping
which sounds like it would help, except that VsVim is returning a parse error on the sleep command, suggesting it hasn't been implemented yet.
Approaching from a different point of view, why are you trying to remap Alt-G like this?
Regardless of the why though, the problems are broader than just Alt-G though. Use Alt-M, and when you jump to a method in the file, the method name is selected, dropping you into Visual mode. I am reluctant to start looking for every way VA can / does select text, since this does not sound like a helpful approach here. |
feline |
Posted - Nov 01 2024 : 07:58:55 AM I will have to have a prod of this. But the movement going to the wrong buffer suggests that the macro is being run "instantly", and not waiting for one command to finish before triggering the next command. That seems like it will be a standard problem that has a fix, since surely VsVim cannot expect all IDE commands to return "instantly" without having an effect on the buffer? |
kcbanner |
Posted - Oct 31 2024 : 5:30:06 PM Good ideas!
Indeed, I had enabled "Prefer implemention on Goto" to avoid the menu.
I tried the left cursor idea, but it ends up moving the cursor left in the buffer that the action was executed in, not the destination.
Additionally, I tried:
nnoremap gd :vsc VAssistX.GotoImplementation<CR>:vsc Edit.SelectNone<CR>
thinking that the commands would execute sequentially, but this didn't work either.
|
feline |
Posted - Oct 31 2024 : 08:29:59 AM Can you try sending a move left one space instead of Escape? If you use the left cursor key after Alt-G then you end up with the keyboard caret at the start of the symbol you jumped to, with nothing selected. So it should have the same general result as an escape, but perhaps it will be more effective?
Is there a delay command? I am wondering if you need to add a slight delay, to make sure that VA has finished the Alt-G command, before VsVim picks up again.
If we can easily get this working it will be a lot faster than waiting for a code change in VA. Plus, from going looking, this behaviour in VA was done deliberately to match what the IDE its self does when jumping to commands, so a solution might be more widely helpful.
On this front, how are you handling cases where Alt-G shows you a menu? Or did you turn On
VA Options -> Goto -> Prefer implementation on Goto
to avoid running into a menu? |
kcbanner |
Posted - Oct 30 2024 : 12:40:02 PM Actually that was also my first though, and I did attempt to expand the macro I'm using above by adding an <ESC> to the sequence (to exit visual mode after the togo). However, this didn't work as I believe there is something async happening with either the goto call itself, or the way that VsVim calls commands via :vsc.
There was a brief discussion here about it https://github.com/VsVim/VsVim/issues/891#issuecomment-2442397296
Once I determined that I couldn't solve it via extending the binding with <ESC>, then I thought perhaps an options to disable the automatic selection would be a good workaround. |
feline |
Posted - Oct 29 2024 : 07:50:20 AM I haven't used Vim in years, and never did wrap my head around using VsVim, since to me Visual Studio and Vim just work in very different ways
I can sort of read this... is this moving into Vim macro territory? Assuming the <CR> at the end of each line is part of the command you are sending, can't you just add an escape at this point? I seem to recall that Vim macros got rather powerful, since you could just chain together the commands you wanted running as a single block. Or am I thinking of something quite different? |