Friday, December 21, 2018

This year has brought a bunch of changes with it for me, and some of the related effects has been sorting out my ideal development environment yet again. It's been a few years since this came up in any tangible sense, and while I solved it before, I didn't take many notes in terms of what makes me really happy. This time, I'm trying to write it all down for the sake of posterity.

It's amazing just how much detail there is when you sit down and start unpacking it. What you consider as normal is probably made up of thousands of little choices, each with a reason for existing.

One disclaimer: I don't expect anyone to appreciate all of this, and I expect quite a few will reject all of it. That's OK. There are a number of "holy war" level matters discussed herein. If that's how you feel, then this is not for you. You are probably THE ONE and all systems are built around your desires and always work for you.

With that out of the way, let's talk about terminals. Well, I guess it's actually terminal emulation, because who has a real physical terminal any more? Not me.

I happen to use urxvt, but honestly can't remember what got me onto the rxvt ecosystem from xterm in the first place. It happened over 20 years ago, and neither my memory nor my old chat logs are of any assistance. It might have involved dialog/menuconfig (from Slackware) and the box characters looking bad. It might have involved certain alt-key combos not working in my IRC client over ssh any more. Honestly, I don't know for sure.

The one thing about it which needs to be changed from defaults is how it handles triple-click behavior. I expect a triple-click to select the ENTIRE line, not some subset of it, no matter what it contains. I don't care if it's got more parentheses than a packed LISP convention. It needs to be click-click-click equals whole line highlighted and ready to go as an X selection which can then be pasted somewhere else immediately.

The easiest way to do that is to dump some gunk into the .Xresources:


(Then you have to bonk it over the head with xrdb to load them and open a fresh terminal, of course.)

This was a recent discovery for me. Before finding this way to switch off the insanity, I'd just roll a fresh binary with the perl extension stuff switched off. I can still tell which machines pre-date this discovery because "which urxvt" shows me something OTHER than the official upstream-package-provided binary.

In terms of keyboards, I find that a cheap Logitech K120 works fine and can be had at any office supply store in a pinch. It has every key I need to use, and doesn't do ridiculous stuff like hiding important things behind a "Fn" modifier. I've done the model M thing (actual IBM models from the 80s, mind you), but it's not the vibe I want any more. I don't need to assault everyone around me with the clacka-clack-clack when I really get going.

Next, I want the keys on my keyboard to repeat relatively soon after I start holding down one of them, and to repeat rather quickly once it gets going. It turns out that I really like holding down backspace in certain situations where readline isn't in use, or the usual readline combos otherwise won't get me where I'm going. I've also been known to put a nice line of "---" or "***" or even "..." in a text file to separate things. Being able to do that by holding down the key is far better than beating it to death.

This one is simple enough, too:

xset r rate 250 30

What I find interesting is that even in this day of USB keyboards, the key-repeat settings seem to follow the keyboard and disappear if it gets unplugged, just like the old 5-pin DIN and not-so-old PS/2 days. That is, if I unplug it, clean my desk, and plug it back in, it's back to defaults. It's nothing another quick call to xset will fix, but it still seems funny to me. Notice that the LEDs themselves are maintained on the computer side, but the key repeat apparently is not. It's been a long time, but I'm pretty sure you could get the LEDs out of sync with the computer in the pre-USB days, which suggested a totally different implementation.

My tendency to hold down backspace in some situations has exposed a surprising number of wonky input bugs over the years. A certain large web site had a text input form that acted on every single character typed instead of just letting it be a simple client-side TEXTAREA. If you held down BS long enough, it would actually jump all the way back to the beginning of the field. Clearly, they had tried to implement their own state machine for how to handle the whole type-a-key-render-the-screen loop, and got something majorly wrong.

That is, you're typing out this big long thing, smack backspace a few too many times too quickly, and the next thing you know, your cursor is at the VERY BEGINNING of the line, sentence, paragraph, or post, instead of just a bit to the left. It's really annoying when it happens.

While we're on the topic of the whole push-a-key-see-the-change loop, let's talk about that. I expect the screen to change in the way I wanted it to, assuming I hit the right key. It needs to happen right away unless there's some good reason for it to not. This means if I'm in a text editor, I hit the key, and the displayed state changes to reflect that, and there's no uncertainty about it.

If there's lag because light is slow and I'm far away from some box, then okay, fine, I can deal with that. Having grown up with dialup connections means I can handle up to 200-300 msec of lag, assuming it's still fairly constant. It's the variable lag -- jitter -- that really bothers me, and I've written about that before.

I don't type *that* quickly, but when I can outrun a modern huge machine with multiple GHz-speed cores, tons of memory, and zippy storage with no moving parts, something is very wrong! As slow as the VIC-20s, C-64s and Apple IIs of their day were overall, they tended to have nice short rendering loops for text input, and I got used to it. Anything less is going to feel like a regression, because, well, it IS.

I've found that "editors" which are actually giant blobs of Javascript doing who knows what which have the network and backend systems in the rendering loop tend to drive me nuts eventually. They are entirely inconsistent in how well they can keep up with my typing.

I wrote about using nano as my daily driver editor way back in a 2011 post. It's still the case. It stays out of my way and matches what's been programmed into my fingers for the past 25 years now. Yep, it was 1993 when I settled on an editor in the Unix world. Granted, it was pico then, but the better-licensed nano is effectively the same thing.

There's one thing from recent years which has to go, though: syntax highlighting. I don't want any color in my editor that I didn't put there first... and I don't put color anywhere. I want it to match the same scheme which the rest of my terminals have: green on black.

