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

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

Closed
safopet opened this issue Dec 11, 2019 · 12 comments
Labels
Area-Output Related to output processing (inserting text into buffer, retrieving buffer text, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Tag-Fix Doesn't match tag requirements Priority-2 A description (P2) Product-Conpty For console issues specifically related to conpty
Milestone

Comments

@safopet
Copy link

safopet commented Dec 11, 2019

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:
image

@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Dec 11, 2019
@zadjii-msft
Copy link
Member

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?

@zadjii-msft zadjii-msft added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Dec 11, 2019
@safopet
Copy link
Author

safopet commented Dec 12, 2019

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:
image
However, Nothing to happened:
image

@ghost ghost added Needs-Attention The core contributors need to come back around and look at this ASAP. and removed Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something labels Dec 12, 2019
@DHowett-MSFT DHowett-MSFT added Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-2 A description (P2) Product-Conpty For console issues specifically related to conpty Area-Output Related to output processing (inserting text into buffer, retrieving buffer text, etc.) labels Dec 12, 2019
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Dec 12, 2019
@DHowett-MSFT DHowett-MSFT removed Needs-Attention The core contributors need to come back around and look at this ASAP. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Dec 12, 2019
@DHowett-MSFT DHowett-MSFT modified the milestones: Console Backlog, 21H1 Dec 12, 2019
@dmytro-boichenko
Copy link

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

@zadjii-msft
Copy link
Member

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
Copy link

gabest11 commented Aug 3, 2020

FarGroup/FarManager#262

@alabuzhev
Copy link
Contributor

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
Copy link
Member

DHowett commented Aug 3, 2020

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
Copy link
Member

DHowett commented Aug 3, 2020

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
Copy link
Contributor

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

@DHowett
Copy link
Member

DHowett commented Aug 3, 2020

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

  • make/break events for other terminals to implement
  • Mapping VT mouse input -> win32 mouse input ([Conpty] Add support for 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.

@zadjii-msft
Copy link
Member

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.
image

This was either fixed by #4999, or a patch on the Far side.

@ghost ghost added the Needs-Tag-Fix Doesn't match tag requirements label Jan 4, 2022
@alabuzhev
Copy link
Contributor

@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.
Surprisingly, some do work correctly, e.g. cursor keys, modifiers, PgUp, PgDn, Home, End, Tab, Del, Ins.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Output Related to output processing (inserting text into buffer, retrieving buffer text, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Tag-Fix Doesn't match tag requirements Priority-2 A description (P2) Product-Conpty For console issues specifically related to conpty
Projects
None yet
Development

No branches or pull requests

7 participants