Quantcast

Coloring error and warning messages in the gui console

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Coloring error and warning messages in the gui console

Torsten-3
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Coloring error and warning messages in the gui console

Daniel Sebald
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 | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Coloring error and warning messages in the gui console

Torsten-3
On 09.05.2017 22:01, Daniel J Sebald wrote:

> 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

Dan, thank you for the reply. Just to clarify, the selection of the
color is done by the GUI depending on the user's settings. The core is
just interspersing esc-sequences for the GUI's terminal emulation into
the output stream depending on warning or error. This might later be
used for the cli-version, too, if the terminal emulation is known.

When I understand your approach correctly, the core would have to wait
during the four steps of the GUI before actually printing the message?
Wouldn't this have much more impact on the core? Or should the GUI
buffer the stream and search later for the appropriate positions for
changing color before printing?

Torsten

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Coloring error and warning messages in the gui console

Daniel Sebald
On 05/10/2017 01:15 AM, Torsten wrote:

> On 09.05.2017 22:01, Daniel J Sebald wrote:
>> 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
>
> Dan, thank you for the reply. Just to clarify, the selection of the
> color is done by the GUI depending on the user's settings. The core is
> just interspersing esc-sequences for the GUI's terminal emulation into
> the output stream depending on warning or error. This might later be
> used for the cli-version, too, if the terminal emulation is known.
>
> When I understand your approach correctly, the core would have to wait
> during the four steps of the GUI before actually printing the message?
> Wouldn't this have much more impact on the core? Or should the GUI
> buffer the stream and search later for the appropriate positions for
> changing color before printing?
>
> Torsten

You're saying that the changes then are really not GUI-specific, but
more generally the console.  That is, when I run octave-cli, I should
see errors and warnings in color in the shell console as well?  I
suppose that is more core/interpreter centric.  Is there to be some
script that can be used to configure the colors or turn them off from
the command line?  If so, then that is again core-centric.  (Perfectly
fine having configuration in the GUI somewhere--that ultimately calls
said configuration script.)

I thought I read in the bug/feature discussion that one goal is to make
clicking on the error message jump to the location of the code in the
GUI editor.  That is more GUI-related, unless the console can be set up
to initiate such a jump via the core, say something like the "edit"
routine.  Is this something separate from the color idea?  How is the
GUI getting the information about the line number?

Dan

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Coloring error and warning messages in the gui console

Pantxo
In reply to this post by Torsten-3


Torsten-3 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
Hi,

Lachlan had proposed to go this route in a patch he proposed. You may want to look at JWE's answer there:
https://savannah.gnu.org/patch/?9024

Pantxo
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Coloring error and warning messages in the gui console

Torsten-3
On 10.05.2017 10:15, Pantxo wrote:

>
>
>
> Torsten-3 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
>
> Hi,
>
> Lachlan had proposed to go this route in a patch he proposed. You may want
> to look at JWE's answer there:
> https://savannah.gnu.org/patch/?9024
>
> Pantxo
>

Pantxo, thanks for pointing out Lachlans patch, which I have totally
missed. I agree that on the long run, a new solution for the console
window, which does depend on the platform, is required. Maybe we can
still implement affordable solutions in the meantime.

Torsten


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Coloring error and warning messages in the gui console

Torsten-3
In reply to this post by Daniel Sebald
On 10.05.2017 08:33, Daniel J Sebald wrote:

> On 05/10/2017 01:15 AM, Torsten wrote:
>> On 09.05.2017 22:01, Daniel J Sebald wrote:
>>> 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
>>
>> Dan, thank you for the reply. Just to clarify, the selection of the
>> color is done by the GUI depending on the user's settings. The core is
>> just interspersing esc-sequences for the GUI's terminal emulation into
>> the output stream depending on warning or error. This might later be
>> used for the cli-version, too, if the terminal emulation is known.
>>
>> When I understand your approach correctly, the core would have to wait
>> during the four steps of the GUI before actually printing the message?
>> Wouldn't this have much more impact on the core? Or should the GUI
>> buffer the stream and search later for the appropriate positions for
>> changing color before printing?
>>
>> Torsten
>
> You're saying that the changes then are really not GUI-specific, but
> more generally the console.  That is, when I run octave-cli, I should
> see errors and warnings in color in the shell console as well?  I
> suppose that is more core/interpreter centric.  Is there to be some
> script that can be used to configure the colors or turn them off from
> the command line?  If so, then that is again core-centric.  (Perfectly
> fine having configuration in the GUI somewhere--that ultimately calls
> said configuration script.)
>
> I thought I read in the bug/feature discussion that one goal is to make
> clicking on the error message jump to the location of the code in the
> GUI editor.  That is more GUI-related, unless the console can be set up
> to initiate such a jump via the core, say something like the "edit"
> routine.  Is this something separate from the color idea?  How is the
> GUI getting the information about the line number?
>
> Dan

Clickable links are already implemented in the linux gui console window
using the existing concept of filters. The attached patch is just for
coloring the text of error messages in the gui console window by
inserting the respective escape sequences into the text strings.

Torsten



Loading...