> related to the earlier discussion, for stripping the \r at the end of
> lines in windows files, i use:
>
> ,x/$/ c//
>
> where is a cut&pasted return char (yes, i could use '.' instead,
> but i'm paranoid.) x doesn't seem to recognize \r as a escape
> sequence. true?

no they don't: sam/regexp.c and acme/regx.c both have a lex function
that starts basically like this (from acme)

int
lex(void){
int c;

c = *exprp++;
switch(c){
case '\\':
if(*exprp)
if((c= *exprp++)=='n')
c='\n';

i suppose you could also type 000d.

- erik

On Jul 17, 2008, at 8:28 PM, erik quanstrom wrote:
> i suppose you could also type
ctl+m

On Fri, Jul 18, 2008 at 1:45 AM, Pietro Gagliardi wrote:
> On Jul 17, 2008, at 8:28 PM, erik quanstrom wrote:
>> i suppose you could also type
>
> ctl+m

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.

> 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