Tue 19 Sep 2017 06:14:01 PM UTC, comment #17:
And pushed http://hg.savannah.gnu.org/hgweb/octave/rev/8a6747c6db1a
|
Tue 19 Sep 2017 05:42:43 PM UTC, comment #16:
It should be
|
Tue 19 Sep 2017 05:25:56 PM UTC, comment #15:
BTW is this (simple) fix amenable for pushing on stable as well?
|
Tue 19 Sep 2017 05:25:23 PM UTC, comment #14:
Fix works fine for me.
I see you've pushed it.
Closing report.
|
Tue 19 Sep 2017 11:51:57 AM UTC, comment #13:
Pushed http://hg.savannah.gnu.org/hgweb/octave/rev/f7710116bf7d
|
Mon 18 Sep 2017 11:08:33 PM UTC, comment #12:
Windows uses a completely different 'terminal' in Octave than any of the linux flavors, so it wasnt any supprize that it appears only in Windows.
As to why it appears in Win10 and not others - I do not know
|
Mon 18 Sep 2017 10:01:05 PM UTC, comment #11:
OP here.
Thank you to John Donoghue for diagnosing and fixing the problem! Very non-intuitive cause -- thank you for the effort you spent.
Out of curiosity: why was the null buffer only a problem on Windows 10 and not on Debian, or (presumably) older versions of Windows? Shouldn't all of them have stopped reading at the first null character?
|
Mon 18 Sep 2017 03:11:29 PM UTC, comment #10:
Patch attached
(file #41828)
|
Sun 17 Sep 2017 10:37:59 PM UTC, comment #9:
ok - I made some changes to a test version of octave to save to file the content of the raw grabbed data of the console.
Whats happenign seems to be be, that initially the unused space in the window is filled with spaces, but after the clc, unused space is now null bytes instead.
I'll make a patch that will handle that
|
Sat 16 Sep 2017 08:29:02 PM UTC, comment #8:
Confirmed here as well (on Win10) with a --enable-windows-64 Octave-4.3.0+ cross-build from last week.
Release => dev
|
Fri 15 Sep 2017 09:04:19 PM UTC, comment #7:
Yes.
COpy/paste works as expected for me normally, but if If do clc, then ls, and try to copt/paste some of its output, only the first line is pasted.
Does same thing on dev octave and 4.2.1 (both 64 bit) and 4.2.0 (32 bit)
|
Fri 15 Sep 2017 04:14:11 PM UTC, comment #6:
John or Philip - are you able to reproduce this after calling 'clc' as OP mentions?
|
Thu 14 Sep 2017 04:46:52 PM UTC, comment #5:
Add-on info from original poster.
Can copy-paste from the opening screen (copyright notice etc). Cannot copy-paste once clc has been invoked.
|
Thu 14 Sep 2017 03:35:10 PM UTC, comment #4:
Curious. My Windows version is: Windows 10 Home, version 1703, OS Build 15063.608.
FWIW, I've had this computer for 14 months but have always had that Octave copy-paste discrepancy in GUI with older versions of Octave too. I didn't use the GUI much until now, so it may be some Windows edge case.
|
Thu 14 Sep 2017 10:19:41 AM UTC, comment #3:
Potentially the same as Bug #50843?
What version number of Windows 10 ?
|
Wed 13 Sep 2017 08:10:02 PM UTC, comment #2:
Windows 10 Home, 64-bit.
|
Wed 13 Sep 2017 07:57:02 PM UTC, comment #1:
Which Windows version, 32 or 6 bit?
|
Wed 13 Sep 2017 07:04:54 PM UTC, original submission:
Open Octave CLI in Windows, highlight a part of the command window and copy (usually Enter works instead of Ctrl-C). Open Notepad and paste it. It behaves as expected.
Try the same thing with Octave GUI in Windows. Highlight, right-click and Copy. Then paste in Notepad. Only the first line gets pasted. Everything after the first line-break is discarded. Same problem in Wordpad, gedit for Windows etc.
This problem does not happen on Debian. Can copy-paste between command window (CLI or GUI) and text editor.
Probably a line-break / carriage return problem in GUI?
|