From Gerhard.Sittig@gmx.net  Sat Sep  9 17:47:14 2000
Return-Path: <Gerhard.Sittig@gmx.net>
Received: from mail.gmx.net (pop.gmx.net [194.221.183.20])
	by hub.freebsd.org (Postfix) with SMTP id 2330737B423
	for <FreeBSD-gnats-submit@freebsd.org>; 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 <Gerhard.Sittig@gmx.net>
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
Subject: [PATCH] inconsistency in scmouse vs xterm behaviour
References: <20000903211143.T252@speedy.gsinet>

>Number:         21156
>Category:       kern
>Synopsis:       [PATCH] inconsistency in scmouse vs xterm behaviour
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Sep 09 17:50:00 PDT 2000
>Closed-Date:    Sat Jul 30 01:12:53 GMT 2005
>Last-Modified:  Sat Jul 30 01:12:53 GMT 2005
>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:
Responsible-Changed-From-To: freebsd-bugs->yokota 
Responsible-Changed-By: johan 
Responsible-Changed-When: Sat Sep 16 05:15:00 PDT 2000 
Responsible-Changed-Why:  
Over to syscons maintainer. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=21156 

From: Gerhard Sittig <Gerhard.Sittig@gmx.net>
To: FreeBSD-gnats-submit@freebsd.org
Cc:  
Subject: Re: kern/21156: [PATCH] inconsistency in scmouse vs xterm behaviour
Date: Fri, 13 Oct 2000 20:28:15 +0200

 On Sat, Sep 09, 2000 at 17:50 -0700, gnats-admin@FreeBSD.org wrote:
 > 
 > >Category:       kern
 > >Responsible:    freebsd-bugs
 > >Synopsis:       [PATCH] inconsistency in scmouse vs xterm behaviour
 > >Arrival-Date:   Sat Sep 09 17:50:00 PDT 2000
 
 The PR was filed on Sep 9th and was assigned to the syscons
 maintainer on Sep 16th.  Since there was a patch included and a
 description which "misfeatures" it fixes, I expected to get some
 kind of feedback.  But I didn't get some (neither have there been
 f'ups to the PR nor have there been any via PM or Cc: to me when
 discussing this on one of the freebsd- lists).
 
 I would like to remind whomever is interested in the scmouse
 functionality of the syscons driver about this PR.  The previous
 silence could mean the patched bug was a non-issue.  Then I would
 like to hear about this (and have the PR assigned an according
 status).  Or it could have been that I missed some design goal
 and a copy and paste mechanism mangling data (and thus losing
 information) was meant to be like this but I just didn't know and
 considered it a bug.  Then I would be grateful for pointers to
 where I can learn more about it to not collide any further with
 the author's intentions.
 
 But definitely I would be most happy with the above patch (sent
 in the PR's opening message) being reviewed and considered for
 application since it will create a state more consistent with the
 most famous clipboard implementation as seen in xterm.  Differing
 behaviour of the same mechanism in different environments can be
 very annoying.
 
 Thank you for your kind attention!
 
 
 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.
 

From: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp>
To: Gerhard Sittig <Gerhard.Sittig@gmx.net>
Cc: FreeBSD-gnats-submit@freebsd.org,
	yokota@zodiac.mech.utsunomiya-u.ac.jp
Subject: Re: kern/21156: [PATCH] inconsistency in scmouse vs xterm behaviour 
Date: Sat, 14 Oct 2000 16:51:17 +0900

 >>Number:         21156
 >>Category:       kern
 >>Synopsis:       [PATCH] inconsistency in scmouse vs xterm behaviour
 >>Confidential:   no
 >>Severity:       non-critical
 [...]
 >>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.
 
 This is a bug.  Your submitted patch fixes this.
 
 >- Continued (wrapped) lines are broken up.
 
 Xterm determines whether adjacent lines are continued or not, by
 remembering where the new line char ('\n') was printed.
 
 Xterm does put a '\r' in the pasted text in the following situation.
 
 The text in the first line is exactly the width of the window and a
 '\n' char was printed at the end of the line.  Then, the second line
 of text is printed.  The two lines LOOK contiguous, but when you
 select these lines and paste them, the two lines are broken up,
 because of the '\n' char at the end of the first line.
 
 The xterm does NOT put a '\r' in the pasted text only if the two lines
 are really contiguous, that is, there was no '\n' in between.
 
 Syscons cannot do this because it does not remember when and where new
 line chars are printed.  So, when there is a non-space char at the
 right edge of the screen, syscons cannot determine the line is
 continuing or not.  We have to either 1) always assume the line is
 continuing, or 2) always assume the line is not continuing.
 
 The current version of syscons choose 2) ;-<
 
 Your submitted patch assumes 1).  I am happy to commit your patch
 to the source tree, but we should be aware that we still don't
 have full xterm-compatibility even after your patch.
 
 >- When copying a complete line (by triple clicking) all the
 >  spaces at the line's end get pasted, too.
 
 Ok, this should be fixed too.
 
 Your patch doesn't fix this, though. Right?
 
 I am going to commit your patch and the fix for the third problem
 this weekend.
 
 Kazu
 
 >>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.
 [...]
 
 >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. :)
 [...]
 
 We need a major surgery in order to implement this...
 
 
 
 
 
 
 
 

