patchGNU Octave - Patches: patch #9024, Colour-coded output text

 
 

patch #9024: Colour-coded output text

Submitter:  Lachlan Andrew <lachlan>
Submitted:  Fri 10 Jun 2016 09:22:05 AM UTC
   
 
Category:  Core : new feature Priority:  5 - Normal
Status:  None Privacy:  Public
Assigned to:  lachlan Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 17 May 2018 04:43:06 PM UTC, comment #17: 

Has there been any progress on this? How can I apply this patch? I've compiled with ".patch" files before by placing them in the src folder (using mxe-octave), but is it the same to apply .cdiff files?

Marshall <marsian>
Sun 26 Jun 2016 07:05:05 AM UTC, comment #16: 

Yes, the command window widget implementations are entirely different for Windows and Unix.

I would like to merge them into one and handle I/O in a completely different way, probably such that any pager will have to be built-in to Octave instead of using an external program.  I don't think that limitation will cause a lot of trouble for most users.  AFAIK, Matlab can't do 'system ("emacs")'.

I don't know what this would mean for color-coded output, but I expect that it would allow us to do a better job.

But the main reasons that I want to make this change are that I think it will allow better interrupt and event handling and it will simplify maintenance by having one implementation of the command window.

John W. Eaton <jwe>
Group administrator
Sun 26 Jun 2016 12:27:20 AM UTC, comment #15: 

Thanks, Philip.

The command window is completely different in posix and windows.  I'm not sure why it has to be; they just forked from different applications (Konsole for posix and cygwin for Windows).  I think that it would be good to try to port Konsole to Windows, because it also has some support for hyperlinks.  (I'm currently working on hyperlinking error messages to open the editor at the right position.)

The big advantage of using escape sequences is that the pager will set the colours each time it redraws the screen to go backwards or forwards.  I don't think that is possible if the mechanism to set the colour is not based on the character stream itself.  Having said that, the reason for having a new class rather than just storing a list of escape sequences is to allow that sort of flexibility, if it turns out to be necessary.

Lachlan Andrew <lachlan>
Sat 25 Jun 2016 09:34:20 PM UTC, comment #14: 

GUI screenshot attached. More or less similar results with the CLI.

Yes I think on Windows in the GUI ANSI sequences aren't recognized/processed.

I'll try Linux later on - rebuilding w/o patches from a fresh clone from before John's doc changes followed by cross-building + installing needs due attention and it's almost midnight here :-)

Like you I fail to see how any of the patches I included could affect the color cset.
In libgui/src/ you might follow the sources to see if there are specific Windows clauses that could give a clue. AFAIU the GUI terminal on Windows is different than the one on *nix.
Maybe ANSI sequences should be dropped in favor of the way terminal font colors are set in the terminal preferences tab? I suppose JWE prefers identical code paths for as much OSes as possible.



Philip Nienhuis <philipnienhuis>
Group Member
Sat 25 Jun 2016 12:11:58 PM UTC, comment #13: 

For Windows, can you see what happens (with or without the patch) with the code


a = '.[38;5;160m';
a(1) = 27;
a


It should turn the text red.  If it doesn't, then the Windows terminal doesn't accept ANSI escape sequences, and I have no idea how to change the colours.


The Linux case is puzzling.  If you put


output_highlight ('user', 'U', 'cmd_line', 'C', 'err', 'E', 'warn', 'W', 'sys', 'S');


in your .octaverc?  It should output the appropriate character whenever the system would normally try to change colour.

Although none of the patches you have should affect the compile error, it is possible that one is affecting the behaviour.  Could you try it on a the default head?

Lachlan Andrew <lachlan>
Fri 24 Jun 2016 10:23:31 PM UTC, comment #12: 

After JWE pushed a fix to mxe-octave I can build again for Windows.

Intriguingly, the patch does nothing on Windows. I don't know the cause, but the fonts remain black :-Z

Philip Nienhuis <philipnienhuis>
Group Member
Thu 23 Jun 2016 07:24:33 PM UTC, comment #11: 

I really have no idea what could cause that error.
Nor do I ....
But I have updated my mxe-octave tree (three times in fact, due to other cross-build errors) and at least dev Octave gets built for 32-bits now (64-bits pending).

I tried your 1st patch on Linux and have some comments:

- After starting Octave, all text is black.

- After deliberately typing garbage the error message is shown in red and only then the prompt changes to blue.

- Then, after "1 / 0" (w/o quotes) the error message is in black, cursor in blue

- after a valid statement the cursor changes back to black.

Conclusion: overall it works but there are some small glitches.

To repeat myself (comment #3): I like the idea.

(cross-building now)

Philip Nienhuis <philipnienhuis>
Group Member
Wed 22 Jun 2016 09:44:10 AM UTC, comment #10: 

Here's an updated patch reflecting the change to docstring format.

It doesn't address Philip's concerns about MXE.  I really have no idea what could cause that error.

(file #37542)

Lachlan Andrew <lachlan>
Sat 18 Jun 2016 09:50:08 AM UTC, comment #9: 

Yes, this time I did use the latest tip (now two days old).  I haven't checked those patches, but I don't think they should cause the problem you see.  It is related to something JWE did a few weeks ago, introducing the "octave::" namespace.

The function should be defined in oct-env.h, which is included at about line 32 of pager.cc.  Does your oct-env.h have "namespace octave" at line 60, or thereabouts?

You can also check that, for example, kpse.cc uses the same  octave::sys::env::getenv().

Does the new MXE build without this patch?

Lachlan Andrew <lachlan>
Fri 17 Jun 2016 07:34:08 PM UTC, comment #8: 

bug 4149 should be bug 47149

Philip Nienhuis <philipnienhuis>
Group Member
Fri 17 Jun 2016 07:33:18 PM UTC, comment #7: 

Here are some errors that came up:

- 1 hunk FAILED  in cmd-edit.h (was easy to fix)

then:

  CXX      libinterp/corefcn/libinterp_corefcn_libcorefcn_la-pager.lo
../dev_VE2/libinterp/corefcn/pager.cc: In member function 'void font_context::do_init()':
../dev_VE2/libinterp/corefcn/pager.cc:544:26: error: 'octave' has not been declared
       std::string term = octave::sys::env::getenv ("TERM");


Did you use the latest tip?

I do and have these latest patches/csets applied from:
- patch 8656
- bug 36372
- bug 46632
- bug 4149
- bug 47414
- patch 8956
- and patch 9024

Philip Nienhuis <philipnienhuis>
Group Member
Fri 17 Jun 2016 04:00:37 PM UTC, comment #6: 

Ah so you beat me (I got only ~10 patches at a time)  :-)

I'll give it a try.
I'm afraid it is time to renew my mxe-octave build tree (3 months old) so it'll be while.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 15 Jun 2016 03:20:54 PM UTC, comment #5: 

Sorry about the messy patch.  I have about 30 patches on my system, and some of them conflicted with this.

I think I've fixed the problems that were causing those errors.

Now let's see what new errors come up :)

(file #37489)

Lachlan Andrew <lachlan>
Tue 14 Jun 2016 11:42:23 PM UTC, comment #4: 

OK, I'll look into those errors.  Thanks for giving it a test run.

Lachlan Andrew <lachlan>
Tue 14 Jun 2016 05:54:15 PM UTC, comment #3: 

Symlinking pager.h in liboctave/util from lininterp/corefcn (a dirty hack) + fixing the FAILED hunk made the build continue and it works on Mageia-5.
I can say that I like the result.

Too bad it doesn't cross-build with mxe-octave (with pager.h copied into liboctave/util):

:
libtool: link: ( cd "libinterp/octave-value/.libs" && rm -f "liboctave-value.la" && ln -s "../liboctave-value.la" "liboctave-value.la" )
libinterp/build-env-features.cc: In function 'octave_scalar_map octave::build_env::features()':
libinterp/build-env-features.cc:15:5: note: variable tracking size limit exceeded with -fvar-tracking-assignments, retrying without
     features (void)
     ^
mv -f libinterp/.deps/libinterp_liboctinterp_la-build-env-features.Tpo libinterp/.deps/libinterp_liboctinterp_la-build-env-features.Plo
liboctave/util/.libs/libutil.a(liboctave_util_libutil_la-cmd-edit.o): In function `octave::command_editor::readline(std::string const&, bool&)':
/home/philip/devel/octdev/mxe/mxe_w64_20150316/tmp-default-octave/octave-4.1.0+/liboctave/util/cmd-edit.cc:1167: undefined reference to `operator<<(std::ostream&, font_context::font)'
/home/philip/devel/octdev/mxe/mxe_w64_20150316/tmp-default-octave/octave-4.1.0+/liboctave/util/cmd-edit.cc:1169: undefined reference to `operator<<(std::ostream&, font_context::font)'
collect2: error: ld returned 1 exit status
Makefile:12888: recipe for target 'liboctave/liboctave.la' failed


Philip Nienhuis <philipnienhuis>
Group Member
Mon 13 Jun 2016 07:45:34 PM UTC, comment #2: 

I get this with tip of June 13:

  CXX      liboctave/util/liboctave_util_libutil_la-cmd-edit.lo
../dev_VE/liboctave/util/cmd-edit.cc:46:19: fatal error: pager.h: No such file or directory
 #include "pager.h"
                   ^
compilation terminated.
Makefile:22669: recipe for target 'liboctave/util/liboctave_util_libutil_la-cmd-edit.lo' failed
make[2]: *** [liboctave/util/liboctave_util_libutil_la-cmd-edit.lo] Error 1
make[2]: Leaving directory '/home/philip/devel/octdev/oct410+VE'
Makefile:25532: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/philip/devel/octdev/oct410+VE'
Makefile:9686: recipe for target 'all' failed
make: *** [all] Error 2


Note that there was also a FAILED hunk in error.cc

Philip Nienhuis <philipnienhuis>
Group Member
Mon 13 Jun 2016 09:53:48 AM UTC, comment #1: 

Note the patch accidentally has tabs in it.  I'll remove them from the next version, but will wait for feedback first.

Lachlan Andrew <lachlan>
Fri 10 Jun 2016 09:22:05 AM UTC, original submission:  

This patch colour-codes the console output to make errors stand out.

It divides output into five "contexts":

1. User output      (default)
2. Errors           (red)
3. Warnings         (brown)
4. The command line (blue)
5. "system" output, such as the line at which a breakpoint occurs.
                    (green)

Each context is started by a user-definable ANSI escape sequence, which could optionally be set to, for example, underline or bold. The sequences are not limited to ANSI sequences, but other sequences may not be passed through the "less" pager.

This may be considered eye-candy, but I find that it helps me parse a screenful of text.

Lachlan Andrew <lachlan>

 

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

Attach Files:
   
   
Comment:
   

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by marsian (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by lachlan (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 logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-07-07 lachlan CategoryNone Core : new feature
    2016-06-25 philipnienhuis Attached File- Added Octave_terminal_colors.png, #37577
    2016-06-22 lachlan Attached File- Added patch_coloured_font_context.v2.cset, #37542
    2016-06-15 lachlan Attached File- Added patch_coloured_font_context.v1.cset, #37489
    2016-06-10 lachlan Attached File- Added patch_coloured_font_context.cset, #37446

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code