guile-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] Colorized REPL


From: Nala Ginrut
Subject: Re: [PATCH] Colorized REPL
Date: Wed, 05 Dec 2012 18:27:35 +0800

On Wed, 2012-12-05 at 17:45 +0800, Daniel Hartwig wrote:
> 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).
> 

OK, I understand it now. And I'm going to write an more extensible
type-checker. Nevertheless, maybe I should do some work to give the
users chance to define his/her own color-scheme in '~/.guile'. 
But it maybe not so easy, I've no idea about it yet. So I'll do the
type-checker first. 

> >
> >>
> >> 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.
> 

I can understand this too. So your suggestion is to write a 
(term ansi-color) compatible interface. I think it's easy to do.
But I'm afraid that Guile don't integrate (term ansi-color). Or I should
copy (term ansi-color) into colorized.scm? It's not a big one, but is it
proper?
Anyway, (ice-9 colorized) contains ansi-color procedures could be worthy
of the name.

What if I send three patches eventually?
1. optinal-repl-printer
2. colorized.scm
3. ansi-color.scm

I just want to make sure colorized-repl feature work successfully.

> > 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]