Bug 21156
| Summary: | [PATCH] inconsistency in scmouse vs xterm behaviour | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Gerhard Sittig <Gerhard.Sittig> |
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.1-STABLE | ||
| Hardware: | Any | ||
| OS: | Any | ||
Responsible Changed From-To: freebsd-bugs->yokota Over to syscons maintainer. 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. >>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... 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. 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. 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. 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/ I just commit "multiple empty lines as single one" fix into -current. -- Andrey A. Chernov http://ache.pp.ru/ 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. 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 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 Is this still a problem with modern versions of FreeBSD? Responsible Changed From-To: yokota->freebsd-bugs With bugmeister hat on, reassign from inactive committer. State Changed From-To: feedback->closed Feedback timeout |
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. 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. 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. :)