From owner-freebsd-bugs Sat Sep 9 17:50: 9 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id CEDBA37B423 for ; Sat, 9 Sep 2000 17:50:00 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id RAA55405; Sat, 9 Sep 2000 17:50:00 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id 2330737B423 for ; Sat, 9 Sep 2000 17:47:13 -0700 (PDT) Received: (qmail 4714 invoked by uid 0); 10 Sep 2000 00:47:11 -0000 Received: from p3ee2163a.dip.t-dialin.net (HELO speedy.gsinet) (62.226.22.58) by mail.gmx.net with SMTP; 10 Sep 2000 00:47:11 -0000 Received: (from sittig@localhost) by speedy.gsinet (8.8.8/8.8.8) id CAA18714 for FreeBSD-gnats-submit@freebsd.org; Sun, 10 Sep 2000 02:46:05 +0200 Message-Id: <20000910024605.R252@speedy.gsinet> Date: Sun, 10 Sep 2000 02:46:05 +0200 From: Gerhard Sittig To: FreeBSD-gnats-submit@freebsd.org In-Reply-To: <20000903211143.T252@speedy.gsinet>; from Gerhard.Sittig@gmx.net on Sun, Sep 03, 2000 at 09:11:43PM +0200 References: <20000903211143.T252@speedy.gsinet> Subject: kern/21156: [PATCH] inconsistency in scmouse vs xterm behaviour Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21156 >Category: kern >Synopsis: [PATCH] inconsistency in scmouse vs xterm behaviour >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Sep 09 17:50:00 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Gerhard Sittig >Release: FreeBSD 4.1-STABLE i386 >Organization: in private >Environment: FreeBSD 4.1-STABLE i386 >Description: FreeBSD's sysmouse feature (mouse copy'n'paste for text console) is different in behaviour from xterm (the "original", I guess) and Linux consoles (another prominent implementation) in the following respect: - When copying multiple lines empty lines are silently left out. - Continued (wrapped) lines are broken up. - When copying a complete line (by triple clicking) all the spaces at the line's end get pasted, too. >How-To-Repeat: Copy any shell script between a viewer and an editor via scmouse, The code might still be the same, but it's less readable. Copy some diff(1) -u or similar output and feed the result into patch(1), chances are the missing empty line will break the context recognition. Copy a word which is wrapped around the screen's margin. This is impossible to do via scmouse. Use scmouse for "repeating" long command lines (w/o employing the shell's history feature which I know to be in existence -- this scenario is just an example for the "need" to copy wrapped lines) and it gets even worse: The inserted newline will send incomplete commands! So you end up selecting some text up to close before the lines wrap and type the missing parts. I've been bitten by this several times. Especially when transferring code snippets or reports between separate machines by means of the mouse clipboard it's annoying. And since xterm seemed to be the inspiration scmouse should be changed to show the same behaviour. Otherwise switching between text mode and X sessions will make users angry due to permanent annoyance. :> The trailing spaces when copying complete single lines are just a minor annoyance. Fixing these would break copying spaces only as well as copying text and some additional spaces, unless the logic is extended to tell these two situations apart (spaces only, letters and spaces). What I would *love* to see is the chance to start selecting with a double or triple click and to _continue_ selecting wordwise or linewise by _dragging_ the mouse. Extending selection by button3 clicks is not a viable alternative on notebooks. :( And neither does it take into consideration whether selection was initially done for whole words or lines. The latter aspect is not dealt with by this patch. It would mean to keep more than just a "we're selecting" bit but instead have a state "we're selecting whole characters, whole words, or whole lines". Then selection would start by any click (actually a button1 down) in character mode, could be switched to other modes with more clicks (1down shortly after the previous up) and no motion yet, and any motion (above a certail epsilon) would extend until button1 release / the up event. Extension by downing button2 would be an additional feature for those lucky enough to have a (usable) third button. :) >Fix: ----------------------------------------------------------------- --- scmouse.c 2000/09/09 23:46:47 1.1 +++ scmouse.c 2000/09/09 23:56:59 @@ -336,14 +336,15 @@ to = start - 1; } for (p = from, i = blank = 0; p <= to; ++p) { - cut_buffer[i] = sc_vtb_getc(&scp->vtb, p); + cut_buffer[i++] = c = sc_vtb_getc(&scp->vtb, p); /* remember the position of the last non-space char */ - if (!IS_SPACE_CHAR(cut_buffer[i++])) + if (!IS_SPACE_CHAR(c)) blank = i; /* the first space after the last non-space */ /* trim trailing blank when crossing lines */ - if ((p % scp->xsize) == (scp->xsize - 1)) { + if (((p % scp->xsize) == (scp->xsize - 1)) && (IS_SPACE_CHAR(c))) { cut_buffer[blank] = '\r'; - i = blank + 1; + blank++; + i = blank; } } cut_buffer[i] = '\0'; ----------------------------------------------------------------- Storing the current character in c is just for my own sake (wouldn't like to struggle against the fact when the index is incremented and when it's not yet:). Checking for spaces at the screen edge before breaking lines will keep wrapped words together. Pointing blank to the space after the one which just got replaced by carriage return will keep empty lines intact. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message