False Prophets

I do about half my text editing in joe, and half of it in emacs. It’s just what I’ve gotten used to; for a year or two I used primarily joe, and I gradually migrated until I did most of my programming in emacs instead, but I still do random text files in joe. I’ve been gradually trying to migrate to emacs; not least because upgrading joe has gotten to be such a pain.

I use jpico rather than joe, you see. But I started using it a long time ago, probably around when joe 2.8 was current in Debian. And the jpico key bindings keep changing! Which is infuriating, so I keep having to rewrite my keybindings to stay mostly the way I like them.

I like that emacs is such a smart editor. Especially since it defaults to all sorts of nice GNU-ish settings and most of my C is for GNU projects. But when I work on other things, I have to learn how to make it either disable smarts or use appropriate ones, so in self defence I keep learning new things about emacs…

One things I’ve been annoyed at before is the binding for scroll-other-window. You can split a window into two (C-x 2). I often do that while writing a changelog up top of a patch file, whether I’m using joe or emacs at the moment. An advantage of emacs is that you can scroll the window that the cursor isn’t in, paging down through the text you’re describing while keeping the cursor where you’re writing. But it’s bound by default to C-M-v and C-S-M-v (control-meta and control-shift-meta). Hard to hit C-M-v, and impossible to enter C-S-M-v; you can not distinguish Control and Control-Shift in a vt100 terminal (like, say, inside of screen).

Fortunately, you say, it’s also bound to M-next and M-prior (meta-page down and meta-page up)? Well, yes… but… you can’t type that either at a terminal. Normally. I can now though.

Fixing it took two parts. First, I discovered that Meta-next sent the same sequence as plain next, in my xterms. I think I’ve convinced myself this is a bug in xterm. My keymap, which is a pretty standard pc(pc105)+us+altwin(meta_win), has Super_L and Hyper_L bound to modifier 4 along with Meta_L and Meta_R. xterm sees these strange keys and decides that mod4 must be some sort of “other” modifier, in code that looks like it’s for handling num lock. Fortunately, I can work around this easily. I don’t have a Super or Hyper key, so I deleted the bindings by adding this to my .xsession:

  xmodmap -e 'remove mod4 = Super_L'
  xmodmap -e 'remove mod4 = Hyper_L'

UPDATE: This will be fixed in xterm #223, since Thomas Dickey agreed it was a bug.

Next, I discovered that emacs didn’t recognize the sequence produced after that fix. It didn’t recognize C-next or A-next either. So I added this to my .emacs:

  ; Key magic.  Emacs nor terminfo normally have bindings for these.
  ; The meta binding in particular takes a bit of X magic also; see
  ; the xmodmap call in /.xsession.
  (define-key function-key-map "e[6;5~" '[C-next])
  (define-key function-key-map "e[6;9~" '[M-next])
  (define-key function-key-map "e[6;3~" '[A-next])
  (define-key function-key-map "e[5;5~" '[C-prior])
  (define-key function-key-map "e[5;9~" '[M-prior])
  (define-key function-key-map "e[5;3~" '[A-prior])

That really should be conditionalized on the terminal type, but I didn’t want to mess with it any more. And now it works. Woohoo!