[Top][All Lists]

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

Re: [PATCH] Colorized REPL

From: Daniel Hartwig
Subject: Re: [PATCH] Colorized REPL
Date: Sat, 12 Jan 2013 08:26:43 +0800

On 11 January 2013 22:33, Ludovic Courtès <address@hidden> wrote:
>>> > +(define *color-list*
>>> > +  `((CLEAR       .   "0")
>>> > +    (RESET       .   "0")
>>> > +    (BOLD        .   "1")
>>> > +    (DARK        .   "2")

>>> Would it make sense to define a new type for colors?  Like:
>>>   (define-record-type <color>
>>>     (color foreground background attribute)
>>>     color?
>>>     ...)

I presume you intended this to be private to the module.  Exposing
such a type publicly and calling it <color> is just offensive, since
these are ANSI control codes and contain no colour representation. :-)

>> Actually, I did similar things (though without record-type), but I was
>> suggested use the *color-list* implementation from (ansi term) from
>> guile-lib. hmm... ;-)
>> Anyway, I think that implementation is not so clear, and it mixed
>> 'colors' and 'controls' together...
> Which implementation?

See guile-libs (term ansi-color) module.

> I still think that using a disjoint type for
> colors would be better than symbols.

These are arbitrary control codes and can be applied in any
combination.  Essentially, the best you can do with a disjoint type

(define-record-type foo
  (make-foo name code) …

Which you would still need a dictionary to look them up by name, or
export a binding for every code and combination, or provide additional
operators to combine them …

The type you proposed seems to operate at the next level, holding
several codes in pre-defined fields according to their perceived
function (foreground colour, etc.).  Several of those fields will
often be blank, i.e. the case where only “bold” is activated.  These
will have to be later converted to a list to be useful in generating
the escape sequence.

List of symbols is a convenient abstraction over the natural form:
list of control codes.  Embedding this in to a record with named and
function-presuming fields is too much and needlessly complicated, IMO.

List of symbols is also compatible with the interface established by
the earlier guile-lib module, for whatever that is worth.

Using list of symbols:

(colorize-string "foo" '(RED))
(colorize-string "foo" '(BOLD ON-CYAN))

It is not clear to me the interface you are proposed at this level.
Will you provide counter examples to these two calls?


reply via email to

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