> interestingly this only works in some versions of acme and sam. > it seems to work ok under plan 9, and in inferno's acme, > but not in p9p or acme sac.
There are two different issues here. One is getting an actual \r to the program in question (acme, sam, etc.) and the second is how that program interprets it. The first issue is getting a \r to the program. On most systems, you type \r. On Windows, Enter sends \r so the keyboard handler swaps \r and \n, so you type Ctl-J to get \r. (If anyone cared, I think you could check for Ctl in the input handler and not swap in that case.) This applies to drawterm, inferno, and 9pm, which all share the same gui code (I think 9pm is the progenitor). The second issue is what the program thinks \r is. There's a long, boring history of Plan 9 coming to grips with the many extra keys on the PC keyboard, but the short version is that for a long time the End key's only use was to generate \r. That era ended in December 2003, around the time rio, sam, and acme started using Home, End, PgUp, and PgDown for scrolling. Unfortunately, the p9p keyboard.h didn't get the memo, and it was still using \r as End. This meant that when you typed Ctl-M acme or sam saw End (and probably didn't scroll because you were in a window with little text). I just fixed this in p9p cvs and hg. (I had always chalked it up to an X11 input issue similar to the Windows one, or I'd have gone looking for it years ago.) I can't explain why acme sac doesn't handle \r right, but now you know where to look. Russ
