Thu 20 Jul 2017 08:55:47 PM UTC, comment #6:
As a temporary (ugly) work around, since I found that many system(...) calls are at the root of disabling color at the command line, and that system('') re-enables it, I added the following to my path:
I also call system('') at startup.
I am guessing there is a less ugly workaround if the octave source itself is edited, but I haven't had time yet to try and look at, edit and compile octave source yet (since I've heard compiling can take hours).
|
Mon 17 Jul 2017 06:18:22 PM UTC, comment #5:
It looks like Matlab's command window does support ANSI color modes, so Octave should (continue to) as well.
Hopefully, a future version of Octave will have a command window that can reliably support scrollback and selection and ANSI colors and hyperlinks in a cross-platform way. But for now I suspect the Windows command window is what it is. If there is something simple that Octave can do as it is now to allow colors to be supported more reliably, we're happy to accept patches.
So I think the best solution to this is to have a completely new command window, which is a known future improvement project idea.
|
Wed 28 Jun 2017 01:33:46 AM UTC, comment #4:
I traced the known causes of disabling of color in the console back to system(...) calls.
1) xlsread() disables color when system('unzip ...') called in unpack().
2) The random fact that some errors disable color and some don't can be traced as far as I can tell to errors due to improper function call usage, which trigger print_usage() calls which I trace down to color being disabled after system('makinfo ...') in _makeinfo_().
This means system(...) calls both enable or disable ANSI escape character interpretation depending on what is run by the system() command.
Another odd behavior I noticed is that the ANSI coloring can persist after ANSI escape codes are no longer interpreted.
In the above the red coloring triggered by the escape sequence persists even though the second set isn't recognized.
|
Tue 20 Jun 2017 04:37:29 PM UTC, comment #3:
I'm glad to see work is happening (or happened) on this. From looking at the comments on the patch, it supports what I've learned that Windows didn't used to support ANSI escape sequences at all. Windows 10 just recently began to support ANSI escape sequences, so now color can show up. I tested on my Win7 machine and it wouldn't show color even with the use of any of the tricks that I mentioned below.
I had looked into what enables color in Windows this last week and found that supposedly color is enabled by a specific SetConsoleMode call that switches it on or off. I believe the system("") calls turn color on because processes run by octave, such as the system call (or the output pager) turns that switch on, and something in octave, perhaps errors, switches it off. It seems that it should be easy to make sure the switch is set to on at octave startup and isn't turned off by error calls.
I would really like to see red errors, and other colored output in the windows terminal, which doesn't happen at all right now. Now you know windows 10 can support it, maybe you can enable color for Win 10 (or have an option so a user can enable it)?
|
Tue 20 Jun 2017 08:15:53 AM UTC, comment #2:
See also patch #9024
The least that can be said is that the Octave terminal in Windows has some deficiencies :-)
I tend to close this as a duplicate of that patch #9024 but I'll leave it to the other devs.
|
Tue 20 Jun 2017 12:37:04 AM UTC, comment #1:
I found another problem: Now that I can always enable color at the command prompt, I found that at least in one case, color will get disabled: If I call a function incorrectly, (e.g "test" with no argument) then after the usage is displayed, then color has been disabled.
|
Mon 19 Jun 2017 11:10:44 PM UTC, original submission:
I'm using Windows 10, and haven't tested this on Win7 yet. I found a bug that's been bothering me for a while where I happily discovered I could show things in color on the commnad prompt in the gui using the techniques of https://www.gnu.org/software/octave/doc/interpreter/Customizing-the-Prompt.html,
But later no coloring would work. I thought some windows update must have been the culprit or maybe it was because I recently changed from a windows 7 to windows 10 machine, but couldn't get color to work when I went back and tested it on a different windows 7 machine. Finally, today color accidentally appeared on the command line due to output of a system() call, so I knew color WAS working after all, tried the above command, and it worked again. After restarting octave, color was gone again. I narrowed it down so I can reliably get color to be enabled by calling certain functions in octave, but color is never enabled at startup. The following things enable color: calling any system() command, a print() command (don't know if all print calls do it, because I traced it down to a non-documented form of a call to drawnow() ), and any output that uses the pager (e.g. dir(), path(), and long output to the command window: calling more off before color is enabled will disable any of the long output from enabling color.
Color should be enabled at octave startup, rather than randomly after some other function enables color at the command window inside of it.
|