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

 
 

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

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

Add a New Comment (Rich Markup)
   

You are not logged in

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

 

( Jump to the original submission)

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>
Project Member
Wed 03 Mar 2021 05:51:00 PM UTC, comment #35: 

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

Philip Nienhuis <philipnienhuis>
Project 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>
Project 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>
Project 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>
Project Member
Fri 26 Feb 2021 07:42:19 PM UTC, comment #31: 

Thx, building now

Philip Nienhuis <philipnienhuis>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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>
Project Member
Fri 26 Feb 2021 11:14:17 AM UTC, comment #24: 

On Linux the patch works.

Philip Nienhuis <philipnienhuis>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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>
Project Member
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>
Project 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>
Project 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>
Project Member
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>
Project 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>
Project 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>
Project 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>
Project Member
Fri 19 Feb 2021 11:01:39 PM UTC, comment #10: 

Oops, wrong pic. Attempt #2


Philip Nienhuis <philipnienhuis>
Project 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>
Project 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>
Project Member
Fri 19 Feb 2021 10:03:57 PM UTC, comment #7: 

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

Philip Nienhuis <philipnienhuis>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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 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)
  •  

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

    Only project members can vote.

     

     

     

    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    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.6