[Question] passing <alt> to system?

[gilbh]

Hi

I am trying the following so vind will automatically switch to INSERT when I click :

ennoremap <alt> to_insert

This is helpful when I switch to other apps. Problem is that the first is caught by vind and is not passed to Windows. Any way of getting over this? (i.e., to pass the first to Windows so that my first press of will both switch vind to INSERT and also have Windows switch apps?)

[pit-ray]

You can call switch_window after to_insert using the latest macro features like the following.

inoremap <f15> switch_window
ennoremap <ctrl-t> i<f15>

However, there seems to be a bug that triggering with <alt> interferes with <alt-tab> and doesn't work, so please try using something other than <alt> or <Tab>, such as <ctrl-t>.

Thanks.

[gilbh]

I see.

What I was trying to get is a seamless/automatic transition from EDIT NORMAL to INSERT exactly when I press <alt-tab> so behavior will be as close as possible to "usual" Windows .... I understand there is a bug with <alt>, but I tried <ctrl-tab> and it also behaves strange (the window selector insists on jumping to the first window and stays there ...). This leads me to think the problem is with <tab> and not with <alt>. What do you think?

Also, the above issue also opened a new problem: it seems that switch_window automatically goes into RESIDENT if it recognizes that the focused app is vim-based (I actually use neo-vim). Is that behavior deliberate? It totally fine if yes. I like RESIDENT on my neo-vim and could work with this scenario, only that when I try to switch from RESIDENT to INSERT (using <esc-up>) something weird happens: vind switches to INSERT but then goes on and immediately switches automatically to EDIT NORMAL ... This is probably the result of my other mappings:

inoremap <esc> to_edi_normal

-- I assume the <esc> key is still activated after RESIDENT switches to INSERT and that is why it also implements to_edi_normal. Any solution to this?

Thanks!

[pit-ray]

Did the <ctrl-t> that I introduced work as well as you wanted it to?

The conflict problem is in both <alt> and <tab>, because the trigger keys and the internal call to <alt-tab> are in conflict. And then, it is an undeniable bug that the suppress_for_vim option is working even in switch_window. I will fix them in the next minor change.

And. the fact that keys pressed with RESIDENT are still valid after processing is a specification. To solve it, change the mapping from RESIDENT to INSERT.

runmap <esc-up>.
rnoremap <ctrl-alt-up> to_insert

Maybe we need to implement a special mapping to pass key messages by doing something like enmap <alt> <alt>.

Thanks.

[gilbh]

Thanks.

I just now tried switching windows using <ctrl-t> and the result it the same: the window panel appears, but the selection jumps to the first window and stays there, and <tab> does not response (only arrow keys). To conclude the problem: all the mappings that we tried for switch_window, which are <alt-tab> <ctrl-tab> and <ctrl-t>, behave the same, and in a faulty way.

I don't think that having suppress_for_vim activated for switch_window is a bug. It is a logical behavior and actually very useful, because RESIDENT is better than INSERT when working in vim. So this is fine to me.

Your solution for different mapping from RESIDENT to INSERT works well. However, I wish there was a better solution for keeping the <esc-up> like in other modes. But this is really a very minor thing. Also, I am not sure anymore if it is needed. I understand better RESIDENT now and see its usefulness, so RESIDENT to INSERT is not such an important action (at least as I see this now).

[gilbh]

Here' s though I just have:

suppress_for_vim is working great right now in choosing RESIDENT over INSERT if in vim app. However, it should also do the opposite command if the switch is made to non-vim app.

Right now, when vind choose RESIDENT over INSERT because I just entered vim, it will stick to RESIDENT even if I switch to other programs.

It should make this decision every time switch_window occurs. It might seems counter intuitive at first (why would suppress_for_vim switch change behavior for non-vim apps?) but it is actually the complete behavior that is required.

What do you think?

[pit-ray]

I just now tried switching windows using and the result it the same: the window panel appears, but the selection jumps to the first window and stays there, and does not response (only arrow keys).

The operation of switch_window is the same as the mapping of h and l in EditorNormal, i.e. move_caret_left, move_caret_right. Therefore, you can use it in <tab> by writing the following.

ennoremap <tab> move_caret_right
ennoremap <shift-tab> move_caret_left

I don't think that having suppress_for_vim activated for switch_window is a bug. It is a logical behavior and actually very useful, because RESIDENT is better than INSERT when working in vim. So this is fine to me.

If supress_for_vim is working while the selection, even though it is not decided by <enter> in switch_window, it maybe a bug. Not if it switches after <enter>, it is normal.

However, it should also do the opposite command if the switch is made to non-vim app.

I will consider it positively.

Thanks.

[gilbh]

Thanks!

[pit-ray]

I make it open for the milestone.

[gilbh]

A small addition to the issue of switch_window: I added the mapping you suggested--

ennoremap <tab> move_caret_right
ennoremap <shift-tab> move_caret_left

-- and it works great from NORMAL: I can now seamlessly switch between applications with <tab> and <shift-tab>. However, when I release the <alt> key (key-up) the selected app is not activated. I am still required to press <enter>.

I am not sure if you can so anything at that point, to make the switch behave like it should (without having to click another <center>) ... if you can, it would be great.

[petertheprocess]

Maybe we need to implement a special mapping to pass key messages by doing something like enmap .

Hi, are there any plans to add similar functions? I wanna add some shotkeys, which should be passed to the system too.

[pit-ray]

@gilbh It is an assumed specification that switch_windows is determined by Esc or Enter. https://github.com/pit-ray/win-vind/blob/443abf8be0e892de2d92fc268e84de9d3cb2eacd/src/bind/window/switch_win.cpp#L110-L115

[pit-ray]

@petertheprocess Adding shortcut keys is possible by creating a macro using map. ref. https://pit-ray.github.io/win-vind/usage/#3-customize-win-vind

For example, the following generates <ctrl-s> with f in Insert mode.

imap f <ctrl-s>

Thanks.

[petertheprocess]

@pit-ray Hi, thanks for your reply!

My translate software's hotkey is <alt-l>, which can translate the text in the clipboard. And I wanna use it in the edit nomal mode, by enter ev model, select the text and then type y to copy the text, then type a key like t to pass the <alt-l> to my translate app. I have tried these mapping, but neither works. I think it is because that win-vind has blocked the cmd to my system. gnoremap t <alt-l> gnoremap t <Esc-down><alt-l>

[pit-ray]

@petertheprocess win-vind uses map as the mapping to pass to the system and noremap as the internal mapping. Therefore, please try gnmap.

[petertheprocess]

@pit-ray get it, now it works. Thanks!

[pit-ray]

The problem regarding suppress_for_vim and alt problem has been solved.