Hi Thomas,
"xterm" doesn't crash, it just gives the above message and quits -
which
would've been unfortunate, hadn't I be running tmux at the time ;)
I don't see a crash (it probably depends on whether you have the bitmap
fonts installed). Instead, it gives a message:
xterm-dev: cannot load font "2"
To reproduce it needs a few tries.
Here's my ~/.Xresources; I'm using TT fonts, perhaps that's another
factor as well:
XTerm*charClass: 36:48,43:48,45-47:48,59:48,63-64:48,95:48,126:48
XTerm*background: lightyellow
XTerm*foreground: black
XTerm*altSendsEscape: true
XTerm*metaSendsEscape: true
XTerm*utf8Title: true
XTerm*utf8: always
XTerm*visualBell: true
XTerm*renderFont: true
XTerm*faceName: DejaVu Sans Mono
XTerm*faceSize1: 8
XTerm*faceSize2: 10
XTerm*faceSize3: 12
XTerm*faceSize: 13
XTerm*faceSize4: 15
XTerm*faceSize5: 17
XTerm*faceSize6: 19
XTerm*fullscreen: never
and the locale is "de_AT.UTF-8", although xterm's message is talking
about 8859-1.
In the manual for xtermcontrol:
the "#" is literally part of the parameter (though the quotes are
misleading).
Yeah, I tried that as well.
Still, simply quitting just because the user asks for a different font
size
is bad behaviour - and real data might be lost (generated but
not-yet-saved
console output).
If there's no bitmap fonts, xterm's supposed to recover (and gray-out
the
items for the missing fonts). But I don't recall someone using
xtermcontrol
to test that with. If I knew the fonts you're using, I could reproduce
this.
Does the above ~/.Xresources help?
Perhaps it's easier to find out how xterm lands in that code path...
Thank you for your patience!