From: Gerhard Sittig <Gerhard.Sittig@gmx.net>
To: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/21156: [PATCH] inconsistency in scmouse vs xterm behaviour
Date: Sat, 14 Oct 2000 12:11:01 +0200

 On Sat, Oct 14, 2000 at 16:51 +0900, Kazutaka YOKOTA wrote:
 > >>Number:         21156
 > >>Category:       kern
 > >>Synopsis:       [PATCH] inconsistency in scmouse vs xterm behaviour
 > >>Confidential:   no
 > >>Severity:       non-critical
 > [...]
 > >
 > >>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.
 > 
 > This is a bug.  Your submitted patch fixes this.
 
 Yes.
 
 > >- Continued (wrapped) lines are broken up.
 > 
 > Xterm determines whether adjacent lines are continued or not,
 > by remembering where the new line char ('\n') was printed.
 
 Oh!  I was not aware of the effort xterm does to remember the
 printout stream that formed the display look.  This is IMO too
 much of resources dedicated to too small a gain when we talk
 about a kernel console driver instead of an application. :)
 
 > Syscons cannot do this because it does not remember when and
 > where new line chars are printed.  So, when there is a
 > non-space char at the right edge of the screen, syscons cannot
 > determine the line is continuing or not.  We have to either 1)
 > always assume the line is continuing, or 2) always assume the
 > line is not continuing.
 > 
 > The current version of syscons choose 2) ;-<
 > 
 > Your submitted patch assumes 1).  I am happy to commit your
 > patch to the source tree, but we should be aware that we still
 > don't have full xterm-compatibility even after your patch.
 
 Now that you cleared up my simple thinking of what goes behind
 the scenes I don't want "full xterm-compatibility" any longer. :)
 I feel assumption 2 is quite OK:  If these lines _look_
 contigous, they're *probably* wrapped.
 
 The way to improve this (change from assumption to knowledge) was
 to add one flag per syscons line and have it set when
 encountering a '\n' _after_ wrapping lines.  If an array of
 SC_HISTORY_SIZE ints plus the logic to set these is affordable
 this could get implemented, too.
 
 > >- When copying a complete line (by triple clicking) all the
 > >  spaces at the line's end get pasted, too.
 > 
 > Ok, this should be fixed too.
 > 
 > Your patch doesn't fix this, though. Right?
 
 I was not sure if "fixing" this wouldn't destroy another
 "feature".  I'm constantly annoyed by TeraTerm (a Windows telnet
 / ssh client / terminal program) already, not pasting the final
 \n for me when I mark multiple lines and not pasting selected(!)
 spaces.  I'm not sure if I should see this as a feature or a bug.
 Definitely there should be a switch for this, but we have to draw
 a line between customizability and bloat.
 
 Maybe differing between
 - trailing spaces marked when double-/triple-clicking (selecting
   words or lines) -- to be discarded, and
 - trailing spaces marked when single-clicking (selecting
   characterwise and including spaces wantonly(sp,id?)) -- not to
   be discarded
 would be most appropriate.
 
 > I am going to commit your patch and the fix for the third
 > problem this weekend.
 
 I guess those who want all the trailing spaces pasted will raise
 their hands. :)
 
 And I appreciate your attention and effort in reviewing,
 commenting and accepting my proposal.
 
 > >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.  [...]
 > 
 > We need a major surgery in order to implement this...
 
 That's what I'm at currently (hooking up into where the
 cut_mouse_* routines are called, I understand they're just
 executing the cut'n'paste operations and the calling syscons code
 will arrange to make the logic.
 
 But this is not related to this PR and has much lower priority.
 It's more of a comfort thing than of mangling clipboard
 operation.
 
 
 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.
 

From: Gerhard Sittig <Gerhard.Sittig@gmx.net>
To: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/21156: [PATCH] inconsistency in scmouse vs xterm behaviour
Date: Mon, 20 Nov 2000 20:32:40 +0100

 On Sat, Oct 14, 2000 at 16:51 +0900, Kazutaka YOKOTA wrote:
 > >
 > >>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:
 > >
 > > [ ... ]
 > 
 > This is a bug.  Your submitted patch fixes this.
 > 
 > [ ... ]
 > 
 > Your submitted patch assumes 1).  I am happy to commit your
 > patch to the source tree, but we should be aware that we still
 > don't have full xterm-compatibility even after your patch.
 > 
 > [ ... ]
 > 
 > I am going to commit your patch and the fix for the third
 > problem this weekend.
 
 Is there something missing from my part?  Should I do some more
 investigation or cleanup to the patch provided so far?
 
 In case you've "just been busy", I would like to bring this PR to
 your attention again. :)
 
 
 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.
 

From: Gerhard Sittig <Gerhard.Sittig@gmx.net>
To: FreeBSD-gnats-submit@freebsd.org
Cc:  
Subject: Re: kern/21156: [PATCH] inconsistency in scmouse vs xterm behaviour
Date: Tue, 19 Dec 2000 20:25:59 +0100

 On Mon, Nov 20, 2000 at 20:32 +0100, Gerhard Sittig wrote:
 > 
 > Is there something missing from my part?  Should I do some more
 > investigation or cleanup to the patch provided so far?
 
 Umm, on Oct 14th you decided to accept the patch after reviewing
 it.  But since then another two months of silence have passed and
 yet it wasn't committed.  If there's something missing from my
 side, *please* tell me so!
 
 
 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.
 

From: "Andrey A. Chernov" <ache@nagual.pp.ru>
To: freebsd-gnats-submit@FreeBSD.org, Gerhard.Sittig@gmx.net
Cc:  
Subject: Re: kern/21156: [PATCH] inconsistency in scmouse vs xterm behaviour
Date: Mon, 12 Mar 2001 04:32:19 +0300

 We  definitely  needs SC_HISTORY_SIZE byte array to track '\n' happens to
 make  it  really  working.  Who  is  willing  to implement this? Gerhard?
 Yokota?
 
 -- 
 Andrey A. Chernov
 http://ache.pp.ru/
 
 

From: "Andrey A. Chernov" <ache@nagual.pp.ru>
To: freebsd-gnats-submit@FreeBSD.org, Gerhard.Sittig@gmx.net
Cc:  
Subject: Re: kern/21156: [PATCH] inconsistency in scmouse vs xterm behaviour
Date: Tue, 13 Mar 2001 13:37:53 +0300

 I just commit "multiple empty lines as single one" fix into -current.
 
 -- 
 Andrey A. Chernov
 http://ache.pp.ru/
 
 

