> | I still believe the chording code that's ifdef'ed out of the > | plan9port version can be made to work. > > is there any particular senerio that causes a problem; i'd be > willing to take a stab at this.
rob just played with it for a while and got it to break. of course, the current code doesn't behave exactly as acme's anyway, and it should. > i know you've mentioned protocol jam but i can't picture how > the protocol events would be different between b1+b2 and > menu→cut. clearly, i'm missing something. that's why i think it can be made to work. i see the same thing. > | > 4) The unshared snarf buffer issue is gone. > | > | Again the sam die-hards will disagree with you on this one. > > i would like to unshare the buffer; but i'm not intersted > in offending. perhaps this could be switched either via > command line or menu option. (ya, i know. don't kill me > for the menu option idea.) surprisingly this is easier in x than in plan 9. the bad part about sharing the snarf buffer with x is that if you're running sam -r over a long-distance connection, then if you snarf some big piece just to paste in another sam buffer, there's no reason to pull it all the way across the connection just to send it back up. x's snarf model accomodates this, though that makes it much harder to deal with in the easy cases. > | I'm not sure I want to know what this really means, but > | "simple Athena/XTerm" sure sounds like an oxymoron to me. > > uh, i really don't think that you need to be this radical. i've got > some code that allows 9term to scroll-select. they're based on > basically the same "struct Text", so i think it's doable. i'm sure scrolling during select is doable and fine. "simple Athena/XTerm" was the scary part. russ
