I pushed the patch here:
https://hg.savannah.gnu.org/hgweb/octave/rev/1152256be2cf

Already marked as ready for test.

@Markus, I think both versions of comment #30 are readable.  Errors should remain an exception, thus hopefully not too many users will have to read these kinds of error messages on a regular basis.

If you think the patch of comment #30 is useful, please apply it and close this report.  When it reveals as ugly or unreadable, new bug reports will deal with it.

This was marked Ready for Test back in February.  Can it be closed now?

The CMD window win windows only shows 16 colors colors for me.
Looking at CHAR_INFO attributes field, it only uses 4 bits for forground and 4 for background color

By 16 colors that is 16 color indexes at any given time, not that there are only 16 discrete colors you ever choose.

The color map currently used in libqterminal/win32/QTerminalColors.cpp appears to match the default colors CMD, which are build around the black backround

Please, see the attached patch for the described change and screenshots from before and after the patch.

(file #48463,

if we're changing the default color scheme, are the controls (either gui or command) documented for setting/reverting the colors? is it OS dependent? (I know some interpreter behaviors are platform specific?)

Updated patch, that also makes the background a little more consistant when colors change



(file #48461)

Rather than disabling colors, how about changing the color used ? See attached patch.


(file #48439)

I see that color 7 is the general reset color index, (which in our terminal is light gray).

We set it to be different colors using SetConsoleTextAttribute, which I bet the color reset is then also resetting.

John, can you provide a cset for comment #19?  When I patch octave.vbs like this:

If GUI_MODE = 1 then
  AllArgs = AllArgs & " " & chr(34) & "--gui" & chr(34)
  wshSystemEnv("GCC_COLORS") = "error=00:warning=00:note=00:range1=00:range2=00:locus=00:quote=00:fixit-insert=00:fixit-delete=00:diff-filename=00:diff-hunk=00:diff-delete=00:diff-insert=00"
  wshShell.Run chr(34) & OctavePath & "\bin\octave-gui.exe" & Chr(34) & AllArgs, 0
Else
  wshShell.Run chr(34) & OctavePath & "\bin\octave-gui.exe" & Chr(34) & AllArgs, 1
End If

and revert my cset

https://hg.savannah.gnu.org/hgweb/octave/rev/eb46a9f47164

my text still fades to gray.

Thank you for the hint Mike

diff -r 75a90bfc14b1 scripts/pkg/private/configure_make.m
--- a/scripts/pkg/private/configure_make.m        Fri Jan 31 10:45:13 2020 -0800
+++ b/scripts/pkg/private/configure_make.m        Mon Feb 17 15:36:39 2020 +0900
@@ -57,6 +57,12 @@ function configure_make (desc, packdir,
     cenv = {"MKOCTFILE"; mkoctfile_program;
             "OCTAVE_CONFIG"; octave_config_program;
             "OCTAVE"; octave_binary};
+    if (ispc () && isguirunning ())
+      ## FIXME: Remove this branch when the MS Windows GUI terminal widget can
+      ##        properly handle colors (bug #57658).
+      cenv = [cenv; {"CXXFLAGS";
+                     ["-fdiagnostics-color=never " getenv("CXXFLAGS")]}];
+    endif
     scenv = sprintf ("%s='%s' ", cenv{:});

     ## Configure.

I was also fine with the restart solution Mike ;-)  I do not often install packages, but I am no pkg developer...

pkg is indeed sneaking around Octave's convenience wrapper by calling make directly.

https://hg.savannah.gnu.org/hgweb/octave/file/eb46a9f47164/scripts/pkg/private/configure_make.m#l94

Unless there are more spots like this in Octave, I propose the following additional patch:

diff -r 75a90bfc14b1 scripts/pkg/private/configure_make.m
--- a/scripts/pkg/private/configure_make.m        Fri Jan 31 10:45:13 2020 -0800
+++ b/scripts/pkg/private/configure_make.m        Mon Feb 17 14:29:37 2020 +0900
@@ -57,6 +57,11 @@ function configure_make (desc, packdir,
     cenv = {"MKOCTFILE"; mkoctfile_program;
             "OCTAVE_CONFIG"; octave_config_program;
             "OCTAVE"; octave_binary};
+    if (ispc () && isguirunning ())
+      ## FIXME: Remove this branch when the MS Windows GUI terminal widget can
+      ##        properly handle colors (bug #57658).
+      cenv = [cenv; {"CXXFLAGS"; "-fdiagnostics-color=never"}];
+    endif
     scenv = sprintf ("%s='%s' ", cenv{:});

     ## Configure.

It works at least on my MS Win 10 VM.

We stay on m-code.  Anyone can easily test gcc colors by removing the code.

On mkoctfile.cc level we have no change to detect if a running GUI called the program.  Thus the decision has to be made to forbid colors in MS Windows entirely.  This I find a pity, since in the terminal they look great.

Unfortunately for Octave 5.2.0 it is too late but for Octave 6 it can get in easily.

I pushed the following hotfix to stable for Octave 5.2.0:

https://hg.savannah.gnu.org/hgweb/octave/rev/eb46a9f47164

This way we can easily try out if the MS Windows GUI terminal colors are working, just by editing an m-file.

The patch regards the idea of Markus (comment #7) to only avoid colors in the GUI terminal.  In the CLI the colors are indeed very nice.

I rename this item and mark it "dev" problem.

BTW, there was an attempt several years back to have colored text in the terminal, e.g., red for errors (can't find it now, IIRC Lachlan worked on it). That attempt stranded because -of all places- in Windows the patch didn't work. It was s/th with ANSI sequences IIRC.
But apparently colors do work somehow in the Windows terminal; maybe time to revive that attempt?

How about setting env var GCC_COLORS = "" ?

My test in comment #4 (no colors) was with gcc 8.4.0, thus, I havn't updated my mxe environment for quite a long time.

+1 for the workaround proposed by Kai.

Very impressive ^^  My idea is that gcc is tampering with the terminal colors since recent versions.

For Octave 5.1.90:

>> system ("gcc -v")
  [...]
gcc version 9.2.0 (GCC)

For Octave 5.1.90:

>> system ("gcc -v")
  [...]
gcc version 7.4.0 (GCC)

To get some sort of "normal" colors back, one can use

system ("COLOR 01")

or has to restart the Octave session.  Maybe there is a smarter command to reset the window colors?  Please share.


To totally avoid this tampering, if I compile with

mkoctfile -fdiagnostics-color=never .......

https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Diagnostic-Message-Formatting-Options.html

Then it looks pretty much "colorless" as in Octave 5.1.0.  Thus an emergency change would be to add "-fdiagnostics-color=never" to the standard options of mkoctfile.

Thoughts?

Linux does not seem to be affected.
When I try to reproduce this in windows, I do not get colored error messages and the text stays black afterwards. Is there a special trick to get colored error messages in windows (in Linux, I see them, too).

@Hartmut: All attached screenshots look good to me. You might have unintentionally uploaded the same screenshot twice.

I have observed the following in Octave 5.1.90 (and not in Octave 5.1.0). I have seen this under Windows 10, but am unsure if it also happens under Linux.

Here is how to reproduce the behavior:

• start the Octave GUI (for information on CLI see below)
• do something that starts a compilation which will throw an error, maybe a "mkoctfile ..." will do, I used a "pkg install ...".
• the error message will be displayed in nice and useful colors
• at the end of the error message the text will turn to grey color (I am unsure if this is intentional)
• but afterwards, the text color will not return to black and STAY IN GRAY text color. This looks wrong.

In CLI Octave this looks alright, the very error will also be displayed in (red and green) color, and afterwards the text color returns to white on black.

I will attach screenshots to show the colorful behavior.

(This might also happen in dev Octave, I haven't tested for it.)