color-aware output pane

Discussion:

Liviu Andronic

2012-05-13 09:05:16 UTC

Dear Tom
Try this script [1] in a terminal and in emel. In the terminal there
will be formatting (bold, green colour), while in emel the data will

/home/liv/Downloads/src/compiz-check_0-4-6 (6547)

Gathering information about your system...

Distribution: [1mUbuntu 10.04 [0m
Desktop environment: [1mXfce [0m
Graphics chip: [1mIntel Corporation Mobile 4 Series Chipset
Integrated Graphics Controller (rev 07) [0m
Driver in use: [1mintel [0m
Rendering method: [1mAIGLX [0m

Checking if it's possible to run Compiz on your system...

Checking for texture_from_pixmap... [ [1;32mOK [0m ]
Checking for non power of two support... [ [1;32mOK [0m ]
Checking for composite extension... [ [1;32mOK [0m ]
Checking for FBConfig... [ [1;32mOK [0m ]
Checking for hardware/setup problems... [ [1;32mOK [0m ]

/home/liv/Downloads/src/compiz-check_0-4-6 (6547) returned '0'

Could this be fixed in emel? Thanks
Liviu

[1] http://forlong.blogage.de/entries/pages/Compiz-Check

--
Do you know how to read?
http://www.alienetworks.com/srtest.cfm
http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader
Do you know how to write?
http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail

Adam Krolnik

2012-05-14 15:29:17 UTC

Permalink

There are only two things that make emelfm2 less used than Thomas Dickey's
xterm.
o lack of coloring of output text (ala ansi color escape sequence)
o full support of shell globbing - e.g. egrep ... design/*/*v

I would love to have color in emel's output pane like this.

Post by Liviu Andronic
Dear Tom
Try this script [1] in a terminal and in emel. In the terminal there
will be formatting (bold, green colour), while in emel the data will

/home/liv/Downloads/src/compiz-check_0-4-6 (6547)

Gathering information about your system...
Distribution: [1mUbuntu 10.04 [0m
Desktop environment: [1mXfce [0m
Graphics chip: [1mIntel Corporation Mobile 4 Series Chipset
Integrated Graphics Controller (rev 07) [0m
Driver in use: [1mintel [0m
Rendering method: [1mAIGLX [0m
Checking if it's possible to run Compiz on your system...
Checking for texture_from_pixmap... [ [1;32mOK [0m ]
Checking for non power of two support... [ [1;32mOK [0m ]
Checking for composite extension... [ [1;32mOK [0m ]
Checking for FBConfig... [ [1;32mOK [0m ]
Checking for hardware/setup problems... [ [1;32mOK [0m ]

/home/liv/Downloads/src/compiz-check_0-4-6 (6547) returned '0'

Could this be fixed in emel? Thanks
Liviu
[1] http://forlong.blogage.de/entries/pages/Compiz-Check
--
Do you know how to read?
http://www.alienetworks.com/srtest.cfm
http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader
Do you know how to write?
http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail
--
Users can unsubscribe from the list by sending email to
by logging into the web interface.

--
Adam Krolnik

t***@onepost.net

2012-05-14 23:46:11 UTC

Permalink

On Sun, 13 May 2012 11:05:16 +0200

Post by Liviu Andronic
Dear Tom
Try this script [1] in a terminal and in emel. In the terminal there
will be formatting (bold, green colour), while in emel the data will

/home/liv/Downloads/src/compiz-check_0-4-6 (6547)

Could this be fixed in emel? Thanks

Possible, Liviu, but unlikely.

Seems to me that the costs (determining which terminal is being emulated; determining in a cross-OS manner the terminal's 'control codes' and what they're supposed to do; checking each displayed char to see whether it needs special treatment; converting such treatment to GtkTextbuffer-compatible styling; reconciling that with standard emelFM2 output styling) are too high, relative to the number of times it would be beneficial. We're already stuck with some content processing (e.g. to ensure the text is UTF-8 encoded) and I would prefer not to make the output even slower.

Regards
Tom

Adam Krolnik

2012-05-15 14:14:34 UTC

Permalink

<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#99FFFF" text="#000000">
 
Hi Tom; 
 
One always has to weigh the implementation costs. But one has to
also consider the beneficial aspects. 
 
I've used coloring in two major ways on xterm. 
  o print a bar in red/blue to indicate the end of the output and
the exit status. 
    This mostly shows the end of the command so that searching
backward in the buffer has a easy to 
    recognize termination point. Secondly, the exit status is
apparent. Thus my processing is now truncated 
    and thus faster. 
  o highlight my search pattern from egrep. - This also makes
reviewing the results faster due to the 
    pattern I searched for being highlighted. I now can do pattern
matching based on color rather than 
    have to read all the text of each line to scan for what I'm
looking for - again, speeding my processing. 
    Being able to double click on the filename from egrep in emelfm2
to edit a file, is again a time savings. 
 
I've recently setup an alias to vim to pipe color results into so
that I can work with them. Using the 
xterm.vim syntax setup, from Andy Spencer, it converts the ansi
escape colored sequences into vim syntax 
highlighting. Thus I get the patterns highlighted.  It simply
translates the color specified in the escape 
sequence to a highlight color name xtermColorN (where N is the color
number from the escape sequence.) 
[my alias is: alias le 'gvim "+set syntax=xterm" -';   This assumes
you already have vim setup for colors, etc. 
And Andy's xterm syntax setup does not set the guifg colors, so if
you use gvim, you won't get color until you 
set that in his script.] 
 
This feature could simply start as a compile time option, only
supporting ANSI escape sequences. 
It appears that GTK does support adding text with color components,
so the transfer could simply lookup 
the desired colors from a configuration color table. 
 
So yes the time to implement the feature may not be trivial, but the
value is there. There are so many 
features in emelfm2 that took time to implement, but overall make it
a great tool - customizable buttons, 
mouse buttons, click on output pane filenames, etc. All make it
faster for the user to complete the job 
they are doing. 
 
    Thanks Tom. 
 
 
 
On 05/14/2012 06:46 PM, <a class="moz-txt-link-abbreviated" href="mailto:***@onepost.net">***@onepost.net</a> wrote:
<blockquote cite="mid:***@cpc2.cooks"
type="cite">
<pre wrap="">On Sun, 13 May 2012 11:05:16 +0200
Liviu Andronic <a class="moz-txt-link-rfc2396E" href="mailto:***@gmail.com"><***@gmail.com></a> wrote:

</pre>
<blockquote type="cite">
<pre wrap="">Dear Tom
Try this script [1] in a terminal and in emel. In the terminal there
will be formatting (bold, green colour), while in emel the data will
be enclosed in gibberish:
</pre>
<blockquote type="cite">
<pre wrap="">/home/liv/Downloads/src/compiz-check_0-4-6 (6547)
</pre>
</blockquote>
<pre wrap="">
Could this be fixed in emel? Thanks
</pre>
</blockquote>
<pre wrap="">
Possible, Liviu, but unlikely.

Seems to me that the costs (determining which terminal is being emulated; determining in a cross-OS manner the terminal's 'control codes' and what they're supposed to do; checking each displayed char to see whether it needs special treatment; converting such treatment to GtkTextbuffer-compatible styling; reconciling that with standard emelFM2 output styling) are too high, relative to the number of times it would be beneficial. We're already stuck with some content processing (e.g. to ensure the text is UTF-8 encoded) and I would prefer not to make the output even slower.

Regards
Tom

</pre>
</blockquote>
 
<pre class="moz-signature" cols="85">--
Soli Deo Gloria
Adam Krolnik
Director of Design Verification
VeriSilicon Inc.
Plano TX. 75074
Co-author "Assertion-Based Design", "Creating Assertion-Based IP"
</pre>
</body>
</html>

t***@onepost.net

2012-05-17 12:36:56 UTC

Permalink

On Tue, 15 May 2012 09:14:34 -0500

One always has to weigh the implementation costs. But one has to also consider the beneficial aspects.
I've used coloring in two major ways on xterm.
o print a bar in red/blue to indicate the end of the output and the exit status.
This mostly shows the end of the command so that searching backward in the buffer has a easy to
recognize termination point. Secondly, the exit status is apparent. Thus my processing is now truncated
and thus faster.

This sort of thing already happens in the e2 output pane.

o highlight my search pattern from egrep. - This also makes reviewing the results faster due to the
pattern I searched for being highlighted. I now can do pattern matching based on color rather than
have to read all the text of each line to scan for what I'm looking for - again, speeding my processing.
Being able to double click on the filename from egrep in emelfm2 to edit a file, is again a time savings.

You remind me - long ago I considered adapting the find plugin to show a matching line as well as the file path. Then forgot about it.

I've recently setup an alias to vim to pipe color results into so that I can work with them. Using the
xterm.vim syntax setup, from Andy Spencer, it converts the ansi escape colored sequences into vim syntax
highlighting. Thus I get the patterns highlighted. It simply translates the color specified in the escape
sequence to a highlight color name xtermColorN (where N is the color number from the escape sequence.)
[my alias is: alias le 'gvim "+set syntax=xterm" -'; This assumes you already have vim setup for colors, etc.
And Andy's xterm syntax setup does not set the guifg colors, so if you use gvim, you won't get color until you
set that in his script.]
This feature could simply start as a compile time option, only supporting ANSI escape sequences.
It appears that GTK does support adding text with color components

Yes, that's how e2 shows in its output pane red text for error messages and green (or red) text for command-completion-status messages.

, so the transfer could simply lookup

the desired colors from a configuration color table.

Not so simple, in practice.

So yes the time to implement the feature may not be trivial, but the value is there. There are so many
features in emelfm2 that took time to implement, but overall make it a great tool - customizable buttons,
mouse buttons, click on output pane filenames, etc. All make it faster for the user to complete the job
they are doing.

Implementation time/effort is not an issue, really. In fact, some of the work for this sort of capability was done, long ago, but abandoned because I'm more interested to preserve the application's speed, size, minimal dependencies, no wheel-reinvention, reliability, etc etc - overall, I might call it "good value".

Could perhaps just get it going as a build-time define, tell Liviu and you about it, and the rest of us can get on with our lives ...

Regards
Tom

Adam Krolnik

2012-05-17 13:48:18 UTC

Permalink

I've made an attempt at the ansi code parsing. Colors are hard coded.
e2_output_print was modified,
but don't know if this is the correct place...

The example shows egrep coloring its search terms. Egrep uses GREP_COLOR
set to the ansi sequence number to define the color.

ANSI sequences basically give up to 4 attributes: bold, blink, color,
background. A configuration
pane would be needed to map a color (and background) number (0-255) to a
gtk color.
So the text generating tool can specify a color (as a number), but emelfm2
would define what that
exact color would be.

Post by t***@onepost.net
On Tue, 15 May 2012 09:14:34 -0500

One always has to weigh the implementation costs. But one has to also

consider the beneficial aspects.

I've used coloring in two major ways on xterm.
o print a bar in red/blue to indicate the end of the output and the

exit status.

This mostly shows the end of the command so that searching backward

in the buffer has a easy to

recognize termination point. Secondly, the exit status is apparent.

Thus my processing is now truncated

and thus faster.

This sort of thing already happens in the e2 output pane.

o highlight my search pattern from egrep. - This also makes reviewing

the results faster due to the

pattern I searched for being highlighted. I now can do pattern

matching based on color rather than

have to read all the text of each line to scan for what I'm looking

for - again, speeding my processing.

Being able to double click on the filename from egrep in emelfm2 to

edit a file, is again a time savings.
You remind me - long ago I considered adapting the find plugin to show a
matching line as well as the file path. Then forgot about it.

I've recently setup an alias to vim to pipe color results into so that I

can work with them. Using the

xterm.vim syntax setup, from Andy Spencer, it converts the ansi escape

colored sequences into vim syntax

highlighting. Thus I get the patterns highlighted. It simply translates

the color specified in the escape

sequence to a highlight color name xtermColorN (where N is the color

number from the escape sequence.)

[my alias is: alias le 'gvim "+set syntax=xterm" -'; This assumes you

already have vim setup for colors, etc.

And Andy's xterm syntax setup does not set the guifg colors, so if you

use gvim, you won't get color until you

set that in his script.]
This feature could simply start as a compile time option, only

supporting ANSI escape sequences.

It appears that GTK does support adding text with color components

Yes, that's how e2 shows in its output pane red text for error messages
and green (or red) text for command-completion-status messages.
, so the transfer could simply lookup

the desired colors from a configuration color table.

Not so simple, in practice.

So yes the time to implement the feature may not be trivial, but the

value is there. There are so many

features in emelfm2 that took time to implement, but overall make it a

great tool - customizable buttons,

mouse buttons, click on output pane filenames, etc. All make it faster

for the user to complete the job

they are doing.

Implementation time/effort is not an issue, really. In fact, some of the
work for this sort of capability was done, long ago, but abandoned because
I'm more interested to preserve the application's speed, size, minimal
dependencies, no wheel-reinvention, reliability, etc etc - overall, I might
call it "good value".
Could perhaps just get it going as a build-time define, tell Liviu and you
about it, and the rest of us can get on with our lives ...
Regards
Tom
--
Users can unsubscribe from the list by sending email to
by logging into the web interface.

--
Adam Krolnik

t***@onepost.net

2012-05-25 22:52:12 UTC

Permalink

On Thu, 17 May 2012 08:48:18 -0500

Post by t***@onepost.net
Implementation time/effort is not an issue, really. In fact, some of the
work for this sort of capability was done, long ago, but abandoned because
I'm more interested to preserve the application's speed, size, minimal
dependencies, no wheel-reinvention, reliability, etc etc - overall, I might
call it "good value".
Could perhaps just get it going as a build-time define, tell Liviu and you
about it, and the rest of us can get on with our lives ...

With assistance and encouragement from Adam and Liviu, there's now code in svn to process many of the ANSII style-related control sequences (the ones like ESC[....m). You can enable this by building with make parameter WITH_OUTPUTSTYLES=1.

I probably won't normally use this, myself, so if/when you find a problem, please advise.

Regards
Tom