GeezerVison

This makes Alt+← and Ctrl-Alt+← work just as Ctrl+←. Is that how it should be?

On Unix for me Alt+← gives me capital C (not sure why, does not really make sense to me) and Ctrl-Alt+← triggers my window manager.

In the keymap I also don't see Alt-left with a special meaning:

Exactly, I didn't see anything existing that was useful for Alt+←, so I figured might as well make it useful. I can remove it if you prefer only Ctrl+← being useful. Also, it would definitely violate separation of concerns if this Lib/_pyrepl/windows_console.py file were to try to read the keymappings in Lib/_pyrepl/reader.py to check if r"\M-\<left>" existed, and I don't expect that to be added anytime soon.

I would prefer all implementations (unix, windows, etc.) to have the same implementation. Please revert the changes to ALT. There might be good use for the ALT modifier, but that would be for another PR.

That brings up a good question, why don't we add (r"\M-\<left>", "backward-word") and (r"\M-\<right>", "forward-word") to the default_keymap, so that way all implementations will have something useful for Alt+←?

Also, I just tested that, and it made me realize that the Lib\_pyrepl\windows_console.py code also needs to # queue the key, return the meta command in the special key == "\x00" section (see 46b22d1 for the fix and removal of treating Alt+← as Ctrl+←).

I guess adding (r"\M-\<left>", "backward-word") and (r"\M-\<right>", "forward-word") to the default_keymap can be part of a separate GH Issue+PR...

Are you ok with the changes I made so we can resolve this conversation?

I don't know the answer. But why pass the ctrl modifier as a key f'ctrl {key}`, and the alt modifier using a special event?

Yeah, it took me a while to figure out what was going on in Lib\_pyrepl\keymap.py, cause the code is not very readable, but that's what it expects. If we wanted Ctrl and Alt to be treated in a similar way, we'd probably have to make some major edits to Lib\_pyrepl\keymap.py and Lib\_pyrepl\unix_eventqueue.py.

I'm not sure about including the right ALT in ALT_ACTIVE. On Linux, ALT+Backspace removes a whole word, whereas AltGr+Backspace removes a single character.

Lib/_pyrepl/keymap.py doesn't distinguish between right and left (it just has C- and M-), so I'm not sure that was a conscious decision that was made for the Linux code. Maybe that's actually a bug in the _pyrepl/unix_* code?

Lib/_pyrepl/keymap.py doesn't distinguish between right and left

Python 3.14 on Linux behaves differently for left Alt and right AltGr:

• Left Alt + backspace: remove a word
• Right AltGr + backspace: remove a single character

On my Linux, the English keyboard layout has Right Alt which generally works like Left Alt (in a terminal).
The French or Czech layout has AltGr instead, which is apparently not Meta enough, so AltGr+Backspace works like Backspace (in both pyrepl and bash).

I tried on some Windows consoles:

Doesn't look useful, so it's probably best to have Linux-like behaviour here.

I don't understand what you are saying. Are you saying because the existing functionality isn't useful, we should continue to make the right Alt key not be useful in _pyrepl?

Either way, if this is about AltGr, I think we have to really understand how it works in Windows... I don't have an AltGr key, so I can't test it, but https://en.wikipedia.org/wiki/AltGr_key says, "Windows interprets Ctrl+Alt as AltGr," and since the _KEY_EVENT_RECORD doc doesn't show a dwControlKeyState value for AltGr, doesn't that mean that RIGHT_ALT_PRESSED is not the same thing as AltGr and that the Lib/_pyrepl/windows_console.py code would actually have to look for a combination of Ctrl (left/right) and Alt (left/right) (or maybe just lefts?) being pressed to know if AltGr is being pressed, or am I misunderstanding how the _KEY_EVENT_RECORD works?

I didn't know that other keyboards have a right ALT key different than AltGr. In this case, I'm fine with ALT_ACTIVE = 0x01 | 0x02.

I don't understand what you are saying.

Sorry for being unclear!
I meant that the behaviour of Windows terminals I tried (cmd & powershell) is not useful, so Python should not emulate that.

I don't have an AltGr key, so I can't test it

It's a feature of the keyboard layout, not the physical keyboard. To test it you can add, for example, French "AZERTY" in system settings.

I didn't know that other keyboards have a right ALT key different than AltGr. In this case, I'm fine with ALT_ACTIVE = 0x01 | 0x02.