Mail services (such as Google Mail) will often have directories with names that contain spaces. Acme does not support spaces in window names. So, replace spaces in mail directory names with the Unicode character for visible space. The code is a bit of an over-approximation and generally non-optimal. R=rsc, david.ducolombier, 0intro CC=plan9port.codebot https://codereview.appspot.com/13010048

UTF-8 searches with the SEARCH command must be conducted in two steps: the first sends the SEARCH command with the length of the UTF-8 encoded string and the second sends the literal search term. The searches need to not be quoted. R=rsc, david.ducolombier, rsc, 0intro CC=plan9port.codebot https://codereview.appspot.com/13244043

R=rsc CC=plan9port.codebot https://codereview.appspot.com/12505045

R=rsc CC=r https://codereview.appspot.com/12577043

Everyone seems to assume that TERM != dumb implies ANSI escape codes are okay. In fact, many people assume that unconditionally, but it is easier to argue back about TERM=dumb than TERM=9term. This applies to acme win too, because they share the code. Set termprog=9term or termprog=win for clients who need to know. R=rsc CC=r https://codereview.appspot.com/12532043

R=rsc https://codereview.appspot.com/12162043

See https://bitbucket.org/rsc/plan9port/issue/128/alt-button-sticks-in-acme-sometimes-after R=rsc https://codereview.appspot.com/11453043

R=rsc https://codereview.appspot.com/10690044

R=rsc https://codereview.appspot.com/10458043

There are two bugs in pdec() on INT_MIN: * wrong output. `n = 1-n' should be `n = -1-n' when n is INT_MIN. * infinite loop. gcc optimizes `if(n>=0)' into `if(true)' because `-INT_MIN' (signed integer overflow) is undefined behavior in C, and gcc assumes the negation of a negative number must be positive. The resulting binary keeps printing '-' forever given INT_MIN. Try the simplified pdec.c below. $ gcc pdec.c $ ./a.out -2147483648 --214748364* $ gcc pdec.c -O2 $ ./a.out -2147483648 <infinite loop> $ gcc pdec.c -O2 -D__PATCH__ $ ./a.out -2147483648 -2147483648 === pdec.c === #include <stdio.h> #include <stdlib.h> #include <limits.h> #define io void void pchr(io *f, int c) { putchar(c); } void pdec(io *f, int n) { if(n<0){ #ifndef __PATCH__ n=-n; if(n>=0){ pchr(f, '-'); pdec(f, n); return; } /* n is two's complement minimum integer */ n = 1-n; #else if(n!=INT_MIN){ pchr(f, '-'); pdec(f, -n); return; } /* n is two's complement minimum integer */ n = -(INT_MIN+1); #endif pchr(f, '-'); pdec(f, n/10); pchr(f, n%10+'1'); return; } if(n>9) pdec(f, n/10); pchr(f, n%10+'0'); } int main(int argc, char **argv) { int n = atoi(argv[1]); pdec(NULL, n); putchar('\n'); } R=rsc CC=plan9port.codebot https://codereview.appspot.com/7241055

gcc compiles `p + length < p' into 'length < 0' since pointer overflow is undefined behavior in C. This breaks the check against a large `length'. Use `length > pend - p' instead. There's no need to check `length < 0' since `length' is from length_decode() and should be non-negative. === Try the simplified code. void bar(void); void foo(unsigned char *p, int length) { if (p + length < p) bar(); } $ gcc -S -o - t.c -O2 ... foo: .LFB0: .cfi_startproc testl %esi, %esi js .L4 rep ret .L4: jmp bar .cfi_endproc Clearly `p' is not used at all. R=rsc CC=plan9port.codebot https://codereview.appspot.com/7231069

R=rsc https://codereview.appspot.com/7565045

For single-button mouse users. R=rsc https://codereview.appspot.com/7620043

R=rsc https://codereview.appspot.com/7304064

Ubuntu Precise seems to have a buggy X server that sometimes fails at XCopyArea. Let devdraw do it itself. This will slow down remote X a little bit, but slow and correct is better than fast and broken. R=rsc https://codereview.appspot.com/7310069