Terminal: Using Far Manager under Terminal: Command history similar to IntelliSense does not work

[safopet]

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:

[zadjii-msft]

Hey thanks for the bug report! Since we're not super familiar with far commander, could yo u help answer a couple questions?

• What version of the Windows Terminal are you using?
• What version of Windows are you running?
• What keys are you pressing to open that dialog?
• What would you expect to be happening?

[safopet]

What version of the Windows Terminal are you using?

Version: 0.7.3382.0

What version of Windows are you running?

Windows 10 Pro 1909 18363.535 (Russian localization)
Also, I use a latest stable builds of Far Manager: 3.0.0.5511 x64

What keys are you pressing to open that dialog?

I pressed any letter key. When I prepare screen-shot I presss 'y'.

What would you expect to be happening?

I expect showing a list of commands that I recently typed and they begin with pressed letters (a like IntelliSens in Visual Studio) as in screen-shot in my first message:

However, Nothing to happened:

[dmytro-boichenko]

I fixed that issue just by adding %ProgramFiles%\\Far Manager to local PATH variable

[zadjii-msft]

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.

[gabest11]

https://github.com/FarGroup/FarManager/issues/262

[alabuzhev]

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:

• Press any key, e.g. Space
• Hold it for a while
• Release it
• Compare the output.

Conhost:

KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000020 (casac - ecNs)
KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000020 (casac - ecNs)
KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000020 (casac - ecNs)
KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000020 (casac - ecNs)
KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000020 (casac - ecNs)
KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000020 (casac - ecNs)
KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000020 (casac - ecNs)
KEY_EVENT_RECORD: Up, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000020 (casac - ecNs)

Terminal:

KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns)
KEY_EVENT_RECORD: Up, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns)
KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns)
KEY_EVENT_RECORD: Up, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns)
KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns)
KEY_EVENT_RECORD: Up, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns)
KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns)
KEY_EVENT_RECORD: Up, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns)
KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns)
KEY_EVENT_RECORD: Up, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns)
KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns)
KEY_EVENT_RECORD: Up, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns)
KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns)
KEY_EVENT_RECORD: Up, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns)

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:

• illogical
• a breaking change.

[DHowett]

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.

[DHowett]

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.

[alabuzhev]

@DHowett , thanks for the explanation.
It's a little sad though that more and more native concepts are being sacrificed for VT compatibility.

[DHowett]

I agree! We're trying to avoid or repair those sacrifices where possible. :smile:

• make/break events for other terminals to implement
• Mapping VT mouse input -> win32 mouse input (#376)
• X10 focus events can be coded in VT, which could help us generate a FOCUS_INPUT_EVENT
• OSCs that report/set the palette can interact with the traditional conhost color palette

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.