octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Coloring error and warning messages in the gui console


From: Daniel J Sebald
Subject: Re: Coloring error and warning messages in the gui console
Date: Tue, 9 May 2017 15:01:41 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0

On 05/09/2017 02:35 PM, Torsten wrote:
I am currently working on possible ways to color error and warning
messages in the gui console window. The unix based terminal offers
filters for highlighting matched "hotspots". Unfortunately, the elements
painted for highlighting lead to ugly artefacts when scrolling.
Consequently, this filter method is currently only used for underlining
clickable links (files for opening in the editor or urls) when the mouse
cursor is hovering over them.

For the text colors of error and warning messages I would like to insert
suitable escape sequences into the message strings as implemented in the
patch attached to comment #9 of bug #35619
(https://savannah.gnu.org/bugs/?35619#comment9)
Before pushing this patch, I would like to know whether there are any
objections against changing one of octaves core files (error.cc) only
for "cosmetic" reasons.

Best,
Torsten

Thanks for asking Torsten. I looked at the patch and I object to this one on the basis that it implies the core code is doing something GUI specific, i.e., assigning some color to the errors. Is that something that should be done? I've been against inter-mixing GUI details into core code from the start, for multiple reasons. (I drafted a response to one of Rik's emails a couple weeks back, but hadn't sent it... I will follow up this email.)

The proper way to do this, as I see it, is for the core to allow some routine to access the previous error(s), whether that is a function or some type of script command. (Unfortunately, there has always been lacking the simple method of calling a script from the GUI and getting an octave_value_list in return.) That is, when there is an error, the core should have a log of what happened (a unique error message or classification) and the line number and file where it happened. There should also be a list of available error messages, for which the GUI can assign the color scheme however it wants. The steps would be:

1) GUI recognizes error occurred
2) GUI inquires what the error was
3) GUI cross references error message in the list of possible messages
4) GUI uses the index from the cross reference to look up color in its own table

Dan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]