tabbed extension mini-bugs

[James Cloos]

[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
as expected.

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
either issue.

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.

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6