-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Using Far Manager under Terminal: Command history similar to IntelliSense does not work #3910
Comments
Hey thanks for the bug report! Since we're not super familiar with far commander, could yo u help answer a couple questions?
|
I fixed that issue just by adding |
Just tried that out locally - unfortunately didn't do anything for me 😕. Maybe they're doing something weird like creating another screen buffer? I really have no idea why this would be happening. |
In the linked issue it has been discovered that GetNumberOfConsoleInputEvents API reports 1 under this new terminal and 0 under the default console host after receiving the identical keyboard input. I think this might be the cause: Please take this tool - readkey.zip - and do the following under both conhost and terminal:
Conhost:
Terminal:
I.e. terminal reports paired false "Up" events even though the key stays down. If terminal sends the Up event instantaneously after the Down event, and not when I release the key as it should, it's not surprising that the Up is already in the input queue while we're still processing the Down event. In any case, the current terminal behaviour regarding Up and Down event is:
|
Discussion moved from FAR-262 You're not wrong about it being a breaking change, but it's a breaking change for clients who should be robust enough to handle it. The core issue is that there is not a broad standard in use that allows for a VT encoding of make/break sequences. There's no widely-compatible mechanism for communicating a key's press and release separately over SSH (or anywhere VT input is required). The few specifications there are (DECKPM, DECSMKR, DECPCTERM) are not offered by any terminal emulator, and there is a handful of homegrown implementations (libtickit, kitty's make/break extension). Given that the entire rest of the world settled on key press being the event of repute and chose to discard key release, it's not illogical at all. |
We knew going into this that in choosing a naturally less-featureful pipe (by going "all in" on VT for input/output) we'd hit an impedance mismatch for a small percentage of Windows applications. It was a sacrifice we initially made for broader compatibility: trading working with a larger percentage of terminal emulators for losing a smaller percentage of Windows apps. Internally (to Terminal), we're still unfortunately hampered by our UI framework in determining when a character-generating key was released. We've gotta fake it because that's what we're given. Externally, we're trying to change the landscape with the spec from #4999, but I can't speak for when other terminal emulators on Windows will follow us in implementing make/break sequences. |
@DHowett , thanks for the explanation. |
I agree! We're trying to avoid or repair those sacrifices where possible. 😄
I'd continue listing, but it would rapidly take us off-topic. I don't want to sacrifice the things that made the console infrastructure on Windows good; I'd just like to sacrifice the ones that made it worse. |
Hey so I know it's been few years, but I'm playing around with Far 3.0.5888.0 and Terminal 1.12, and this seems fixed to me. This was either fixed by #4999, or a patch on the Far side. |
@zadjii-msft yes, there's now a workaround for this in Far. However, it's worth mentioning that WT keyboard handling is still wonky: false "Up" events are still there for most of the keys. |
I like to use Far Manager (64-bit clone of Norton Comander).
https://www.farmanager.com/index.php?l=en
However I can't use very helpful functionality that available if run far manager under simple cmd:
The text was updated successfully, but these errors were encountered: