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!

Reply via email to