From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu From: "Douglas A. Gwyn" Message-ID: <3B093634.CDBFDDE3@null.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <150144503394.20010519085440@proweb.co.uk>, <200105191707.KAA00509@tammananny.tiger> Subject: Re: [9fans] home, end ^h^j^k^l Date: Mon, 21 May 2001 16:23:59 +0000 Topicbox-Message-UUID: a45def14-eac9-11e9-9e20-41e7f4b1d025 Quinn Dunkan wrote: > Deleting text with backspace replaces the snarf buffer. I often cut out > something I want, and then do some editing to prepare a place for it, and wind > up deleting a space or something, at which point my paste doesn't give what I > expected. I don't think the snarf buffer should be quite so ephemeral, but it > probably also has something to do with how I work (i.e., if I want to snarf > something, I snarf, and if I want to delete it, I delete). It's not just you; I keep running into this problem using "sam". Partly it's coupled to the behavior of backspace for a highlighted region: to exactly delete what is highlighted, one has to cut it, which overwrites the snarf buffer. I would actually prefer an array of snarf buffers (a la TECO's Q-registers), but then the complexity starts to overwhelm the user. I doubt it is possible to design a *small* interface that best fits all usage patterns.