Beautifying xterm, and/or wasting opportunities to get back into dayshift mode post nights
Like Andrew, I decided a few days ago to change my entire environment over from ISO8859-1 to UTF-8 (dammit, what was wrong with US-ASCII anyway, apart from being invented by the Americans?). The driver was querybts erroneously (debian bug 487674, 497641, 213470, etc) putting out utf-8 when the terminal wasn't capable of it, so every now and then the terminal would lock up. This started happening everytime for some bugs, and I traced it down to querybts (recently?) outputting cutsie wutsie symbols:
14) #487789 [i||☺↝] [apt-cacher] apt-cacher locks when using checksum and requiring it concurr
I also had always found it mildly annoying that at some time in the past, I had to play with the 8 bit clean settings in /etc/inputrc for some reason I can't recall, which meant I then had to redefine all the other key combinations that were now being interpreted as 8 bit key combos:
"�": forward-word #\M-f
(where � was the iso-8859-1 representation of what came out of C-v M-f)
But UTF-8 always seemed to cause me more problems. Logging into systems would all get confused, etc.
But I found that if I set LANG=LC_MESSAGES=en_AU.UTF-8 (utf8 on some systems, but UTF-8 always seems to work), logged out completely so any new xterms inherited the right environment, and changed all of my systems so they don't explicitly set LC_MESSAGES to en_AU (ISO-8859-1) fixed that.
So next, the only font I found that could render both the characters in querybts's output, and any characters I could find on the net/in my spam folder, and displayed 0 with a dot in it (a feature I only just discovered during my experimenting (had been using the default "fixed" in xterm for years), which I found extremely useful and all of a sudden indispensable), and allows arbitrary rescaling, was DejaVu. So, in ~/.Xdefaults (and ~/.Xresources, symlinked):
!http://www.leonerd.org.uk/hacks/hints/xterm-sensible.html
XTerm*VT100.faceName: DejaVu Sans Mono
XTerm*VT100.boldFont: DejaVu Sans Mono:style=Bold
XTerm*VT100.faceSize: 11
However, setting the face sizes for shift-kp+/- was unreliable:
!doesn't seem to set the relative sizes as monotonically increasing - can't slot default size=11 in between facesize4 and facesize5
!XTerm*VT100.faceSize1: 1
!XTerm*VT100.faceSize2: 5
!XTerm*VT100.faceSize3: 7
!XTerm*VT100.faceSize4: 9
!XTerm*VT100.faceSize5: 14
!XTerm*VT100.faceSize6: 17
So I went back to defining non-xft fonts which set the scaling and the default font size relative to the other selectable fonts, which xft then overrides the actual fonts (but not their sizes) with:
!When using xft fonts (facename below), these below just set the relative scalings and where the default font size fits in relative to the other font sizes
!XTerm*VT100.Font2: -efont-fixed-medium-r-normal-*-12-*-*-*-*-*-iso10646-1
!XTerm*VT100.Font2: -misc-fixed-medium-r-*--12-*-*-*-*-*-iso10646-1
XTerm*VT100.Font2: -misc-fixed-medium-r-normal-*-8-80-75-75-c-50-iso10646-1
XTerm*VT100.Font3: -misc-fixed-medium-r-normal-*-13-*-*-*-*-*-iso10646-1
XTerm*VT100.Font4: -efont-fixed-medium-r-normal-*-14-*-*-*-*-*-iso10646-1
!XTerm*VT100.Font5: -efont-fixed-medium-r-normal-*-16-*-*-*-*-*-iso10646-1
XTerm*VT100.Font: -misc-fixed-medium-r-normal--18-*-*-*-*-*-iso10646-1
XTerm*VT100.Font5: -misc-fixed-medium-r-normal--20-*-*-*-*-*-iso10646-1
!XTerm*VT100.Font6: -efont-fixed-medium-r-normal-*-24-*-*-*-*-*-iso10646-1
XTerm*VT100.Font6: -misc-fixed-medium-r-normal-*-24-*-*-*-*-*-iso10646-1
(efonts is from xfonts-efont-unicode and xfonts-efont-unicode-ib)
Annoyingly, displaying an xterm over a ssh connection to 1000km away was very slow at drawing the fonts. Paging up and down in pine would cause redisplays to take a few seconds (and scrolling through my spam folder line by line was impossibly annoying), compared to instaneous redisplays in the past. So for remote pine sessions (displayed within an xterm started remotely via bindings within gbuffy), I overrode the font selections to go back to non-xft rendered fonts, and selected a large font size (that's how I read email - I'm getting blinderer) manually:
xterm -geometry 125x28 -fn '-misc-fixed-medium-r-normal-*-24-*-*-*-*-*-iso10646-1' -xrm 'XTerm*renderFont:false' -e pine
But gee fixed-24 looks ugly and blocky, looking like it has been rendered at the incorrect size. If I select via shift-KP_- the next smallest font (defined by XTerm*VT100.Font5 = fixed-20 above), then it looks fine. Another twisty passage to this spagetti was my spam folder. I actually found I had been using the fact that pine would display "??????" for anything international. For me, international==spam, which makes for a very useful mental filter - if I see a block of "????", then it speeds up my visual processing a hell of a lot compared to seeing
+ N 7902 Thu11am john-patrick chun (7041) База данных
So I overrode the xterm that starts the spam folder version of pine with
env LANG=POSIX LC_MESSAGES=POSIX pinexterm -f spam
Now finally, pressing meta-q in an emacs session to justify text was screwing up, as was meta prefixes in bash and readline, outputting strange characters or worse. So clean up all that crap I had in /etc/inputrc, and set 8 bit clean mode:
# Be 8 bit clean.
set input-meta on
set output-meta on
set convert-meta off
and tell xterm to send meta chars as escape prefixes instead of a high bit in ~/.Xdefaults:
!to get meta characters to be able to be input in bash and emacs in an xterm:
!http://www.leonerd.org.uk/hacks/hints/xterm-8bit.html
XTerm*VT100.utf8: 1
XTerm*VT100.eightBitInput: false
XTerm*VT100.eightBitControl: false
XTerm*VT100.eightBitOutput: true
Remaining issues: the terminal (specifically, readline history recall in bash) sometimes gets confused and repositions the cursor up a line everytime the up arrow is pressed, until enter is pressed (on some unknown line that you can't read because the display lines are messed up), whereupon history will function normally again. Under circumstances I don't yet understand or can reliably reproduce. I wonder if the "stty sane" in my $PROMPT_COMMAND is interacting with the 8-bit clean mode and/or some other method of playing nasty tricks?
The ℃ symbol Andrew talks about doesn't seem to be in my copy of DejaVu, and I get a square box at least in xterm (and can't be bothered firing up openoffice to see what it thinks).
Strangely, rescaling the fonts in the non-xft rendered xterm sometimes get rid of the abilty for the querybts symbols to be rendered properly. Not all of the -fixed- sizes were created equally.
Non xft rendered fixed-24 (the incorrectly scaled one) leaves dags behind.
The dash is a bit too short for my tastes. Yes, I know it's typesettically correct, but my tastes are set in stone now, unfortunately. ls --color looks silly when the dash is only a few pixels wide, and gnu/posix didn't standardise on the em-dash when choosing the character used in setting commandline switches.
Nice surprises: Now I can cut and paste scientific/international stuff from a webpage, and paste into an xterm (slrn, the bash prompt, etc) without getting missing characters or strange side effects, because meta is now effectively now sent out of band.
Summary
Now, where's the interrobang key on my keyboard?
Lunix on *my* desktop finally enters the 19th century. In most of my xterms (I've got a tiny little xterm that sits in my FvwmButtons that is only just wide enough to display 'ncal -3', and stays on all virtual screens, for doing quick nasty one liners, like start up other xterms or aforementioned 'ncal -3'. Because it's tiny, it needs to be a small font, and fixed still works best for that)
Incidentally, it's probably a good thing that the new Telscope Control Computer appears to be fully operational as of a couple of weeks ago[1], because I don't think the old interdata supports UTF-8 (not that it has ssh or indeed telnet either - wouldn't fit in core or on the disks). Expect the old interdata to be decommisioned over the next 6 months. Anyone want nixie and/or nimo tubes? I won't vouch for the core memory - it actually developed a core parity error 2 nights ago - I walked past it on the way back from the tearoom, and it was startingly obvious that it was stuck - the flickering front panel register and program counter lights are very notable in their absense. I didn't bother exercising (mpg and asf also in the same location) the Big White Lever, because the new TCS was functioning so well without the old Computor Control System. I encouraged the dinosaur herder over a beer today to pull the Big Red Switch, but he wasn't having anything of it. Something about tempting fate. And 37 year old paper capacitors in power supplies.
[1] Modulo decreasing numbers of bugs of lesser importance - although I did alert my boss today^Wyesterday to the fact that the servoing algorithm is entirely suboptimal (the D term in the PID loop is set to zero) compared to modern servo algorithms employed on the likes of the VLT despite the fact that the world expert on telescope servoing algorithms wrote the source code to ours
14) #487789 [i||☺↝] [apt-cacher] apt-cacher locks when using checksum and requiring it concurr
I also had always found it mildly annoying that at some time in the past, I had to play with the 8 bit clean settings in /etc/inputrc for some reason I can't recall, which meant I then had to redefine all the other key combinations that were now being interpreted as 8 bit key combos:
"�": forward-word #\M-f
(where � was the iso-8859-1 representation of what came out of C-v M-f)
But UTF-8 always seemed to cause me more problems. Logging into systems would all get confused, etc.
But I found that if I set LANG=LC_MESSAGES=en_AU.UTF-8 (utf8 on some systems, but UTF-8 always seems to work), logged out completely so any new xterms inherited the right environment, and changed all of my systems so they don't explicitly set LC_MESSAGES to en_AU (ISO-8859-1) fixed that.
So next, the only font I found that could render both the characters in querybts's output, and any characters I could find on the net/in my spam folder, and displayed 0 with a dot in it (a feature I only just discovered during my experimenting (had been using the default "fixed" in xterm for years), which I found extremely useful and all of a sudden indispensable), and allows arbitrary rescaling, was DejaVu. So, in ~/.Xdefaults (and ~/.Xresources, symlinked):
!http://www.leonerd.org.uk/hacks/hints/xterm-sensible.html
XTerm*VT100.faceName: DejaVu Sans Mono
XTerm*VT100.boldFont: DejaVu Sans Mono:style=Bold
XTerm*VT100.faceSize: 11
However, setting the face sizes for shift-kp+/- was unreliable:
!doesn't seem to set the relative sizes as monotonically increasing - can't slot default size=11 in between facesize4 and facesize5
!XTerm*VT100.faceSize1: 1
!XTerm*VT100.faceSize2: 5
!XTerm*VT100.faceSize3: 7
!XTerm*VT100.faceSize4: 9
!XTerm*VT100.faceSize5: 14
!XTerm*VT100.faceSize6: 17
So I went back to defining non-xft fonts which set the scaling and the default font size relative to the other selectable fonts, which xft then overrides the actual fonts (but not their sizes) with:
!When using xft fonts (facename below), these below just set the relative scalings and where the default font size fits in relative to the other font sizes
!XTerm*VT100.Font2: -efont-fixed-medium-r-normal-*-12-*-*-*-*-*-iso10646-1
!XTerm*VT100.Font2: -misc-fixed-medium-r-*--12-*-*-*-*-*-iso10646-1
XTerm*VT100.Font2: -misc-fixed-medium-r-normal-*-8-80-75-75-c-50-iso10646-1
XTerm*VT100.Font3: -misc-fixed-medium-r-normal-*-13-*-*-*-*-*-iso10646-1
XTerm*VT100.Font4: -efont-fixed-medium-r-normal-*-14-*-*-*-*-*-iso10646-1
!XTerm*VT100.Font5: -efont-fixed-medium-r-normal-*-16-*-*-*-*-*-iso10646-1
XTerm*VT100.Font: -misc-fixed-medium-r-normal--18-*-*-*-*-*-iso10646-1
XTerm*VT100.Font5: -misc-fixed-medium-r-normal--20-*-*-*-*-*-iso10646-1
!XTerm*VT100.Font6: -efont-fixed-medium-r-normal-*-24-*-*-*-*-*-iso10646-1
XTerm*VT100.Font6: -misc-fixed-medium-r-normal-*-24-*-*-*-*-*-iso10646-1
(efonts is from xfonts-efont-unicode and xfonts-efont-unicode-ib)
Annoyingly, displaying an xterm over a ssh connection to 1000km away was very slow at drawing the fonts. Paging up and down in pine would cause redisplays to take a few seconds (and scrolling through my spam folder line by line was impossibly annoying), compared to instaneous redisplays in the past. So for remote pine sessions (displayed within an xterm started remotely via bindings within gbuffy), I overrode the font selections to go back to non-xft rendered fonts, and selected a large font size (that's how I read email - I'm getting blinderer) manually:
xterm -geometry 125x28 -fn '-misc-fixed-medium-r-normal-*-24-*-*-*-*-*-iso10646-1' -xrm 'XTerm*renderFont:false' -e pine
But gee fixed-24 looks ugly and blocky, looking like it has been rendered at the incorrect size. If I select via shift-KP_- the next smallest font (defined by XTerm*VT100.Font5 = fixed-20 above), then it looks fine. Another twisty passage to this spagetti was my spam folder. I actually found I had been using the fact that pine would display "??????" for anything international. For me, international==spam, which makes for a very useful mental filter - if I see a block of "????", then it speeds up my visual processing a hell of a lot compared to seeing
+ N 7902 Thu11am john-patrick chun (7041) База данных
So I overrode the xterm that starts the spam folder version of pine with
env LANG=POSIX LC_MESSAGES=POSIX pinexterm -f spam
Now finally, pressing meta-q in an emacs session to justify text was screwing up, as was meta prefixes in bash and readline, outputting strange characters or worse. So clean up all that crap I had in /etc/inputrc, and set 8 bit clean mode:
# Be 8 bit clean.
set input-meta on
set output-meta on
set convert-meta off
and tell xterm to send meta chars as escape prefixes instead of a high bit in ~/.Xdefaults:
!to get meta characters to be able to be input in bash and emacs in an xterm:
!http://www.leonerd.org.uk/hacks/hints/xterm-8bit.html
XTerm*VT100.utf8: 1
XTerm*VT100.eightBitInput: false
XTerm*VT100.eightBitControl: false
XTerm*VT100.eightBitOutput: true
Remaining issues: the terminal (specifically, readline history recall in bash) sometimes gets confused and repositions the cursor up a line everytime the up arrow is pressed, until enter is pressed (on some unknown line that you can't read because the display lines are messed up), whereupon history will function normally again. Under circumstances I don't yet understand or can reliably reproduce. I wonder if the "stty sane" in my $PROMPT_COMMAND is interacting with the 8-bit clean mode and/or some other method of playing nasty tricks?
The ℃ symbol Andrew talks about doesn't seem to be in my copy of DejaVu, and I get a square box at least in xterm (and can't be bothered firing up openoffice to see what it thinks).
Strangely, rescaling the fonts in the non-xft rendered xterm sometimes get rid of the abilty for the querybts symbols to be rendered properly. Not all of the -fixed- sizes were created equally.
Non xft rendered fixed-24 (the incorrectly scaled one) leaves dags behind.
The dash is a bit too short for my tastes. Yes, I know it's typesettically correct, but my tastes are set in stone now, unfortunately. ls --color looks silly when the dash is only a few pixels wide, and gnu/posix didn't standardise on the em-dash when choosing the character used in setting commandline switches.
Nice surprises: Now I can cut and paste scientific/international stuff from a webpage, and paste into an xterm (slrn, the bash prompt, etc) without getting missing characters or strange side effects, because meta is now effectively now sent out of band.
Summary
Now, where's the interrobang key on my keyboard?
Lunix on *my* desktop finally enters the 19th century. In most of my xterms (I've got a tiny little xterm that sits in my FvwmButtons that is only just wide enough to display 'ncal -3', and stays on all virtual screens, for doing quick nasty one liners, like start up other xterms or aforementioned 'ncal -3'. Because it's tiny, it needs to be a small font, and fixed still works best for that)
Incidentally, it's probably a good thing that the new Telscope Control Computer appears to be fully operational as of a couple of weeks ago[1], because I don't think the old interdata supports UTF-8 (not that it has ssh or indeed telnet either - wouldn't fit in core or on the disks). Expect the old interdata to be decommisioned over the next 6 months. Anyone want nixie and/or nimo tubes? I won't vouch for the core memory - it actually developed a core parity error 2 nights ago - I walked past it on the way back from the tearoom, and it was startingly obvious that it was stuck - the flickering front panel register and program counter lights are very notable in their absense. I didn't bother exercising (mpg and asf also in the same location) the Big White Lever, because the new TCS was functioning so well without the old Computor Control System. I encouraged the dinosaur herder over a beer today to pull the Big Red Switch, but he wasn't having anything of it. Something about tempting fate. And 37 year old paper capacitors in power supplies.
[1] Modulo decreasing numbers of bugs of lesser importance - although I did alert my boss today^Wyesterday to the fact that the servoing algorithm is entirely suboptimal (the D term in the PID loop is set to zero) compared to modern servo algorithms employed on the likes of the VLT despite the fact that the world expert on telescope servoing algorithms wrote the source code to ours