Allow using characters typed via "Alt Gr" again (Follow up for Window.py)

[ufo]

Characters typed via "Alt Gr" also didn't appear in windows, e.g., for incremental search. I'm not sure why the "not is_ctrl_pressed(rec)" was placed in the final condition, so I hope it doesn't brake anything else?

[ufo]

I have some time these days and will have a try. By the way, how do you debug these key pressed handlers? Currently I'm using a debug snippet like this, together with a running DebugView from Microsoft:

rec = read_input()
import ctypes; ctypes.windll.kernel32.OutputDebugStringW(
    "PyCmd: %s %s %s %s" % (repr(rec.Char),
                            rec.VirtualKeyCode,
                            is_ctrl_pressed(rec),
                            is_alt_pressed(rec)))
if rec.Char == ...

Just to understand what's going on. For example, I wasn't aware about rec.Char often being x\0. But maybe you know a smarter way to display these values in runtime.

[ufo]

need to be validated on Linux as well, using branch "mesh"

Interesting to know that on Linux I don't need a patch to be able to type characters via "Alt Gr". It simply worked in your vanilla mesh branch. I've tested it in WSL+Ubuntu22.04.

But the patch above doesn't work on Linux since then rec.Char is 0 (thus an integer) instead of chr(0) as on Windows. Is that intentional?

self.filter += rec.Char
TypeError: can only concatenate str (not "int") to str

If it is supposed to be like that, then I would need to modify the patch like this:

if rec.Char == chr(0) or rec.Char == 0 \

Then the patch is also working in the 'mesh' branch on Linux.

[horeah]

If it is supposed to be like that, then I would need to modify the patch like this:

It is not; this is a mistake in console_linux.py, where I wrote 0 instead of chr(0) for lots of key combos :( Out of pure luck, it never mattered in practice due to the way the code paths are flowing.

Given this fact, my proposal is to fix the Ctrl-Alt-K issue as well as we can on Windows, and then rebase branch mesh on top of the new master (this is how I worked on branch mesh until now) and fix console_linux.py as/if needed.

[horeah]

Just to understand what's going on. For example, I wasn't aware about rec.Char often being x\0. But maybe you know a smarter way to display these values in runtime.

I'm afraid my methods are even more rudimentary than yours :|

There's a debug() function in common.py which (on branch master) allows you to print messages on some corner of the screen. On branch mesh, the debug() function has been replaced with a simpler implementation which appends the messages to <pycmd-data-dir>/debug.log; and I use tail -f to watch for these messages live.

[ufo]

Is the readability of the code better now? I've tested it on Windows and Linux.

[horeah]

Is the readability of the code better now? I've tested it on Windows and Linux.

Yes! The code looks much cleaner (to my eyes at least). Thank you!

I will validate the changes (on Windows) for the next few days in my daily work (I use PyCmd as a daily driver), and merge this if no additional problems arise.

On Linux: console_linux.py needs to be fixed to use a char instead of an int for PyINPUT_RECORDType.Char. I plan to do this on branch mesh, after rebasing it on top of your Windows.py on master. Would this be ok for you? (I am not sure how to work on branch mesh right now -- I am used to mostly developing solo so rebase+force-push is convenient for me; but it can create trouble if you also have changes there. Also see comments on Issue #11).

[ufo]

I use PyCmd as a daily driver

Me too, since many many years 🙌 And now that you started making it work under Linux, it will get massively more powerful, since many developer colleagues switch from Windows shell to WSL/Linux shell very often aswell👍 I'm using ConsoleZ together with your PyCMD by the way.

.. after rebasing it.. but it can create trouble if you also have changes there.

Absolutely no problem for me. To be able to test it under Linux I simply made a silly temp patch directly in Windows.py, since I didn't dig into console_linux.py.