This is not some new rant. I think I first saw color-based syntax highlighting in 1999 on a friend's workstation, and just couldn't understand why anyone would want it. Then I've run across it on occasion when borrowing someone else's machine, and/or using vim to get something done on short order when nano/pico wasn't available. All of the blinkiness and stuff flipping around when I type things and it starts figuring out what it means is just not something I want. Also, call me weird, but I find the code itself already has this kind of meta-feel to it for me, like a certain "texture" on the letters when things are set up right. Someone else's choices will never match.

I used to kill this in nano much like I used to kill triple-clicking in urxvt, which meant chopping it out with a recompile. Those older machines still have some other binary in my PATH as a result. But, I recently discovered a .nanorc setting which will do the same thing. It looks bogus but it does the job nicely, cargo-cult style:

syntax "all" ".*"
color yellow "^$"

It works, and I no longer have to slice and dice my editor everywhere.

The pattern I'm noticing here is that all of this stuff was probably the default behavior at some point, and then something changed, and I didn't like it. So, then, instead of having it stay intact, I had to go out and shave some yaks to keep it working the way I wanted.

Closely related to the display is the actual monitor. It has to be big enough to hold a handful of non-overlapping terminals at a decent resolution. Right now I'm on a 25" monitor at 1920x1080 and that works well enough -- six non-overlapping 80x25 urxvts is no problem. The no-longer-produced Apple Thunderbolt monitor gives me 2560x1440, and that means I can pop open twelve 80x25 urxvts before they start overlapping. (I usually don't, but I can, and that's amazing.)

In practice, some of those terminals will be stretched different ways depending on what's going on: source editing tends to get somewhat taller windows to fit a reasonable amount of context, for instance. Running programs that use glog tends to get max-width windows because those log messages can be incredibly wide. That sort of thing.

Regardless of whatever monitor I'm using, it needs to be at a reasonable height above the desk, such that I'm not looking too far off horizontal at it -- that is, up or down too much. That means putting the monitor straight on the desk probably is no good unless it also happens to incorporate a rather large vertically-sliding stand.

In practice, this means I usually end up stacking the monitor on top of something -- a box holding festive mugs, the computer itself, or whatever.

If I'm dual-screening it and the laptop's actual display is involved, then it also has to be raised up. A previous job gave me a whole stack of physical books when I started there, as they did all new people in that job description. I used them to hold up the laptop. In that sense, those books "supported" my entire time at that company.

I've seen people use reams of paper grabbed from the copier/printer supply rooms to accomplish this, too. Whatever works for you.

The desk itself needs to be at a reasonable height. This is rarely a problem. I've been given "desks" which are actually just glorified picnic tables and are seriously scratchy right at the front edge where your arms might rest at times. My solution there usually involves some kind of fabric tape. Life's too short to go home with weird scrape marks just around the corner from your elbow every night.

The desk's thickness is related to this. The desk itself has to be high enough to support the keyboard at a reasonable height while also not being so low that I can't fit my legs underneath it. This has never been a problem, but it's worth mentioning for the sake of completeness. Having a typical adjustable office chair makes this easy to handle.

The desk needs to be deep enough to let me push the keyboard back away from the edge without dropping the monitor on the floor. There's also the matter of having enough spacing to not kick the person opposite me, assuming the typical Silly Valley thing of desks pushed into each other from all sides. The depth of the desk affects whether you can stretch your legs without making for awkward work situations.

I should mention that it would be nice to have a desk with a modesty panel on occasion. However, since most places tend to issue tables, not true desks, that seems to be hard to come by. How I tell them apart, incidentally: a desk has drawers, preferably locking, and hopefully the modesty panel. A table is just a flat surface with some legs.

Why locking drawers? So I can put my purse away and not have to carry it around the office all day. Leaving it on my desk all day is tacky (and invites theft - a whole other problem at big companies), and dragging it around everywhere just makes me look like a refugee. I usually end up getting a locking pedestal to bridge the gap.

Why the modesty panel? Easy: I sometimes wear things other than pants (as in slacks, for those of you from Europe...), particularly if the weather is nice. Duh. (Did you forget who you were reading?) It would be nice to sit and work without worrying about what kind of randos are somewhere downrange crawling around on the floor wiring stuff up (or worse).

Finally, there's the matter of the OS and GUI setup. I find that Ubuntu vs. Slackware vs. CentOS vs. whatever doesn't really bother me too much any more, particularly if the machine is really just being used as a fairly dumb terminal. I just ended an almost five year stint using a an Ubuntu VM just running X, Fluxbox (a window manager), Firefox, a bunch of terminals, and ssh connections to other machines where the "real work" happened.

The fact it was Ubuntu underneath mattered very little. It would occasionally apply some security patch to a package, and I'd have to restart the browser or whatever, but that was it. It basically stayed out of my way and that's all I really wanted from it.

Fluxbox, meanwhile, is a window manager that doesn't try to be a desktop environment and can be reduced to about the minimum amount of cruft possible while still being useful. I use it to pick workspaces with ALT and a function key, move or resize windows, open those few things I run regularly, and display two ancient Window Maker era applets from the 90s - one for the CPU load and another for the day, date and time with second-level precision. That's it. It doesn't try to "manage my files" or let me "drag and drop" things. It just manages windows.

Some day maybe I'll write about "war rooms" and why they are bad for actually getting deep thoughtful analysis type work done. Stuff like this is a big part of it.