Skip to content
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

FAR Manager is not receiving Alt+F1 #1510

Closed
nico-abram opened this issue Jan 6, 2022 · 6 comments
Closed

FAR Manager is not receiving Alt+F1 #1510

nico-abram opened this issue Jan 6, 2022 · 6 comments
Labels
bug Something isn't working fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds. keyboard Keyboard mapping/handling

Comments

@nico-abram
Copy link
Contributor

What Operating System(s) are you seeing this problem on?

Windows

WezTerm version

wezterm 20220105-201141-1131f2dc

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

Running FAR Manager on windows under wezterm, it does not do anything when I press Alt+F1

To Reproduce

  1. Download FAR Manager from https://www.farmanager.com/download.php?l=en
  2. Run far inside wezterm
  3. Press Alt+F1 (You may have to disable the alt+f1 hotkey in wezterm, for example with disable_default_key_bindings = true)
  4. Nothing happens

Configuration

I am using disable_default_key_bindings = true to disable alt+F1 in wezterm

Expected Behavior

A "Change drive" box should open in FAR when pressing alt+F1 on the left half of the console like this (In cmd. Also works in Windows Terminal Preview)
imagen

Logs

Using debug_key_events = true:

 2022-01-06T07:48:33.909Z INFO  wezterm_gui::termwindow::keyevent > key_event KeyEvent { key: Function(1), modifiers: ALT, repeat_count: 1, key_is_down: true }
 2022-01-06T07:48:33.909Z INFO  wezterm_gui::termwindow::keyevent > send to pane key=Function(1) mods=ALT
 2022-01-06T07:48:34.088Z INFO  wezterm_gui::termwindow::keyevent > key_event RawKeyEvent { key: Physical(F1), modifiers: ALT, phys_code: Some(F1), raw_code: 112, repeat_count: 1, key_is_down: true, handled: Handled(false) }
 2022-01-06T07:48:34.089Z INFO  wezterm_gui::termwindow::keyevent > key_event KeyEvent { key: Function(1), modifiers: ALT, repeat_count: 1, key_is_down: true }
 2022-01-06T07:48:34.089Z INFO  wezterm_gui::termwindow::keyevent > send to pane key=Function(1) mods=ALT
 2022-01-06T07:48:34.266Z INFO  wezterm_gui::termwindow::keyevent > key_event RawKeyEvent { key: Physical(F1), modifiers: ALT, phys_code: Some(F1), raw_code: 112, repeat_count: 1, key_is_down: true, handled: Handled(false) }
 2022-01-06T07:48:34.266Z INFO  wezterm_gui::termwindow::keyevent > key_event KeyEvent { key: Function(1), modifiers: ALT, repeat_count: 1, key_is_down: true }
 2022-01-06T07:48:34.266Z INFO  wezterm_gui::termwindow::keyevent > send to pane key=Function(1) mods=ALT

Anything else?

I think it is possible this is related to #1509

@nico-abram nico-abram added the bug Something isn't working label Jan 6, 2022
@wez wez added the keyboard Keyboard mapping/handling label Jan 6, 2022
wez added a commit that referenced this issue Jan 6, 2022
This commit causes the terminal to emit win32-input-mode encoded key up
and down events for a limited subset of keys When win32-input-mode is
enabled.

We limit them to keys where we know the VK key code equivalent,
and where those keys are either not representable (eg: modifier
only key events), or may generate ambiguous output (eg: CTRL-SPACE
in different keyboard layouts).

However, in my experiments, modifier only key presses confuse powershell
and cause it to emit `@`, so I've disabled that in the code for now.

refs: #318
refs: #1509
refs: #1510
wez added a commit that referenced this issue Jan 6, 2022
Normalize the left/right to the main VK.

Fixup the left/right control modifier flags: they were flipped!

refs: #318
refs: #1509
refs: #1510
@wez wez added the fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds. label Jan 6, 2022
@wez
Copy link
Owner

wez commented Jan 6, 2022

I didn't install far manager, but I verified that in powershell I can see alt and alt-f1 events:

; while (1) { echo $Host.UI.RawUI.ReadKey() }

VirtualKeyCode Character ControlKeyState KeyDown
-------------- --------- --------------- -------
            18           LeftAltPressed    True
           112           LeftAltPressed    True
           112                        0    True

Please give the next nightly build a try; either build from source or wait ~1 hr for a binary to built by the CI

@nico-abram
Copy link
Contributor Author

I can confirm alt+F1 now works in FAR on nightly

@wez wez closed this as completed in 3ca840a Jan 8, 2022
@NikGovorov
Copy link
Contributor

Hi @wez,

I think mod+F1-F4 for example Alt+F1 does not work again on Windows.

@wez
Copy link
Owner

wez commented Apr 12, 2022

@NikGovorov: please open a new issue so that we can investigate this further!

@NikGovorov
Copy link
Contributor

Done #1865

@github-actions
Copy link
Contributor

github-actions bot commented Feb 4, 2023

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 4, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds. keyboard Keyboard mapping/handling
Projects
None yet
Development

No branches or pull requests

3 participants