bugGNU Octave - Bugs: bug #60079, (Windows) Ctrl-C / Ctrl-V...

 
 

bug #60079: (Windows) Ctrl-C / Ctrl-V dysfunctional in Command Window

Submitter:  Philip Nienhuis <philipnienhuis>
Submitted:  Fri 19 Feb 2021 11:26:43 AM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  None
Originator Name:  Philip Nienhuis Open/Closed:  * Closed
Release:  * dev Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 06 Dec 2021 03:18:38 PM UTC, comment #44: 

http://hg.savannah.gnu.org/hgweb/octave/rev/60a4fcf2d51b changed the default behavior of that preference to off, precluding the need for most the comment #43 message.  A simplified NEWS item covering the change is pushed to stable as
https://hg.savannah.gnu.org/hgweb/octave/rev/e9b5838722fc

Nicholas Jankowski <nrjank>
Group Member
Fri 03 Dec 2021 08:39:40 PM UTC, comment #43: 

@ttl looked at the changeset and suggests that copy/paste were exceptions in the paste on all platforms, not just windows.  so the news item should maybe read something like:


The preference “Disable global shortcuts when Command Window has focus” is
now consistently applied and is enabled by default. This option disables
keyboard shortcuts like Ctrl-C/V for Copy/Paste, Ctrl-N for creating a new
editor document, Ctrl-Q for quitting Octave, etc, to avoid interference with
readline key strokes in the Command Window. Ctrl-C/V were unaffected by this
setting prior to version 7 of Octave, but are now disabled by default. They
can be enabled by de-selecting the preference under the Edit/Preferences
menu and Shortcuts tab.


Nicholas Jankowski <nrjank>
Group Member
Fri 03 Dec 2021 02:58:53 PM UTC, comment #42: 

sorry, to clarify - wondering if someone could verify that the text is correct and this only applied to earlier versions of Windows.

Nicholas Jankowski <nrjank>
Group Member
Fri 03 Dec 2021 02:44:16 PM UTC, comment #41: 

