urxvt-tabbedex
urxvt-tabbedex copied to clipboard
mina86
Using tabbedex makes initial window too small
Slackware64-15.0 urxvt v9.26 (+ slackware patches to use libutempter) If I execute urxvt -geometry 80x24 -pe tabbedex then in the new terminal window 'tput lines' outputs 23 and 'tput cols' outputs 77.
I would, of course, expect 24 and 80, respectively. Is this just me, or is this a more wide-ranging problem?
Columns being 77 is really surprising. Rows being one less has been an issue at one point but it should have been fixed since IIRC.
That might have been the fastest reply in the history of github, thanks.
I am surprised by that difference as well. However, typing
echo 12345678901234567890123456789012345678901234567890123456789012345678901234567
into the window shows that tput is not confused.
A long time ago I hacked some changes into tabbedex to fix this, in the function on_resize_all_windows(). However, for better or worse (better, no doubt) that function is gone, so I can't (quickly) hack them back in.
FWIW, I am using a TTF version of Inconsolata, like this:
urxvt -font xft:inconsolata:size=10 -geometry 80x24 -pe tabbedex
Those sizing issues are always annoying to debug and I pretty much never could reproduce them to be honest. Could you provide output of xrdb -query? Also, if you up to it, could you try compiling urxvt 9.30 and trying on it as well? (Yes, urxvt didn’t have a release in nearly five years and then all of a sudden had three in a span of six months ;) ).
Compiling 9.30 will take a bit of time, but for now here is xrdb. (I know that for this tabbedex I need to change my resource names from "tabbed", but I'm hoping that isn't the issue.) There is a lot of stuff I think is irrelevant, but in case I'm wrong, here's everything. I see it is past time to go remove some ancient cruft.
Emacs*XlwScrollBar.Background: NavajoWhite4
Emacs*XlwScrollBar.Foreground: NavajoWhite4
Emacs*background: #120059
Emacs*bitmapIcon: on
Emacs*cursorColor: green
Emacs*foreground: white
Emacs*pointerColor: #ffff33
Emacs*w3-node-style.attributeForeground: red
Emacs*w3-visited-node-style.attributeForeground: grey70
Emacs.bold-italic.attributeForeground: red
Emacs.bold.attributeForeground: yellow
Fig.splash: false
URxvt.background: #000050
URxvt.color8: rgb:7f/7f/7f
URxvt.colorBD: yellow
URxvt.colorUL: cyan
URxvt.cursorColor: green
URxvt.cursorColor2: black
URxvt.cutchars: *
URxvt.deletekey:
URxvt.foreground: white
URxvt.iconFile: /home/zsd/.urxvt/terminal.svg
URxvt.keysym.C-M-S-Left: perl:tabbedex:move_tab_left
URxvt.keysym.C-M-S-Right: perl:tabbedex:move_tab_right
URxvt.keysym.Insert: eval:paste_primary
URxvt.keysym.KP_Insert: eval:paste_primary
URxvt.keysym.M-Left: perl:tabbedex:prev_tab
URxvt.keysym.M-Right: perl:tabbedex:next_tab
URxvt.keysym.M-t: perl:tabbedex:new_tab
URxvt.perl-lib: /home/zsd/.urxvt
URxvt.pointerColor: red
URxvt.print-pipe: sh -c 'cat > $(TMPDIR=$HOME mktemp urxvt-screen-dump.XXXXXX)'
URxvt.saveLines: 2000
URxvt.scrollTtyKeypress: True
URxvt.scrollTtyOutput: False
URxvt.scrollWithBuffer: True
URxvt.scrollstyle: next
URxvt.tabbed.autohide: True
URxvt.tabbed.tab-bg: 19 ! The active tab (19 = 00/00/af)
URxvt.tabbed.tab-fg: 11 ! The active tab (11 = yellow)
URxvt.tabbed.tabbar-bg: 0 ! bg of empty space and inactive tabs
URxvt.tabbed.tabbar-fg: 246 ! text of inactive tabs, separators
URxvt.tabbed.title: False
XBiff.file: /home/myuseridhere/mail/inbox
XDiff*confirmQuit: false
XDiff*exit.accelerator: ~Shift<Key>Q
XDiff*exit.acceleratorText: q
XDiff*lineNumbers: False
XDvi.Offset: 1truein
XDvi.cursorColor: red
XDvi.editor: xdvi-reverse-search +%l %f
XDvi.expert: true
XDvi.gamma: 3
XDvi.mainTranslations: #override Ctrl<Key>Return: back-page()\n Alt<Key>Return: back-page()\n
XTerm*background: #000050
XTerm*backspacekey: \177
XTerm*charClass: 37:48,45-47:48,58:48,61:48,63-64:48,126:48
XTerm*colorBD: yellow
XTerm*colorBDMode: on
XTerm*colorUL: cyan
XTerm*colorULMode: on
XTerm*cursorColor: green
XTerm*deletekey: \010
XTerm*eightBitInput: false
XTerm*foreground: white
XTerm*pointerColor: red
XTerm*scrollBar: true
XTerm*scrollBar_right: false
XTerm*termName: xterm
XTerm.vt100.translations: #override <Key>BackSpace: string(\177) \n <Key>Delete: string(\010)
Xcursor.size: 24
Xft.antialias: 1
Xft.autohint: 0
Xft.hinting: 1
Xft.hintstyle: hintfull
Xft.lcdfilter: lcddefault
Xft.rgba: rgb
cosnole-xterm*background: darkgreen
main-tty-xterm*background: navy
noseguy*program: fortune
phosphor*program: fortune
tux-xterm*background: #003080
xclock*clientDecoration: none
xfd*background: darkblue
xfd*foreground: white
xfontsel*background: blue
xfontsel*foreground: white
xpdf.t1Courier: /usr/share/ghostscript/fonts/n022003l.pfb
xpdf.t1CourierBold: /usr/share/ghostscript/fonts/n022004l.pfb
xpdf.t1CourierBoldOblique: /usr/share/ghostscript/fonts/n022024l.pfb
xpdf.t1CourierOblique: /usr/share/ghostscript/fonts/n022023l.pfb
xpdf.t1Helvetica: /usr/share/ghostscript/fonts/n019003l.pfb
xpdf.t1HelveticaBold: /usr/share/ghostscript/fonts/n019004l.pfb
xpdf.t1HelveticaBoldOblique: /usr/share/ghostscript/fonts/n019024l.pfb
xpdf.t1HelveticaOblique: /usr/share/ghostscript/fonts/n019023l.pfb
xpdf.t1Symbol: /usr/share/ghostscript/fonts/s050000l.pfb
xpdf.t1TimesBold: /usr/share/ghostscript/fonts/n021004l.pfb
xpdf.t1TimesBoldItalic: /usr/share/ghostscript/fonts/n021024l.pfb
xpdf.t1TimesItalic: /usr/share/ghostscript/fonts/n021023l.pfb
xpdf.t1TimesRoman: /usr/share/ghostscript/fonts/n021003l.pfb
xpdf.t1ZapfDingbats: /usr/share/ghostscript/fonts/d050000l.pfb
I can reproduce it and it’s present in tabbed as well so it’s not tabbedex-specific issue.
URxvt.scrollBar: false
URxvt.internalBorder: 0
‘Solves’ this issue.
You might try experimental branch. I push a change which seems to fix the issue with internal border. There’s still issue with scroll bar not being accounted for.
OK, I think this is fixed. Border as well as scroll bars are taken into account.
I'll try it out. Compiling 9.30 is turning out to be a bit more of an issue than I had hoped, since it requires libptytty to be installed first. Which is leading me down the rabbit hole, unfortunately.
I'll try it out. Compiling 9.30 is turning out to be a bit more of an issue than I had hoped, since it requires libptytty to be installed first. Which is leading me down the rabbit hole, unfortunately.
If it’s non trivial it’s probably not worth bothering at this point.
I just tried out the new tabbedex. Here is a very strange thing: sometimes the initial window is the requested size, sometimes it is a bit smaller. I just started two urxvts in exactly the same way, and one is 79x23 (820x504 pixels on my screen) and the other is 80x24 (823x508).
I did a diff of the two versions (earlier today and the most recent one) and I didn't see any random number features. Maybe I need to look more closely? Any thoughts? I'm open to more tests, if anyone has any good suggestions.
(I'm using fvwm2 2.6.9, should that have any relevance.)
This is either a bit of information and/or a dumb question, since I admittedly don't understand everything going on inside tabbedex.
After calling $root->XMoveResizeWindow($root->parent, 0, 0, $w, $h); I notice that, although the X window on the screen changed size, $root->width (and $root->height) do not always change. Is this expected?
Further, I put some debug statements in start(), refresh() and configure(), and note this oddity:
_on start(): hpadding = 23 vpadding = 4
w = width (800) + hpadding (23)
h = height (504) + vpadding (4)
calling XMoveResizeWindow(...,823,508)
after XMRW root->width = 800, root->height = 504
configure() calling XMoveResizeWindow(, 0, 1 [= 1 + tabheight], 800,
504 [r->ht - r->tbht])
then calling XMoveResizeWindow(, 0, 0 [= tabheight], 800,
504 [r->ht - r->tbht])
refresh() called, visible =
refresh(): w, h = 800, 504
refresh() returning (! visible)
_on start about to return
configure() calling XMoveResizeWindow(, 0, 1 [= 1 + tabheight], 823,
508 [r->ht - r->tbht])
then calling XMoveResizeWindow(, 0, 0 [= tabheight], 823,
508 [r->ht - r->tbht])
refresh() called, visible =
refresh(): w, h = 823, 508
refresh() returning (! visible)
configure() calling XMoveResizeWindow(, 0, 1 [= 1 + tabheight], 820,
504 [r->ht - r->tbht])
then calling XMoveResizeWindow(, 0, 0 [= tabheight], 820,
504 [r->ht - r->tbht])_on start(): hpadding = 23 vpadding = 4
w = width (800) + hpadding (23)
h = height (504) + vpadding (4)
calling XMoveResizeWindow(...,823,508)
after XMRW root->width = 800, root->height = 504
configure() calling XMoveResizeWindow(, 0, 1 [= 1 + tabheight], 800,
504 [r->ht - r->tbht])
then calling XMoveResizeWindow(, 0, 0 [= tabheight], 800,
504 [r->ht - r->tbht])
refresh() called, visible =
refresh(): w, h = 800, 504
refresh() returning (! visible)
_on start about to return
configure() calling XMoveResizeWindow(, 0, 1 [= 1 + tabheight], 823,
508 [r->ht - r->tbht])
then calling XMoveResizeWindow(, 0, 0 [= tabheight], 823,
508 [r->ht - r->tbht])
refresh() called, visible =
refresh(): w, h = 823, 508
refresh() returning (! visible)
configure() calling XMoveResizeWindow(, 0, 1 [= 1 + tabheight], 820,
504 [r->ht - r->tbht])
then calling XMoveResizeWindow(, 0, 0 [= tabheight], 820,
504 [r->ht - r->tbht])
The first group of print statementsfrom configure() are
print "configure() calling XMoveResizeWindow(, 0, ", $root->{tabheight} + 1;
print " [= 1 + tabheight], ", $root->width, ",\n ";
print $root->height - $root->{tabheight}, " [r->ht - r->tbht])\n";
and the second is the same, except for the +1.
As you see, the root->width (and height) have magically changed sizes. However, this happens only sometimes when I start up urxvt, not all the time.
I don't know if this sheds any light on the problem, but in case it does, here it is.
The other thing I note is that even in the cases where the initial tab starts at the requested size, if I use my window manager to resize the window (by making it larger and then back to the original size) in one resize action, there is confusion between tabbedex and my window manager about how big the window really is. Let me know if you would like some specifics.
My understanding is that the width and height should change. Part of the problem is that interface for interacting with X that urxvt offers to extensions is a bit lacking so there may be errors that go unreported. I’ll try to do some more investigation later today.
I don't know about the urxvt interface specifically, but I suspect part of the problem is that since some (most?) X lib calls are asynchronous, XMoveResizeWindow() is probably returning (some times) before the effect has taken place, but tabbedex blissfully carries on assuming effects have completed, and yet they might not have.
This may be 100% wrong, but it would explain why I "randomly" get different results on different invocations. The last time IO looked at this problem, IIRC I was trying to find a way to know that XMoveResizeWindow()'s action had taken effect before I moved on, but I did not find it. I don't know whether there is no such facility available to a urxvt perl extension, or whether it was staring me in the face and I didn't see it.
Unfortunately, this problem still exists with urxvt 9.31.
And (interestingly) when I open a terminal window, it typically has a non-integer number of lines and columns displayed, even with the tab bar hidden (only one tab). And my window manager (fvwm2) won't let me resize the window to get an even number of lines or columns (it restricts me to making the window one line/column bigger or smaller).
Any recent thoughts about this?
Hi, I have found a work-around for this problem. Investigation shows that when a terminal windows is first opened, XMoveResizeWindow() is called four times, once from start(), next from make_current() and twice more from configure_notify(). Here is the relevant output from some print statements when the problem manifests itself:
init(): root->{h and v padding} = 4
init(): scrollBar is defined
get_scrollbar_thickness() called
sb style is next and its width is 19
get_scrollbar_thickness() returning 19
init(): root->hpadding incremented by sb width to 23
start(): hpadding = 23 vpadding = 4
w = width (800) + hpadding (23)
h = height (504) + vpadding (4)
calling XMoveResizeWindow(...,823,508)
after root->XMRW root->width = 800, root->height = 504
make_current() calling configure()
configure() calling XMoveResizeWindow(, 0, 1 [= 1 + tabheight], 800,
504 [r->ht - r->tbht])
then calling XMoveResizeWindow(, 0, 0 [= tabheight], 800,
504 [r->ht - r->tbht])
start() about to return
configure_notify() calling configure()
configure() calling XMoveResizeWindow(, 0, 1 [= 1 + tabheight], 823,
508 [r->ht - r->tbht])
then calling XMoveResizeWindow(, 0, 0 [= tabheight], 823,
508 [r->ht - r->tbht])
configure_notify() calling configure()
configure() calling XMoveResizeWindow(, 0, 1 [= 1 + tabheight], 820,
504 [r->ht - r->tbht])
then calling XMoveResizeWindow(, 0, 0 [= tabheight], 820,
504 [r->ht - r->tbht])
As you see, the height and width are magically reset to 504 and 820 (from the correct 508 and 823) in the fourth call. On my system, this "magic" is sporadic, in that sometimes the fourth call has the correct numbers, and other times it doesn't.
A simple hack to fix this (I am making no claims it is nice, but it has the expediency of working) is to put a delay in the program between the two XmoveResizeWindow() calls in configure(). On my system,
select(undef, undef, undef, 0.01);
makes one terminal window opened a time reliably open to the correct size, but if I have a script open 20 terinals in very quick succession, not all open correctly. A delay of 1.25 seconds makes them all open at the correct size, and a delay of 0.1 seconds makes many of them open correctly.
I'm not sure exactly what you want to do with this, but since a delay of 0.1 seconds shouldn't cause most people a problem, and works in many cases, would you care to add it to the code base? (Until a "real" fix comes along, anyway?)
I guess I should sort of withdraw the above comment. With the delays, the initial window opens at the right size. But if I subsequently change the window size (via the window manager), the terminal is likely to end up in a size with a "partial" line or column, and after this happens getting it back to an integer number or lines and columns is something I haven't succeeded in doing.
My personal version of tabbedex, based on some versions floating around about 8 years ago, does not have this problem. You made some major re-writes, and so it is difficult to compare them to see what the problem is. Perhaps a binary search to look for the guilty update is in order.