From cff860335e2a0348d9f16db0a9ce3b8cee5b5270 Mon Sep 17 00:00:00 2001 From: Matthew Mondor Date: Sun, 17 Apr 2022 05:23:05 +0000 Subject: [PATCH] Update TODO after discovering the source of a bug --- MATT/TODO.txt | 33 ++++++++++++++++++--------------- 1 file changed, 18 insertions(+), 15 deletions(-) diff --git a/MATT/TODO.txt b/MATT/TODO.txt index 001e827..f965294 100644 --- a/MATT/TODO.txt +++ b/MATT/TODO.txt @@ -54,21 +54,24 @@ TODO https://en.wikipedia.org/wiki/Arrow_%28symbol%29#Unicode and ▮ from Geometric Shapes These have been remapped to existing graphics chars for now. -- On a friend's Ubuntu machine, analogterm runs and backspace runs fine in - general but not in top(1)'s line editor, despite ^H being set for ERASE. - Moreover, strangely, when switching to the English US keyboard layout (his - default are French Canadian), space no longer works. Space works in his - default layout. I should enable some X11 input debugging log and see what - gets issued for space, if any. Currently, the only space-related special - processing may be in utils/textclient.c and is to map the keypad space to - space. Apparently some users had similar issues with space not working - correctly when using extra input method tools like ibus-ui-gtk3. This was - running and I killed it but the issue persisted. Space works in xterm - despite that, so there must be something different going on with analogterm. - I should also check if xterm on Ubuntu uses the same stty settings like for - ERASE. No such problem with RPI2 and ArchLinux. - Update: Ubuntu x86-64 confirmed to use ^?/Delete by default in xterm, with - "tput kbs | xxd" showing it. +- Ubuntu x86-64 confirmed to use ^?/Delete by default in xterm, with + "tput kbs | xxd" showing it. With the current code setting ^H this breaks + backspace in some applications like top(1) without using stty(1) or tset(1) + explicitly. +- On a friend's Ubuntu x86-64 machine, space doesn't work. It gets swallowed + as part of the special code to allow inserting ^@. For the same reason, @ + also doesn't work and all the special PC key processing is broken. This + only happens when switching to the US layout, everything is fine with the + Canadian French one. The issue is that with this keymap, left and right + Ctrl and Shift are all reported as pressed. No such issue when switching + with setxkbmap on RPI2 running ArchLinux. + Update: xfce bug where any layout that's not the first/default one in the + switching plugin gets Ctrl/Shift flagged in X11 XKeyEvent's state field, + affecting various applications, but not all. Presumably applications that + check up/down events to themselves handle Ctrl/Shift flags are not affected. + Fixed by replacing the plugin by two buttons directly invoking setxkbmap for + now. Leaving this note in case someone else experiences a similar issue, to + have a clue on how to fix it. - Apparently eol2 can be used for Flush and Linux would not support it. On NetBSD I see it applied by xterm, so have included in tcsetattr(3). This may be wrong on Linux. Moreover, running xterm remotely from an Ubuntu -- 2.9.0