[Question] How does far decide where to open up the right-click menu?

[PankajBhojwani]

Hello! I am a dev over at the Windows Terminal team and we are trying to get right-clicking in far to operate correctly. Far seems to be receiving the right-click we send to it, but it doesn't open up the right-click menu at the correct place - the right-click menu always opens at the center of the screen (even though we send the mouse coordinates of the right click).

So, we are pretty sure we are omitting something when we send the Win32 right-click or possibly even before that when we send the hover events. Could you inform me on how far decides where to open the right-click menu? If you could point me to the relevant section(s) of the code that would help too!

[johnd0e]

There is an option in settings defining whether menu should be opened in the center, or at the mouse cursor position.
See Plugins settings / Emenu.

[PankajBhojwani]

Hm so it seems that regardless of what I set and save that setting to, the right-click menu opens at the center.

EDIT: Just to check if I am setting it correctly, here's what I'm doing:
ConfMn (at the bottom) -> Options (at the top) -> Plugins configuration -> EMenu -> Menu position -> change setting -> Save

[alabuzhev]

Hi @PankajBhojwani. To check that you're setting it correctly you could try it under the standard conhost.
The code that determines the cursor position is here.
If you could point me to the version of Terminal with mouse support, I'll have a look from our side as well.

[PankajBhojwani]

Hi! Sorry that it took a while to get back to you.

The latest version of Terminal Preview from the Microsoft Store supports mouse mode (version 1.9.x and onward).

So there's something interesting going on here, in standard conhost the right-click menu always seems to open up at the position of the mouse cursor, regardless of what I set the setting to, and in terminal the right-click menu always opens at the center regardless of the setting.

I wonder if this has something to do with far using GetCursorPos to get the position of the cursor directly instead of using the coordinates received from the mouse event.

[alabuzhev]

in standard conhost the right-click menu always seems to open up at the position of the mouse cursor, regardless of what I set the setting to

That option only applies when the menu is invoked via the Apps key (VK_APPS).
When the menu is invoked via the mouse right click that option is ignored.

I wonder if this has something to do with far using GetCursorPos to get the position of the cursor directly instead of using the coordinates received from the mouse event.

It seems that the root issue is in GetClientRect API behavior in Terminal:

• in standard conhost it returns a sensible RECT that is the same as the console client area in pixels, e.g. {LT(0, 0) RB(1080, 600) [1080 x 600]}.
• in terminal it returns rubbish - {LT(0, 0) RB(120, 0) [120 x 0]}

The code then checks if the mouse position is within that area, obviously fails and fallbacks to the screen center.

[DHowett]

Ah, that’s curious. We should be returning 0, 0, 0, 0. There is no legal HWND for a Terminal pane or an SSH client session, and so the API provides a message-only window.

[alabuzhev]

That's unfortunate.
I kinda understand the motivation, but it would break quite a lot of 3rd party plugins, e.g. various picture viewers that draw their windows on top of the console.

[alabuzhev]

We should be returning 0, 0, 0, 0. There is no legal HWND for a Terminal pane or an SSH client session, and so the API provides a message-only window.

That's unfortunate.
I kinda understand the motivation

Although no, I don't understand this motivation. I don't understand this motivation at all.

Broken APIs:

• GetClientRect
• GetWindowRect
• GetCurrentConsoleFont
• GetCurrentConsoleFontEx
• ...the list probably goes on and on

https://docs.microsoft.com/en-us/windows/console/getconsolewindow:

This API is not recommended and does not have a virtual terminal equivalent. This decision intentionally aligns the Windows platform with other operating systems. This state is only relevant to the local user, session, and privilege context. Applications remoting via cross-platform utilities and transports like SSH may not work as expected if using this API.

With all due respect, breaking something completely only because it didn't work in some arcane contexts and calling it "intentional aligning" is like saying "we don't support displays anymore, because there are blind people. Learn Braille, it works everywhere".

I miss the Good Ol' Days, when Microsoft was not afraid of setting the standards in the industry and actually cared about backwards compatibility - not only by replicating its own bugs, but even by fixing them in 3rd party software.
And now it hectically chops its legs off, because "other operating systems" were born crippled. 😞

Sorry for the rant, just saying.

[d3x0r]

Someone is making far work in Microsoft terminal? Can this issue be more general to just address that?

I recently implemented escape code input for a text editor.... this same escape sequence method is where one is supposed to get mouse events when running in Microsoft Terminal..... microsoft/terminal#376 . And I was going to dig into this myself...

Will this become a pull request upstream? a fork to follow?

https://forum.farmanager.com/viewtopic.php?f=20&t=11622&p=154201&hilit=microsoft+terminal#p154201 people on this thread might want to know too...

---

Edit: Small note I found on input for keys at least - escape codes come in the normal event channels, but with keycode and scancode 0, but in a set, so you should read input events into a larger than 1 event buffer; and result with the count of events received....