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


bug #39305: copy/paste not consistent or intuitive

Submitted by:  John Donoghue <lostbard>
Submitted on:  Thu Jun 20 23:50:03 2013  
Category: GUISeverity: 3 - Normal
Priority: 5 - NormalItem Group: Other
Status: FixedAssigned to: None
Originator Name: John DonoghueOpen/Closed: Closed
Release: devOperating System: Any

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


(Jump to the original submission Jump to the original submission)

Wed Aug 14 16:47:12 2013, comment #39:

I pushed the changeset here:


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>
Project Administrator
Wed Aug 14 16:11:29 2013, comment #38:

Looks good to me

John Donoghue <lostbard>
Project Member
Wed Aug 14 15:44:10 2013, 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>
Project Administrator
Wed Aug 14 13:22:17 2013, 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>
Project Member
Wed Aug 14 13:13:24 2013, comment #35:

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

John W. Eaton <jwe>
Project Administrator
Tue Aug 13 23:33:47 2013, comment #34:

An initial attempt at using keyPressEvent rather than winEvent.

(file #28836)

John Donoghue <lostbard>
Project Member
Tue Aug 13 19:58:57 2013, 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>
Project Administrator
Tue Aug 13 19:14:56 2013, 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>
Project Member
Tue Aug 13 18:57:22 2013, comment #31:

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

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

John W. Eaton <jwe>
Project Administrator
Tue Aug 13 18:42:13 2013, comment #30:

I think the patch is okay:

is only false for CTRL+C and true otherwise.

Torsten <ttl>
Project Member
Tue Aug 13 18:14:59 2013, comment #29:

I don't understand the intent of

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>
Project Administrator
Tue Aug 13 16:17:14 2013, 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>
Project Member
Mon Aug 12 22:21:17 2013, comment #27:

Pushed http://hg.savannah.gnu.org/hgweb/octave/rev/f95bb8763f4e

John Donoghue <lostbard>
Project Member
Mon Aug 12 18:30:49 2013, comment #26:

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

John Donoghue <lostbard>
Project Member
Mon Aug 12 18:25:01 2013, comment #25:

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

Torsten <ttl>
Project Member
Sun Aug 11 04:05:16 2013, comment #24:

How about this .. (attached)

(file #28808)

John Donoghue <lostbard>
Project Member
Sat Aug 10 07:58:43 2013, 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 <ttl>
Project Member
Mon Aug 5 19:18:58 2013, 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 ?? ()

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

John Donoghue <lostbard>
Project Member
Mon Aug 5 19:06:31 2013, comment #21:

Try this, which seems to work for me.

(file #28766)

John Donoghue <lostbard>
Project Member
Sat Aug 3 20:21:17 2013, 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 <ttl>
Project Member
Fri Aug 2 19:31:46 2013, 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>
Project Administrator
Thu Aug 1 16:30:28 2013, 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 <ttl>
Project Member
Wed Jul 31 20:24:52 2013, 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>
Project Administrator
Wed Jul 31 13:00:51 2013, 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>
Project Administrator
Wed Jul 31 12:54:14 2013, 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>
Project Administrator
Wed Jul 31 10:31:53 2013, comment #14:

On my mingw build for Ctrl-C, running:

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

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>
Project Member
Wed Jul 31 05:17:22 2013, 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 <ttl>
Project Member
Wed Jul 31 02:23:23 2013, 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>
Project Administrator
Wed Jul 31 01:12:01 2013, 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>
Project Member
Tue Jul 30 23:51:45 2013, comment #10:

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

Mike Miller <mtmiller>
Project Administrator
Tue Jul 30 20:21:18 2013, 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 <ttl>
Project Member
Tue Jul 30 10:35:30 2013, 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>
Project Member
Tue Jul 30 06:02:29 2013, 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:

Mike Miller <mtmiller>
Project Administrator
Tue Jul 30 05:07:54 2013, 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 <ttl>
Project Member
Mon Jul 29 20:32:52 2013, 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.

>> sleep(60)

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

John Donoghue <lostbard>
Project Member
Mon Jul 29 19:40:51 2013, 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 <ttl>
Project Member
Sun Jul 28 19:52:04 2013, 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>
Project Administrator
Mon Jul 1 01:40:13 2013, 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>
Project Member
Fri Jun 21 10:30:17 2013, 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>
Project Member
Thu Jun 20 23:50:03 2013, 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>
Project Member


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

Attach File(s):

Attached Files
file #28841:  octave-1-keypress.patch added by jwe (3kB - text/x-diff)
file #28836:  keypress.patch added by lostbard (4kB - application/octet-stream)
file #28808:  ctrl_c_qt.patch added by lostbard (1kB - 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 (4kB - text/x-diff)
file #28699:  ctrl_v.diff added by ttl (4kB - text/x-diff)


Depends on the following items: None found

Items that depend on this one: None found


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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 11 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed Aug 14 16:47:12 2013jweStatusIn Progress=>Fixed
    Wed Aug 14 15:44:10 2013jweAttached File-=>Added octave-1-keypress.patch, #28841
    Tue Aug 13 23:33:47 2013lostbardAttached File-=>Added keypress.patch, #28836
    Sun Aug 11 04:05:16 2013lostbardAttached File-=>Added ctrl_c_qt.patch, #28808
      Summarycopy/paste not consitent or intuitive=>copy/paste not consistent or intuitive
    Mon Aug 5 19:06:31 2013lostbardAttached File-=>Added ctrl_c_fix.patch, #28766
    Tue Jul 30 20:21:18 2013ttlAttached File-=>Added ctrl_v_02.diff, #28713
    Tue Jul 30 06:02:29 2013mtmillerItem GroupNone=>Other
      StatusNone=>In Progress
    Mon Jul 29 19:40:51 2013ttlAttached File-=>Added ctrl_v.diff, #28699

    Back to the top

    Powered by Savane 3.1-cleanup