tabbed extension mini-bugs
cloos+rxvt-unicode at jhcloos.com
Wed Aug 15 20:10:25 CEST 2007
[ARGH; sent with wrong From line; resending with that fixed. -JimC]
About a year ago there was a report here that the tabbed extension was
shrinking the geometry by an extra line. Ie, specifying 80x24 gave a
subwindow of 80x22 instead of the expected 80x23.
I'm getting even fewer. I get 78x22 for the default 80x24, and 94x64
for my preference of 96x66. (With either 8.2 or 8.3.)
Some of the shifted keys also partially fail.
I use click to focus (with icewm).
W/o the tabbed extension all of the keys work the same no matter where
the mouse pointer is.
With the tabbed extension, Shift-F1 thru Shift-F10 still generate
unshifted F11 thru F20 as expected no matter where the pointer is.
And the extension's own Shift-Down, Shift-Left and Shift-Right work
But Shift-Insert, Shift-PgUp and Shift-PgDown are ignored unless the
pointer is in the term subwindow of the focused window. Also, although
Shift+Control successfully starts ISO 14755 mode, the non-modifier keys
(space, return, backspace and the hex keys) are ignored unless the
pointer is in the subwindow.
> From reading rxvt_term::key_press() in command.C, the fact that Shift-
Insert is affected suggests that (priv_modes & PrivMode_ShiftKeys) is
false. Unless, I suppose, ctrl and/or meta are getting spuriously set.
That part leaves me confused. Obviously the logic:
((ctrl && (keysym == XK_Shift_L || keysym == XK_Shift_R))
|| (shft && (keysym == XK_Control_L || keysym == XK_Control_R)))
works, but (shft && ctrl) does not seem to.
Before looking at that bit of code, I didn't know about the support for
PrintScreen. I just tried it and when using the tabbed extension, if
the pointer is not in the (sub)window neither ctrl nor shft are >0 when
scr_printscreen(ctrl | shft) is called. Which leaves me completely
confused as to how the ISU_14755 overlay gets new()ed....
I'm still poking through the code, but I haven't yet derived a fix for
Having to resend this saves me from posting a followup:
After sending it the first time I discovered that Compose sequences are
also affected by the tabbed extension.
To illustrate, I'll use the sequence « Multi_Key o o o » which should
generate a degree sign followed by a lowercase letter O: « °o ».
Without the tabbed extension everything works perfectly.
With the tabbed extension, if the pointer is in the term subwindow the
Multi_Key is ignored; the above sequence results in « ooo ». If the
pointer is anywhere else, the entire sequence is ignored, resulting,
in the case of our example sequence, just one letter o: « o ».
Perhaps this will help diagnose the cause.
James Cloos <cloos at jhcloos.com> OpenPGP: 1024D/ED7DAEA6
More information about the rxvt-unicode