bugGNU Octave - Bugs: bug #39305, copy/paste not consistent or...

 
 

bug #39305: copy/paste not consistent or intuitive

Submitter:  John Donoghue <lostbard>
Submitted:  Thu 20 Jun 2013 11:50:03 PM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  Fixed Assigned to:  None
Originator Name:  John Donoghue Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 14 Aug 2013 04:47:12 PM UTC, comment #39: 

I pushed the changeset here:

http://hg.savannah.gnu.org/hgweb/octave/rev/0b2a0acd0315

Now I see a difference with C-v in the Unix and Windows terminals, but that should probably be a different bug report.

John W. Eaton <jwe>
Group administrator
Wed 14 Aug 2013 04:11:29 PM UTC, comment #38: 

Looks good to me

John Donoghue <lostbard>
Group Member
Wed 14 Aug 2013 03:44:10 PM UTC, comment #37: 

Looking at it some more, it seems somewhat complex with all the conversions between byte arrays and strings.  Is all that conversion necessary?  Also, can we use a switch on the key sequences?  How about the attached changeset instead?  It seems to work for me.  If you agree that this is OK, I'll push it.


(file #28841)

John W. Eaton <jwe>
Group administrator
Wed 14 Aug 2013 01:22:17 PM UTC, comment #36: 

No reason except I didn't want to check it in until I had tested it some more, which I have now done.
I will check it in tonight when I have access to my r/w version of the code, unless someone else wants to check it in before then.

John Donoghue <lostbard>
Group Member
Wed 14 Aug 2013 01:13:24 PM UTC, comment #35: 

This seems to work for me.  Is there any reason not to check it in?

John W. Eaton <jwe>
Group administrator
Tue 13 Aug 2013 11:33:47 PM UTC, comment #34: 

An initial attempt at using keyPressEvent rather than winEvent.


(file #28836)

John Donoghue <lostbard>
Group Member
Tue 13 Aug 2013 07:58:57 PM UTC, comment #33: 

Yes, if I understand correctly that means that Qt is in control of all keyboard input and passes something else on to Octave (readline)?  If so, that seems like a better and more reliable way to handle input.

John W. Eaton <jwe>
Group administrator
Tue 13 Aug 2013 07:14:56 PM UTC, comment #32: 


My guess is that when doing a ctrl-V, which then passes the clipboard to the console, that the ctrl key is still pressed so potentially all characters then sent to the console are with the ctrl key pressed?

I just did an initial play around with removing the winEvent processing the keyPressEvent instead.

Would it make more sense to use it instead - keys such as the cursor keys etc would then need be encoded into escape code strings, and passed on, but the unix terminal code is doing that already.


John Donoghue <lostbard>
Group Member
Tue 13 Aug 2013 06:57:22 PM UTC, comment #31: 

Hmm, well, maybe it would be clearer if instead of using a double negative it was


GetKeyState ('C') && GetKeyState (VK_CONTROL)


But anyway, what causes the problem with not responding unless CTRL is pressed?

John W. Eaton <jwe>
Group administrator
Tue 13 Aug 2013 06:42:13 PM UTC, comment #30: 

I think the patch is okay:


(NOT 'C') OR (NOT CTRL)


is only false for CTRL+C and true otherwise.

Torsten Lilge <ttl>
Group Member
Tue 13 Aug 2013 06:14:59 PM UTC, comment #29: 

I don't understand the intent of


GetKeyState ('C') == 0 || GetKeyState (VK_CONTROL) == 0


in the patch.  That looks like it is checking for a 'C' key or a 'Control' key, not both combined.  Should this have used something other than the short-circuit logical '||' operator?

John W. Eaton <jwe>
Group administrator
Tue 13 Aug 2013 04:17:14 PM UTC, comment #28: 

Another issue I am seeing - probably occurring from change f95bb8763f4e, if anyone else can confirm they are seeing the same issue:

On using ctrl-v to paste a line to the terminal (that I think contains a 'c' - but haven't 100% verified), it will then sometimes then will not respond to pressing other keys until the ctrl key is pressed.

John Donoghue <lostbard>
Group Member
Mon 12 Aug 2013 10:21:17 PM UTC, comment #27: 
John Donoghue <lostbard>
Group Member
Mon 12 Aug 2013 06:30:49 PM UTC, comment #26: 

I will push the change later today if no one has any issues.

John Donoghue <lostbard>
Group Member
Mon 12 Aug 2013 06:25:01 PM UTC, comment #25: 

Yes, works for me.
No more crashes and no more interrupts when copying selected text.

Torsten Lilge <ttl>
Group Member
Sun 11 Aug 2013 04:05:16 AM UTC, comment #24: 

How about this .. (attached)

(file #28808)

John Donoghue <lostbard>
Group Member
Sat 10 Aug 2013 07:58:43 AM UTC, comment #23: 

I can confirm the issue with John's patch.

Is it possible to recognize "ctrl-c" in the WM_KEYUP, WM_KEYDOWN messages and prevent calling PostMessage in this cases?


Torsten Lilge <ttl>
Group Member
Mon 05 Aug 2013 07:18:58 PM UTC, comment #22: 

hmm ... found an issue with it.

Ctrl-C, V appear to work in regards to copy and paste all the time that the should.

Ctrl-C appears to exit from scripts/function etc after the next function call.

Ctrl-C (and something not selected to copy) when not running a script/function sometimes terminates the whole program.

Running with -g option:

Program received signal SIGINT, Interrupt.
[Switching to Thread 4580.0x13c4]
0x75196da7 in NlsUpdateSystemLocale () from C:\Windows\syswow64\kernel32.dll
(gdb) where
#0  0x75196da7 in NlsUpdateSystemLocale ()
   from C:\Windows\syswow64\kernel32.dll
#1  0x4d5bcd6a in ?? ()
#2  0x00000000 in ?? ()
(gdb)

However, at other times pressing ctrl-c when not running a function, this doesn't occur.




John Donoghue <lostbard>
Group Member
Mon 05 Aug 2013 07:06:31 PM UTC, comment #21: 

Try this, which seems to work for me.


(file #28766)

John Donoghue <lostbard>
Group Member
Sat 03 Aug 2013 08:21:17 PM UTC, comment #20: 

To summarize:
From the 2nd issue of comment #19 and the 1st of #18 can we conclude that, in addition to the copyClipboard slot of the main window, there is a second path for C-c to raise an interrupt?
So the questions are: Where is this path and what disables the slot copyClipboard in main window before C-c is used in another dock widget?

Torsten Lilge <ttl>
Group Member
Fri 02 Aug 2013 07:31:46 PM UTC, comment #19: 

OK, I see that the behavior is different after using C-c and C-v in another widget.  But for me it is still not correct.  I see two different behaviors depending on the precise sequence of events.  Both are wrong in different ways:

1. Start Octave and select a file name in the file browser widget, then type C-c followed by C-v.  Next, change the focus to the terminal widget and type C-v.  The file name is inserted at the Octave prompt.  So far, that's expected behavior.  Next, type C-c and Octave exits.  That's not expected, so it looks like the interrupt signal is not being delivered properly.

2. Start Octave and select a file name in the file browser widget, then type C-v followed by C-v.  Next, chnage the focus to the terminal widget and select some text.  Type C-c.  A new prompt is printed, indicating that the text was copied and and interrupt signal has been sent to the Octave process.  At this point, I was just expecting the text to be copied.  Next, type C-v and the text that was selected from the terminal window is inserted at the Octave prompt.  So it seems that C-c performed both copy and interrupt at the same time when I was expecting just one action.

John W. Eaton <jwe>
Group administrator
Thu 01 Aug 2013 04:30:28 PM UTC, comment #18: 

A test in Windows has shown the following:

1. Directly after the startup of octave C-c does not copy and C-v does not paste. C-c aborts the actual input line (a new prompt appears) even when there is selected text. The slots connected to the copy/paste-actions of the main window are not entered.

2. When the focus is changed into another widget and back into the terminal, C-c and C-v still don't work.

3. When the focus is changed into another widget and C-c (or C-v) is used there (e.g. in the editor without open tab), then  C-c or (C-v) work as expected in the terminal.

It seems that the windows terminal catches C-c and C-v until these shortcuts are used in another dock widget.

Torsten Lilge <ttl>
Group Member
Wed 31 Jul 2013 08:24:52 PM UTC, comment #17: 

What I see with the current sources (hg id is 47b504503a3f) on Windows is that C-c always interrupts and never copies text to the clipboard and C-v always behaves as the readline quote character and never copies text from the clipboard.

Do other people see different behavior on Windows systems?

Remember, the code that provides the terminal is completely different on Windows and Unix systems.  So checking the behavior on a Unix system is not sufficient to know what will happen on Windows.

Again, what I think is happening is that on Windows systems, the terminal widget works by giving input to the Windows console directly, so the Qt code that handles keyboard shortcuts never sees the keyboard input.  If I'm right about this, then I don't see how we can possibly get the behavior we want with this design and we need to arrange for Qt to get the input first, and then pass it on to readline.  I think that's the way the Unix code works, by using a pty (see the sendKeyEvent function in the Unix terminal files).

Can we use a similar approach with Windows, so that Qt responds to all key press events and then passes them to the Octave thread?  That way, Qt shortcuts should work.  But maybe it's not possible on Windows since we don't have a proper pty implementation?

John W. Eaton <jwe>
Group administrator
Wed 31 Jul 2013 01:00:51 PM UTC, comment #16: 

Sorry, I meant to say based on the contents of the clipboard (for Ctrl-V) and whether any text is currently selected (for Ctrl-C).

Mike Miller <mtmiller>
Group Member
Wed 31 Jul 2013 12:54:14 PM UTC, comment #15: 

Yes, let's keep the discussion about whether the interrupt from Ctrl-C breaks out of loops, long operations, or system calls to bug #37672, there are more details there.

AFAICT, Torsten's second patch fully fixes the context switching between copy/paste and readline in the terminal widget based on the contents of the clipboard.

I'm not sure about the spurious ^V reported in comment #11, but I can't test on Windows. I was getting spurious ^V with the first version of the patch, but the second one fixed that.

Mike Miller <mtmiller>
Group Member
Wed 31 Jul 2013 10:31:53 AM UTC, comment #14: 

On my mingw build for Ctrl-C, running:

for i = [1:10]
 printf("x=%d\r\n", i);
 sleep(3);
endfor

Ctrl-C will stop the program without running the whole loop - it appears to do the stop after the sleep call.

If you get impatient and press Ctrl-C more than once whilst it is in the sleep call it will display "Press Control-C again to abort."
Pressing ctrl-C again will kill octave.

John Donoghue <lostbard>
Group Member
Wed 31 Jul 2013 05:17:22 AM UTC, comment #13: 

When the clipboard is empty, the paste action is disabled and C-v is used by readline. With a non empty clipboard, the paste action is enabled and C-v works as paste shortcut (I don't know why this does not work 100% of time for John).

C-c works copies text and raises SIGINT with no text selected. But this does not break a sleep() for example as discussed in bug #37672.

Torsten Lilge <ttl>
Group Member
Wed 31 Jul 2013 02:23:23 AM UTC, comment #12: 

Is the problem that keyboard input in the Windows terminal widget is grabbed by readline instead of always being handled first by the GUI widget?  I'm surprised that C-v ever works.  Does C-c now work to copy the selection to the clipboard (when text is selected)?  Does it also generate an interrupt when there is no text selected?

John W. Eaton <jwe>
Group administrator
Wed 31 Jul 2013 01:12:01 AM UTC, comment #11: 

In windows:

1) Started octave in gui mode.
Selected clear clipboard to verify clipboard is empty -> both paste and clear clipboard options are ghosted afterwards. (expected)

2) Close and restart octave -> both paste and clear menus are ghosted. (expected)

3) Selected text within console(command window) and used Ctrl-C -> paste and clear menus now not ghosted.
Press ctrl-V -> selected text pasted into console window (expected, however not 100% of time see 6))

selected clear clipboard menu and closed octave.

4) Restarted octave, and did Ctrl-V in console -> nothing happens. Press ctrl V again and ^V displayed. (expected)

selected clear clipboard menu and closed octave.

5) Restarted octave, selected text from file browser text edit and Ctrl-C -> paste and clear menu not ghosted (expected)

6) Ctrl-V in console -> displays ^V (unexpected, but doesn't happen 100% of the time (and isn't limited to browser text edit, it can also occur when copy from console or any of the other windows)

Paste into other windows functions normally, as does paste using the menu itself.




John Donoghue <lostbard>
Group Member
Tue 30 Jul 2013 11:51:45 PM UTC, comment #10: 

This updated patch works perfectly for me, solves all issues with respect to Ctrl-V.

Mike Miller <mtmiller>
Group Member
Tue 30 Jul 2013 08:21:18 PM UTC, comment #9: 

I have attached a new version of the patch which should fix the remaining issues for Ctrl-V (I have no possibility to test on windows at the moment).
Disabling the Copy-action is still not addressed.

(file #28713)

Torsten Lilge <ttl>
Group Member
Tue 30 Jul 2013 10:35:30 AM UTC, comment #8: 

The clear clipboard menu appears to work, and the paste menu and clear clipboard option are disabled after selecting clearing the clipboard.

Ctrl-V working as the clipboard paste never seems to work in the command window, even when I try the same steps as Mike.

If I focus in an edit window, or the editor and press Ctrl-V - it works for that window as the paste.




John Donoghue <lostbard>
Group Member
Tue 30 Jul 2013 06:02:29 AM UTC, comment #7: 

It works for me if I read my ~/.inputrc after starting Octave. Octave installs its own inputrc file that is read on startup, which disables the Ctrl-V readline binding. That's a separate issue.

Ctrl-V does now pass through to the terminal when the clipboard is empty with this patch, but there's some interaction with window focus as well or something else I'm not understanding. For example, starting with an empty clipboard:


octave:1> readline_read_init_file ("~/.inputrc");
octave:2> ^V^V ## typed Ctrl-V four times
## now select a word and copy with Ctrl-C
octave:2> ^V^V ## Ctrl-V is still self-inserting here
## now switch focus out of Octave and back to Octave
octave:2> learn ## Ctrl-V pastes the word now


Mike Miller <mtmiller>
Group Member
Tue 30 Jul 2013 05:07:54 AM UTC, comment #6: 

Using Ctrl-V (or Ctrl-Q) for displaying the following key value does not work for me in ubuntu (neither in the gui nor in the cli version).

So even if the clipboard is empty the "Paste" and the "Clear Clipboard" menus are still enabled?

Yes, the "Copy" menu still has to be disabled when there are no selections (not included in this patch), and the missing ability of Ctrl-C to abort the actual command is discussed in bug #37672.

Torsten Lilge <ttl>
Group Member
Mon 29 Jul 2013 08:32:52 PM UTC, comment #5: 

In windows (mingw), ctrl-v typed into the GUI command window and then pressing another key displays that key value.
<Ctrl-V pressed and then left cursor> displays \340K

It seems to do that no matter if I have something in the clipboard or not: I can paste from the menu, and the content will be pasted.

Using the copy menu sends an actual ctrl-c to the command window if nothing was selected in the terminal, and a a command is running.
Ex:

>> sleep(60)

<Ctrl-C pressed>  Press Ctrl-C again to abort
<Ctrl-C pressed>  <GUI terminates>

John Donoghue <lostbard>
Group Member
Mon 29 Jul 2013 07:40:51 PM UTC, comment #4: 

Attached a patch that should fix issue 2. and 3. reported by Mike. I have also added a menu entry for clearing the clipboard in order to easily get accces to the ctrl-v readline functionality.

But to be honest, I do not see any effect when using ctrl-v with an empty clipboard after applying the patch. Since I have no experience in using the readline interface I would be happy if someone could test this.

(file #28699)

Torsten Lilge <ttl>
Group Member
Sun 28 Jul 2013 07:52:04 PM UTC, comment #3: 

Here are a couple more observations related to this:

1. If no text is selected, Ctrl-C does indeed cancel the current line. However, the menu item Edit->Copy is still clickable and also cancels the current line (not the right-click context menu Copy).

2. Same thing with Edit->Paste, it is active and clickable but does nothing when the clipboard is cleared.

3. Is it possible to allow the Ctrl-V to be passed through to readline when the clipboard is empty? This is normally connected to the "quoted-insert" readline function.

Mike Miller <mtmiller>
Group Member
Mon 01 Jul 2013 01:40:13 AM UTC, comment #2: 

Changeset http://hg.savannah.gnu.org/hgweb/octave/rev/944ade6e7f66 makes the main window copy/paste work on the focused window/control.

John Donoghue <lostbard>
Group Member
Fri 21 Jun 2013 10:30:17 AM UTC, comment #1: 

Added changeset http://hg.savannah.gnu.org/hgweb/octave/rev/1d1f02e0f6b4 which makes the content menu for terminal window look at the clipboard to see whether it should enable copy/paste.

John Donoghue <lostbard>
Group Member
Thu 20 Jun 2013 11:50:03 PM UTC, original submission:  

A number of copy/paste issues, all probally related, some probaly mentioned before:

  • The copy/paste menu of the main window is really copy/paste of the terminal window.


  • The key shortcuts for copy and paste appear only work when not focused in the terminal window (Windows version)


  • terminal window copy/paste content menu always awailable even if nothing is available to copy/paste. (Same with main window copy/paste)



John Donoghue <lostbard>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #28841:  octave-1-keypress.patch added by jwe (3KiB - text/x-diff)
file #28836:  keypress.patch added by lostbard (4KiB - application/octet-stream)
file #28808:  ctrl_c_qt.patch added by lostbard (1KiB - application/octet-stream)
file #28766:  ctrl_c_fix.patch added by lostbard (1010B - application/octet-stream)
file #28713:  ctrl_v_02.diff added by ttl (4KiB - text/x-diff)
file #28699:  ctrl_v.diff added by ttl (4KiB - text/x-diff)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by ttl (Updated the item)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by lostbard (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-08-14 jwe StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2013-08-14 jwe Attached File- Added octave-1-keypress.patch, #28841
    2013-08-13 lostbard Attached File- Added keypress.patch, #28836
    2013-08-11 lostbard Attached File- Added ctrl_c_qt.patch, #28808
        Summarycopy/paste not consitent or intuitive copy/paste not consistent or intuitive
    2013-08-05 lostbard Attached File- Added ctrl_c_fix.patch, #28766
    2013-07-30 ttl Attached File- Added ctrl_v_02.diff, #28713
    2013-07-30 mtmiller Item GroupNone Other
        StatusNone In Progress
    2013-07-29 ttl Attached File- Added ctrl_v.diff, #28699

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code