From: Gerhard Sittig <Gerhard.Sittig@gmx.net>
To: "Andrey A. Chernov" <ache@nagual.pp.ru>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/21156: [PATCH] inconsistency in scmouse vs xterm behaviour
Date: Tue, 13 Mar 2001 18:33:10 +0100

 On Mon, Mar 12, 2001 at 04:32 +0300, Andrey A. Chernov wrote:
 > 
 > We  definitely  needs SC_HISTORY_SIZE byte array to track '\n'
 > happens to make  it  really  working.  Who  is  willing  to
 > implement this? Gerhard?  Yokota?
 
 Well, I got sidetracked and did other things since last year.
 But I will have another look at this code (wasn't sure about how
 much of an issue arises from scrolling, but it looks doable to me
 after a quick glance).  In a previous message in this PR thread I
 said something along the lines of "If an array of SC_HISTORY_SIZE
 ints plus the logic to set these is affordable this could get
 implemented, too."  Let's see how expensive the extension will
 become ...
 
 Until then I feel my patch to be small and tested enough that it
 could get applied.  Squeezing data by a clipboard mechanism
 really is a bug, and I feel the assumption that parts looking
 contiguous are more probably contiguous than accidently(? by
 chance?) separated by a line break.  At least I've seen many more
 situations where inserting '\n' at wrapped lines does harm than
 being good.  Regarding the last item (trailing spaces) I'm still
 undecided whether snipping them is A Good Idea(TM), it's a pity
 we don't know about how selection started -- with single, double,
 or triple clicks.  And teaching syscons about it takes a lot of
 surgery I didn't get to, yet. :(
 
 
 yokota seems to be a very busy guy.  I haven't got any response
 since October (when he promised to commit the fix "next
 weekend"), but admittedly I only tried to reach him in late
 November, late December and one week ago.  Although I've seen him
 developing and committing, apparently he's concentrating on a
 different (more important I guess) corner of syscons.  We all
 know this is a volunteer project, no offence meant here.  But
 could this PR get assigned to somebody else, please?
 
 
 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.

From: Maxim Sobolev <sobomax@FreeBSD.org>
To: freebsd-gnats-submit@FreeBSD.org, Gerhard.Sittig@gmx.net
Cc:  
Subject: Re: kern/21156: [PATCH] inconsistency in scmouse vs xterm behaviour
Date: Mon, 26 Nov 2001 15:25:47 +0200

 Just FYI. I've recently committed a patch, which makes line selection
 mode less broken, i.e. it is no longer pads the line with useless
 spaces.
 
 -Maxim

From: Gerhard Sittig <Gerhard.Sittig@gmx.net>
To: freebsd-gnats-submit@FreeBSD.org
Cc: Maxim Sobolev <sobomax@FreeBSD.org>
Subject: Re: kern/21156: [PATCH] inconsistency in scmouse vs xterm behaviour
Date: Sun, 9 Dec 2001 16:23:24 +0100

 On Mon, Nov 26, 2001 at 15:25 +0200, Maxim Sobolev wrote:
 > 
 > Just FYI. I've recently committed a patch, which makes line selection
 > mode less broken, i.e. it is no longer pads the line with useless
 > spaces.
 
 I noticed two commits done by sobomax to the scmouse.c file:
 
   ----- 8< ----- snip ----- >8 ----- ----- 8< ----- snap ----- >8 -----
   [sittig@shell] (231) ~/FreeBSD-source/src-current $ cvs log -r1.27 -r1.28 sys/dev/syscons/scmouse.c 
   RCS file: /CVSREPO/FreeBSD/src/sys/dev/syscons/scmouse.c,v
   Working file: sys/dev/syscons/scmouse.c
   head: 1.28
     [ ... RCS head snipped ... ]
   ----------------------------
   revision 1.28
   date: 2001/11/25 22:51:30;  author: sobomax;  state: Exp;  lines: +5 -1
   Fix POLA - when selecting line into syscons' cut'n'paste buffer (double
   click) do not include newline into the buffer. This is exacly how
   things worked before my recent changes to the cut'n'paste code and
   how they work in 4-STABLE.
   ----------------------------
   revision 1.27
   date: 2001/09/21 20:39:25;  author: sobomax;  state: Exp;  lines: +92 -101
   Introduce new syscons(4) kernel options:
   - SC_CUT_SPACES2TABS - when copying text into the cut buffer convert leading
     spaces into the tabs;
   - SC_CUT_SEPCHARS="XYZ" - treat supplied characters as possible words
     separators when the driver searches for words boundaries when doing cut
     operation.
 
   Also unify cut code a bit to decrease amount of duplicated code. This fixes
   line cut mode, so that it is no longer pads line with useless spaces.
   ----- 8< ----- snip ----- >8 ----- ----- 8< ----- snap ----- >8 -----
 
 
 Fetching a -CURRENT iso image from the Japanese snapthots server
 ("FreeBSD 5.0-CURRENT-20011204-JPSNAP #0: Mon Dec  3 22:41:03 GMT 2001
 root@ushi.jp.freebsd.org:/usr/src/sys/i386/compile/BOOTMFS" -- many
 thanks for this build service!) allowed me to run a quick test.  From
 the sysinstall menu I chose the "fixit" option and inserted the
 live-current.iso to issue the following commands:
 
   # moused -p /dev/psm0 -m 2=3 (a notebook with only two buttons)
   # vidcontrol -m on
   # cat > /dev/null            (followed by typing and pasting ...)
 
 To cite from my original PR opening:
 
 > >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.
 
 The first issue was attacked and is solved.  Empty lines are copied
 into the clipboard and get pasted correctly.
 
 The second issue is still open:  typing long sentences while having
 lines wrap "by chance" at the screen's edge will make scmouse paste
 a line break in the middle of the wrapped word.
 
 The third issue -- although not attacked by the patch I proposed
 initially -- was resolved in a very well suited way.  Thank you
 Maxim!  When trailing spaces are selected by will(id?) through
 dragging a single click selection, they're copied and pasted.  When
 trailing spaces are selected by triple clicking a line, they're
 left out.  This seems to best fit users' expectations by obeying
 explicit wishes while trimming auto selected trailing whitespaces.
 
 
 Since I don't have a -CURRENT machine around and am unable to build
 a -CURRENT system myself without causing unrelated and unnecessary
 fuzz and since these two revs haven's been MFCed yet, I only have
 the unchecked (untested with current code) idea that the
 
         /* 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';
 
 change from my PR opening patch will resolve the second issue
 (non wanted insertion of line breaks in words which are "merely
 wrapped" at the screen edge).  At least this change worked some
 year ago. :)  This context is in the mouse_do_cut() function in
 scmouse.c's rev 1.28.
 
 This change admittedly doesn't *know* if there has been a line
 break, either.  But the new assumption apparently fits reality
 better.  What's the probability for writing text up exactly to
 the screen's edge and then issuing a newline?  By far the most
 cases with non space characters at the screen edge come from the
 same word which got (visually) wrapped.
 
 
 Should this one line change (avoid line breaks at wrapped only
 words) work and these three revisions get MFCed then the PR can
 be closed.
 
 
 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.
State-Changed-From-To: open->feedback 
State-Changed-By: linimon 
State-Changed-When: Thu Aug 26 03:33:42 GMT 2004 
State-Changed-Why:  
Is this still a problem with modern versions of FreeBSD? 


Responsible-Changed-From-To: yokota->freebsd-bugs 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Thu Aug 26 03:33:42 GMT 2004 
Responsible-Changed-Why:  
With bugmeister hat on, reassign from inactive committer. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=21156 
State-Changed-From-To: feedback->closed 
State-Changed-By: kris 
State-Changed-When: Sat Jul 30 01:12:40 GMT 2005 
State-Changed-Why:  
Feedback timeout 

http://www.freebsd.org/cgi/query-pr.cgi?pr=21156 
>Unformatted:
