Date: Wed, 26 Jun 1996 08:07:01 -0700 (PDT) From: "Eric J. Schwertfeger" <ejs@bfd.com> To: sos@FreeBSD.ORG Cc: FreeBSD current <current@FreeBSD.ORG> Subject: Re: RFC: cut&paste funtionality... Message-ID: <Pine.BSI.3.94.960626080200.25544B-100000@harlie.bfd.com> In-Reply-To: <199606261425.QAA29111@ra.dkuug.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 26 Jun 1996 sos@FreeBSD.ORG wrote: > > So, I'm left with a little problem about how to handle the marked > text when new output goes to the screen, possibly messing up > the marked area or moving it around. There is 3 possible > solutions to this: > > 1. Catch all updates and change the marking to comply > > 2. Remove the marking on all updates. > > 3. Only show the marked text when actually doing the > cut action, remove as soon as the mousebutton is > released. > > Now, 1 above is almost impossible, so unless we will accept > a MAJOR slowdown on screen updates, this is not really an > option. 2 above is possible (thats the route I've started) > but it generates quite alot of code. 3 is easy and does > not cost anything... > > So comments are VERY welcome... I don't like 3 because I tend to move the mouse when I let go of the button, and the only reason I notice this under X is because it leaves the area highlighted. 2 also keeps xterm behavior, which I like (for consistency, not because I think it's the best way to do it). In fact, I was disappointed when gpm became the standard under linux, because selection was mostly xterm-mouse software compatible, so I had text editors that I could use the mouse on the console or in an xterm without having to change a thing. sigh :-) Sometimes I do miss a linux kludge or two (not that the entire OS is a kludge, but the development model supports kludges becoming standard).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.94.960626080200.25544B-100000>