Before, executing Get in a file rewound the window offset and selection to the start of the file. After this CL, Get preserves the window offset and selection, where preserve is defined as "the same line number and rune offset within the line". So if the window started at line 10 before and the selection was line 13 chars 5-7, then that will still be true after Get, provided the new content is large enough. This should help the common situation of plumbing a compiler error, realizing the window is out of date, clicking Get, and then losing the positioning from the plumb operation.

Thanks to Lorenzo Beretta for noticing.

Bad remote file systems can change mtime unexpectedly, and then there is the problem that git rebase and similar operations like to change the files and then change them back, modifying the mtimes but not the content. Avoid spurious Put errors on both of those by checking file content. (False positive "modified since last read" make the real ones difficult to notice.)

Should be a clean build now. Change-Id: Id3460371cb5e8d4071f8faa9c2aec870d213a067 Reviewed-on: https://plan9port-review.googlesource.com/2781 Reviewed-by: Russ Cox <rsc@swtch.com>

Reading /mnt/acme/log reports a log of window create, put, and delete events, as they happen. It blocks until the next event is available. Example log output: 8 new /Users/rsc/foo.go 8 put /Users/rsc/foo.go 8 del /Users/rsc/foo.go This lets acme-aware programs react to file writes, for example compiling code, running a test, or updating an import block. TBR=r R=r https://codereview.appspot.com/89560044

TBR=r https://codereview.appspot.com/89510044

Bakul Shah has observed corrupted files being written when acme writes over osxfuse to sshfs to a remote file system. In one example we examined, acme is writing an 0xf03-byte file in two system calls, first an 0x806-byte write and then a 0x6fd-byte write. (0x806 is BUFSIZE/sizeof(Rune); this file has no multibyte UTF-8.) What actually ends up happening is that an 0x806-byte file is written: 0x000-0x6fd contains what should be 0x806-0xf03 0x6fd-0x7fa contains zeros 0x7fa-0x806 contains what should be 0x7fa-0x806 (correct!) The theory is that fuse or sshfs or perhaps the remote file server is mishandling the unaligned writes. acme does not seem to be at fault. Using bio here will make the writes align to 8K boundaries, avoiding the bugs in whatever underlying piece is broken. TBR=r https://codereview.appspot.com/89550043

This allows commands in bin subdirectories. R=rsc CC=plan9port.codebot https://codereview.appspot.com/13254044

R=rsc CC=plan9port.codebot http://codereview.appspot.com/6854092

R=rsc http://codereview.appspot.com/6736060

R=rsc CC=plan9port.codebot http://codereview.appspot.com/6614056

Home and End previously navigated between two different window locations: the top and the bottom of the text. Now they include a third waypoint: the location where typing last happened. Thus, in a win window, typing ls -l <home> scrolls to the beginning of the ls -l output. A second <home> continues to the top of the file. Makes Send scroll always, along with writes by external programs to +Errors. R=r CC=mccoyst http://codereview.appspot.com/4830051

Ignore scroll/noscroll window setting. Instead, scroll when the write begins in or immediately after the displayed window content. In the new scrolling discipline, executing "Noscroll" is replaced by typing Page Up or using the mouse to scroll higher in the buffer, and executing "Scroll" is replaced by typing End or using the mouse to scroll to the bottom of the buffer. R=r, r2 http://codereview.appspot.com/4433060

R=r http://codereview.appspot.com/583043

message http://codereview.appspot.com/123051