Re: [9front] [PATCH] Fix shift release events in X11 drawterm with shift:both_capslock xmodmap option

["Timothy Robert Bednarzyk" <mail@trbsw.dev>]

> this does seem like your xmodmap is causing a bug in x11.

I do actually have to apologize, I've had these options set in an X11
configuration file for months and had forgotten which program was used
to enable the option on the fly. Prior to sending my first e-mail, I had
quickly looked up the option to re-remember what program it was, and
xmodmap came up first (and, incidentally, I now remember that when I was
first attempting to do something similar to those options, I had tried
to do it with xmodmap first). As it turns out, those options can 
actually be set by setxkbmap, not xmodmap. The specific X11 program that
actually contains the options is mostly an inconsequential detail here,
I realize, but I wanted to correct myself regardless.

> the behavior is completely non-sensical. maybe nobody ever tested this
> x11 feature? ;)

I wouldn't be surprised if some emacs users were using the same options
as me; after all, I originally set them when I wanted to attempt to try
out emacs and was following the advice of many who suggest remapping
caps lock to control (but still wanted to have some way of toggling caps
lock). While I ended up not using emacs too much (honestly, I think I
prefer even ed over emacs), I did like the options that I'd set and have
kept them since. Drawterm was the first program that I've used where
this insane behavior in X11 actually surfaced as a problem, so I also
wouldn't be surprised if I was the first one to thoroughly test the
option and discover exactly how it's screwy.

> not sure how much we should care about workarounds for bugs that only
> happen in an edge-case of a (mis-?)configuration.

That is a good point. Originally, I was so focused on "fixing" the "bug"
in drawterm (when I should've just gone to bed) that I hadn't even
considered just getting the actual X11 bug fixed where it should be once
I learned what was causing the problem. I'll try to get it fixed
wherever appropriate first; this change to drawterm can be saved as a
last resort if someone determines that the current X11 behavior is not
to be changed for some bs reason like "compatibility", or even worse:
claims that it's actually the correct and intended behavior.

> otoh a few well commented lines that contain a good justification for
> this braindamage, which now exists after such deep analysis wouldn't
> bother me personally... even if it's just a link to this thread.

Should this change actually be applied to upstream drawterm, I fully
agree that the comment should just contain a link to this thread.

--
trb