the fixed setting now applies by default to disable keyboard copy/paste along with other shortcuts. Confirmed after some checking in old octave versions (see https://octave.discourse.group/t/octave-v7-default-disable-global-shortcuts-setting-for-keyboard-copy-paste-impact ) that whether deliberate or not this is a default UI behavior change going back to at least octave 4 on Windows (it seems even when the setting worked properly in v4 and 5, copy paste was maybe separately excluded?) Recommend adding a note to the GUI section of news to at least document the change in behavior, something like the following (although maybe it's too verbose):


The preference “Disable global shortcuts when Command Window has focus” is
now consistently applied under all Operating Systems and is enabled by
default. This option disables keyboard shortcuts like Ctrl-C/V for
Copy/Paste, Ctrl-N for creating a new editor document, Ctrl-Q for quitting
Octave, etc, to avoid interference with readline key strokes in the Command
Window. Ctrl-C/V were unaffected by this setting prior to version 7 of Octave
for Windows, but are now disabled by default. They can be enabled by
de-selecting the preference under the Edit/Preferences menu and Shortcuts
tab.


could someone verify whether this was in fact just as windows exception prior to v6?

Nicholas Jankowski <nrjank>
Group Member
Fri 28 May 2021 08:01:07 PM UTC, comment #40: 

Works fine, thanks very much.
Remarkable that such a small fix was all that is needed.

I see no other remaining issues here, so I'll close this report.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 28 May 2021 02:02:47 PM UTC, comment #39: 

Yes, the change I pushed should be all that is needed.

John W. Eaton <jwe>
Group administrator
Fri 28 May 2021 01:31:47 PM UTC, comment #38: 

Am I right assuming that this new patch replaces the one from comment #27?

Philip Nienhuis <philipnienhuis>
Group Member
Fri 28 May 2021 03:54:03 AM UTC, comment #37: 

The following changeset seems to fix the interrupt problem for me:

http://hg.savannah.gnu.org/hgweb/octave/rev/97e12df28ee6

I thought gnulib provided a kill function that accepts pid and signal arguments but it does not and kill is not available on Windows systems.  So if kill is not available, we just use raise instead to trigger the signal handler.  As it was, nothing was happening when calling kill, so Octave never received the interrupt signal that we were trying to send.

John W. Eaton <jwe>
Group administrator
Wed 03 Mar 2021 05:51:19 PM UTC, comment #36: 

The current sources don't work correctly on Windows. jwe pinpointed to specific changes that might have introduced the issue. Philip confirmed that reverting those changes fixes the issue for him. But there is currently no definitive solution.

Changing status to "in progress".

Markus Mützel <mmuetzel>
Group administrator
Wed 03 Mar 2021 05:51:00 PM UTC, comment #35: 

Was the patch pushed? AFAICR I applied a patch manually.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 03 Mar 2021 05:45:15 PM UTC, comment #34: 

Is this okay to close?  Bug is marked "Ready for Test", and comment #32 from Philip says it works.  But it may be that there are interrupt patches that still need to be applied.

Rik <rik5>
Group administrator
Fri 26 Feb 2021 09:27:29 PM UTC, comment #33: 

But rereading comment #27 if I understand correctly other problems get to be unsolved ...

Philip Nienhuis <philipnienhuis>
Group Member
Fri 26 Feb 2021 09:25:20 PM UTC, comment #32: 

@JWE:
The patch from #27 fixes it completely for me.
It was the last bit to make all context menu options and preferences work as intuitively expected.



Philip Nienhuis <philipnienhuis>
Group Member
Fri 26 Feb 2021 07:42:19 PM UTC, comment #31: 

Thx, building now

Philip Nienhuis <philipnienhuis>
Group Member
Fri 26 Feb 2021 06:58:27 PM UTC, comment #30: 

I will also look into my recent changeset

- http://hg.savannah.gnu.org/hgweb/octave/rev/ca1cc1bca9cb

if I missed something that only has impact on Windows.

Torsten Lilge <ttl>
Group Member
Fri 26 Feb 2021 03:58:15 PM UTC, comment #29: 

Philip: Yes, I fixed up the changes so you should be able to apply to ca1cc1bca9cb without conflicts.

John W. Eaton <jwe>
Group administrator
Fri 26 Feb 2021 03:48:38 PM UTC, comment #28: 

Sure, this weekend or maybe sooner.
AFAICS a quick glance shows the csets you mention don't interfere with Torsten's latest cset ca1cc1bca9cb pushed 2 days ago; right?

As I wrote in the OP it started several weeks ago. The "5 weeks ago" mentioned in the log for the referenced csets seems to match this observation.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 26 Feb 2021 03:32:06 PM UTC, comment #27: 

Could you please try the attached patch and see whether it fixes the problem with interrupts?  These changes are the equivalent of backing out the following changesets:

http://hg.savannah.gnu.org/hgweb/octave/rev/b73ddb964093
http://hg.savannah.gnu.org/hgweb/octave/rev/eb1e10abe9d5
http://hg.savannah.gnu.org/hgweb/octave/rev/0231189f630d

These are recent changes I made to interrupt handling, but I don't know why they would cause it to stop working on Windows systems.  So if backing out these changes does fix the problem, then I guess we'll have to try to understand why.

Otherwise, maybe bisecting would find the changeset where interrupts stopped working?

(file #50928)

John W. Eaton <jwe>
Group administrator
Fri 26 Feb 2021 03:19:58 PM UTC, comment #26: 

Thanks Markus for confirmation.
Just to be sure, in the CLI it all works; it's strictly a GUI issue.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 26 Feb 2021 02:58:01 PM UTC, comment #25: 

I also build for Windows after that change.

Ctrl+C doesn't interrupt `pause(10)` for me independent of the setting of "Disable global shortcut ...", too.

It also doesn't abort a command that wasn't finished independent of that setting.

Markus Mützel <mmuetzel>
Group administrator
Fri 26 Feb 2021 11:14:17 AM UTC, comment #24: 

On Linux the patch works.

Philip Nienhuis <philipnienhuis>
Group Member
Thu 25 Feb 2021 09:47:49 PM UTC, comment #23: 

I tried to interrupt:

  • pause(10)
  • a stray command (just rubbish) I typed (w/o pressing Enter) to try to return to the prompt.

None worked.
Pic of settings attached.

I didn't try on Linux, just on Windows.


Philip Nienhuis <philipnienhuis>
Group Member
Thu 25 Feb 2021 05:46:04 PM UTC, comment #22: 

I think the Qt version should not have any impact to this problem. I was building the default branch for testing with 5.13. Which preferences are you currently using ("disabling global shortcuts" and shortcut for copying) and what did you try to interrupt?

Torsten Lilge <ttl>
Group Member
Thu 25 Feb 2021 05:33:31 PM UTC, comment #21: 

Doesn't work for me on Windows (= no interrupting of commands).

That said, in my mxe-octave build tree Qt is at 5.14.2 due to bug #59426, maybe that interferes?

Philip Nienhuis <philipnienhuis>
Group Member
Wed 24 Feb 2021 08:52:16 PM UTC, comment #20: 

Cset http://hg.savannah.gnu.org/hgweb/octave/rev/ca1cc1bca9cb fixes the issue for me on Linux.

Torsten Lilge <ttl>
Group Member
Sun 21 Feb 2021 06:05:59 PM UTC, comment #19: 

In dev Octave on my Linux box, disabling global shortcuts when the command window has focus also disables interrupting commands with Ctrl-c.

So this (Crtl-c no more interrupting commands) actually looks like a regression.
The other issue, that the setting has no effect in the 6.x branch (and possibly before) has silently been "fixed"; I'd agree to leave it as-is for the stable branch, as about nobody seems to have noticed it.

BTW I didn't even try interrupting e.g., a 'pause(10)' but rather entered rubbish w/o pressing Enter, and then pressed Ctrl-c. If Octave ignores the input and returns to the prompt I'd call it "interrupting commands".
It is that scenario (not being able to simply ignore commands that were accidentally input by e.g., arrow up and inadvertent editing etc.) that is most annoying to me. There may be a readline command but most Windows users would be ignorant of that.

Philip Nienhuis <philipnienhuis>
Group Member
Sun 21 Feb 2021 04:07:58 PM UTC, comment #18: 

I tried interrupting `pause(10)` using Cltr+C. That didn't work for me independent of the setting of "Disable global shortcut ..." with a build from the default branch.
Ctrl+C interrupts the pause independent of that setting with Octave 6.1.90.

Markus Mützel <mmuetzel>
Group administrator
Sun 21 Feb 2021 04:03:20 PM UTC, comment #17: 

@Markus:
Thanks for also investigating.

@Torsten:
Yes I think you've summarized it correctly, thanks.

I didn't check Linux thoroughly, IIRC it mostly worked there incl. interrupting commands. Tonight I'll check again, if I find s/th deviating from your summary I'll report back.

On Windows the dysfunctional Ctrl-c interrupt option was the most annoying for me. As I usually work with bleeding edge Octave I'm not immediately upset if something doesn't work. I'm usually confident it'll get fixed in due time, but in this occasion I got the impression that few if any other users had noted and/or the issue was with my own crossbuilds.

Philip Nienhuis <philipnienhuis>
Group Member
Sun 21 Feb 2021 01:25:10 PM UTC, comment #16: 

Thanks for testing; I try to summarize:

Comment #15 seems to describe the expected behavior for the default branch. Is Ctrl-C working for interrupting the interpreter regardless the setting "Disable global shortcuts ..."?

Comment #14: Also expected behavior for the default branch but ignoring the "Disable global shortcut ..." preference in the stable branch. Interrupting the interpreter with Ctrl-C does not work in 7.0.0.

I had a look into the sources and indeed, the handling of the "Disable ..." pref has changed: Now really all global shortcuts including copy and paste are disabled when the command window has focus and the pref is set. However, I can confirm that  Ctrl-C does not interrupt the interpreter on my Debian system.

I suggest to leave the stable branch as it is (ignoring the "Disable global shortcuts ..." pref for copy and paste) since this probably was the behavior for a long time. In summary, Ctrl-C not interrupting the interpreter anymore in the default branch is the remaining issue? If you agree, I update the title of this report.

Torsten Lilge <ttl>
Group Member
Sun 21 Feb 2021 10:44:44 AM UTC, comment #15: 

Ctrl+C doesn't work for me either on Windows 10 with hg id 6c2fa2293242 if "Disable global shortcuts when Command Window has focus" in the Shortcuts preferences is checked.
It is working if that option is un-checked.

The "Copy" options in the right-click menu in the command window and in the main "Edit" menu are working in either case.

The right aligned "Ctrl+C" is appearing in the main "Edit" menu if the above option is un-checked (and the shortcut is working). It is not appearing if that option is checked (and the shortcut does not work).

All of this is with the focus in the "Command Window". The behavior is different if the focus is in another widget (e.g. the "Editor").

Markus Mützel <mmuetzel>
Group administrator
Sat 20 Feb 2021 11:37:24 PM UTC, comment #14: 

Unsetting "Disable global shortcuts when Command window has focus" makes copy/paste work, and then the shortcuts also appear in the main menu's Edit submenu.
But Ctrl-C to interrupt a command still doesn't work.

In a 6.1.1 nightly from Feb 5 it works differently: Ctrl-v and Ctrl-c work in the terminal for copy/paste regardless of whether "Disable global shortcuts when Command window has focus" is set or not; same for the shortcuts being mentioned in the main menu's edit submenu.
Interrupting commands with ctrl-c always works there.

It looks like the shortcuts setting works better in 7.0.0 in that they are mentioned and work in the main menu if "Disable global ..." is unset, while in 6.1.1 it seems to have no influence.
Unfortunately interrupting commands fell victim in 7.0.0.

IMO it would be nice if someone could confirm all this. I have the feeling it might be a local issue, but I can't put a finger on it.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 20 Feb 2021 11:18:54 PM UTC, comment #13: 

.. but on linux (Mageia-7.1) it's different (see atached)


Philip Nienhuis <philipnienhuis>
Group Member
Sat 20 Feb 2021 11:11:01 PM UTC, comment #12: 

Sorry Torsten, I should have read better.
Yes they're there, see attached pic.



Philip Nienhuis <philipnienhuis>
Group Member
Sat 20 Feb 2021 07:37:14 PM UTC, comment #11: 

Sorry Philip to be not clear enough. In my last comment #8 I was referring to the "real" menu "Edit" of the main widnow where you can also find "Copy" and "Paste" entries. Do they show the related shortcuts of these actions?

Torsten Lilge <ttl>
Group Member
Fri 19 Feb 2021 11:01:39 PM UTC, comment #10: 

Oops, wrong pic. Attempt #2


Philip Nienhuis <philipnienhuis>
Group Member
Fri 19 Feb 2021 10:59:45 PM UTC, comment #9: 

You mean the context menu as in the attached pic?


Philip Nienhuis <philipnienhuis>
Group Member
Fri 19 Feb 2021 10:34:50 PM UTC, comment #8: 

At least on linux, the context menu does not show the shortcuts related to the menu entries (why?), so I expect this is the case in windows, too. But what about the "Edit" menu of the main window? Are you the Ctrl-C/Ctrl-V shortcuts  displayed for the related entries?

Torsten Lilge <ttl>
Group Member
Fri 19 Feb 2021 10:03:57 PM UTC, comment #7: 

Well, correction, sorry: "Clear window" does not work.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 19 Feb 2021 10:02:26 PM UTC, comment #6: 

Ah ... (stupid me), yes all the commands in there work, in fact that's the way I have been using dev Octave the last weeks.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 19 Feb 2021 09:45:51 PM UTC, comment #5: 

With the context menu I mean the menu that appears when you right click into the command window.

Torsten Lilge <ttl>
Group Member
Fri 19 Feb 2021 09:27:47 PM UTC, comment #4: 


> Are the related entries in the context menu of the terminal active or disabled?

Not sure what you mean. I have "Set focus to...." set, but not "Print debug ....".

In addition:

> If Ctrl-V and Ctrl-C work in 6.1.1 than these are the configured shortcuts and should also work in 7.0.0.

Exactly.
In 6.1.1. and 7.0.0 all prefs are exactly the same, AFAICS.

Ctr-Shift-c & Ctrl-Shift-v don't work either in 7.0.0 for copy/paste or interrupting.
It's just the command window. In the GUI editor Ctrl-c & Ctrl-v work fine.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 19 Feb 2021 07:15:54 PM UTC, comment #3: 

In Reply to comment #1:
If Ctrl-V and Ctrl-C work in 6.1.1 than these are the configured shortcuts and should also work in 7.0.0.

Torsten Lilge <ttl>
Group Member
Fri 19 Feb 2021 07:08:20 PM UTC, comment #2: 

Are the related entries in the context menu of the terminal active or disabled?

Is it really safe to have the same settings file across different releases?

I would say yes. The ini file is not executed like a script, but the single preferences are requested by the gui. New preferences in newer versions are just ignored (not requested) by older versions. We currently have only one or two prefs that have changed between versions but that are checked accordingly when being read in new versions.

Torsten Lilge <ttl>
Group Member
Fri 19 Feb 2021 07:06:56 PM UTC, comment #1: 

Does Ctrl-Shift-V work better to paste? What about Ctrl-Shift-C to copy?

Anonymous
Fri 19 Feb 2021 11:26:43 AM UTC, original submission:  

Since a few weeks, Ctrl-C and Ctrl-V don't work anymore for me in the command pane, neither for interrupting commands nor for copy/paste.
Flipping the "Disable global shortcuts when Command Window has focus" setting makes no difference.

(just FTR, works consistently fine in a recent 6.1.1 nightly on the same box)

(another FTR: 6.1.1 and 7.0.0 seem to share the exact same octave-gui.ini file; any settings change in 7.0.0 is reflected verbatim in 6.1.1 when inspecting settings. Is it really safe to have the same settings file across different releases?)

Philip Nienhuis <philipnienhuis>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #50928:  interrupt-diffs.txt added by jwe (10KiB - text/plain)
file #50926:  bug60079#B.png added by philipnienhuis (14KiB - image/png)
file #50892:  bug60079-2.png added by philipnienhuis (23KiB - image/png)
file #50890:  bug60079.png added by philipnienhuis (15KiB - image/png)
file #50889:  bug_60076.png added by philipnienhuis (39KiB - image/png)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jwe (Updated the item)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by philipnienhuis (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 13 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-05-28 philipnienhuis StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2021-05-28 jwe StatusIn Progress Ready For Test
    2021-03-06 ttl Dependencies- bugs #60182 is dependent
    2021-03-03 mmuetzel StatusReady For Test In Progress
    2021-02-26 jwe Attached File- Added interrupt-diffs.txt, #50928
    2021-02-25 philipnienhuis Attached File- Added bug60079#B.png, #50926
    2021-02-24 ttl StatusConfirmed Ready For Test
    2021-02-21 mmuetzel StatusNone Confirmed
    2021-02-20 philipnienhuis Attached File- Added bug60079_linux.png, #50893
    2021-02-20 philipnienhuis Attached File- Added bug60079-2.png, #50892
    2021-02-19 philipnienhuis Attached File- Added bug60079.png, #50890
    2021-02-19 philipnienhuis Attached File- Added bug_60076.png, #50889

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code