guile-devel
[Top][All Lists]
Advanced

[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: Wed, 5 Dec 2012 17:45:04 +0800

On 5 December 2012 16:48, Nala Ginrut <address@hidden> wrote:
>> Is there some advantage to using the GOOPS classes rather than
>> equivalent predicates, which are more universal?  Of course, the order
>> of the tests matters highly in both cases.
>>
>
> GOOPS classes covered all the possible types in Guile, and it's easy to
> detect the type of a datum with class-of. I just choose the simplest way
> which I can imagined.

Predicates cover the same or a greater range of types, in more detail.
 Consider application-specific types:
- a non-GOOPS extension will provide a predicate, but no specific GOOPS class;
- a GOOPS extension will typically provide both.

If the colouring is to be made extensible (as it should be), a system
based on GOOPS class will be insufficient for these extra types.
Further, suppose a user wants to colour the same type differently
depending on it's content (such as short vs. long strings, or strings
matching some pattern).

>
>>
>> There is already a guile-lib module (ansi term-color) that has a
>> particular syntax and defines the codes.  It would be excellent to
>> make use of it here, or at least share the syntax and avoid some
>> duplication.
>>
>
> The code segment of the color is not so big, so I write my own.
> And it's not easy to do a quick hack with mixing other guy's code.
> For a quick hack, and it's simple, so I have no time to care about
> reusing other's work.

Please consider to at least adjust your syntax to be compatible …

> I don't think it's proper to use (ansi term-color)
> purposely, since it's not in Guile.

… or target this work at extending guile-lib; as a pure-scheme module,
it certainly falls within the scope.  I understand you are keen to
have this integrated in to Guile proper.

> Wrong again. I forget add 'before-print-hook' and *unspecified*
> situation.

With the alternate (and preferred, IMO) patch I sent, the custom
print procedure should not contain those parts anyway.  You can
presume that an the before-print-hook has been called, and
unspecified value has already been ignored.

Anyway, looks like a good start to such a feature, though I am
surprised to see the structure is very different to pretty-print ! :-)

Regards



reply via email to

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