Re: color-aware output pane

  • From: Adam Krolnik <adam.krolnik@xxxxxxxxxxxxxxx>
  • To: <emelfm2@xxxxxxxxxxxxx>
  • Date: Tue, 15 May 2012 09:14:34 -0500


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, tpgww@xxxxxxxxxxx wrote:
On Sun, 13 May 2012 11:05:16 +0200
Liviu Andronic <landronimirc@xxxxxxxxx> wrote:

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:
/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



-- 
    Soli Deo Gloria
    Adam Krolnik
    Director of Design Verification
    VeriSilicon Inc.
    Plano TX. 75074
    Co-author "Assertion-Based Design", "Creating Assertion-Based IP"
-- Users can unsubscribe from the list by sending email to emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or by logging into the web interface.

Other related posts: