From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Hartwig Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] Colorized REPL Date: Sat, 12 Jan 2013 08:26:43 +0800 Message-ID: References: <1354692089.25329.71.camel@Renee-desktop.suse> <1354697316.25329.83.camel@Renee-desktop.suse> <1354703255.25329.107.camel@Renee-desktop.suse> <87a9tmajov.fsf@gnu.org> <1355106191.22533.63.camel@Renee-desktop.suse> <87zk1l1t3x.fsf@gnu.org> <1356942598.2785.174.camel@Renee-desktop.suse> <87623dvy88.fsf@gnu.org> <1357726654.2798.103.camel@Renee-desktop.suse> <87k3rj7psf.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1357950413 25029 80.91.229.3 (12 Jan 2013 00:26:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Jan 2013 00:26:53 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Jan 12 01:27:11 2013 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TtowG-0000jF-Gn for guile-devel@m.gmane.org; Sat, 12 Jan 2013 01:27:08 +0100 Original-Received: from localhost ([::1]:49752 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ttow0-00082U-Fg for guile-devel@m.gmane.org; Fri, 11 Jan 2013 19:26:52 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:33413) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ttovw-00082E-KQ for guile-devel@gnu.org; Fri, 11 Jan 2013 19:26:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ttovt-0006Rs-Sp for guile-devel@gnu.org; Fri, 11 Jan 2013 19:26:48 -0500 Original-Received: from mail-ia0-f180.google.com ([209.85.210.180]:48807) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ttovt-0006Qx-O0 for guile-devel@gnu.org; Fri, 11 Jan 2013 19:26:45 -0500 Original-Received: by mail-ia0-f180.google.com with SMTP id f27so665364iae.25 for ; Fri, 11 Jan 2013 16:26:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=ItFulSMKhSlvHd1KdLBbk0I0w+odSlEjcxjiQ0MtuVE=; b=QaWbOt8vLIJFHGnuah3nu3Y/CkI4QZA8BYTs2K08yavsxdTewrxTKye8WQYZKfXLB+ 6gNInNWaesF3Y49a5/4dmww9vyXGWslPlT+3TN7TLpOAczPB+nGPoY0cDbCKULRn7mU6 mNiRhtQT1riVk7/xYA2T/l7E9Q0evERIFyUrhYbwWqkGaxZm1AM3hkehfnSsRXMH7PTA QkBod06HB5a3ahowv7U8kk4L14eI/9mZVp8Sy9XN2Uu5l9R8HARfi5y80a/AeJZra9rl s64JMIYOoL9ARJynYUUOAfUVt9b+26fWY/FyAUlpZK5YAt0GKXUGbH3wKUUlclOXU1OV tXHw== Original-Received: by 10.42.32.71 with SMTP id c7mr59215367icd.35.1357950403531; Fri, 11 Jan 2013 16:26:43 -0800 (PST) Original-Received: by 10.64.76.51 with HTTP; Fri, 11 Jan 2013 16:26:43 -0800 (PST) In-Reply-To: <87k3rj7psf.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.210.180 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:15392 Archived-At: On 11 January 2013 22:33, Ludovic Court=C3=A8s 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 foreground background attribute) >>> color? >>> ...) I presume you intended this to be private to the module. Exposing such a type publicly and calling it 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 is: (define-record-type foo (make-foo name code) =E2=80=A6 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 =E2=80=A6 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 =E2=80=9Cbold=E2=80=9D is activate= d. 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? Regards