term colors file, interested?

[Petar Maymounkov]

Are people interested in having a "term" package which, to start with,
simply has constants for all ANSI term color/decoration switches:

const (
Reset = "\x1b[0m"
Bright = "\x1b[1m"
Dim = "\x1b[2m"
Underscore = "\x1b[4m"
Blink = "\x1b[5m"
Reverse = "\x1b[7m"
Hidden = "\x1b[8m"

FgBlack = "\x1b[30m"
FgRed = "\x1b[31m"
FgGreen = "\x1b[32m"
FgYellow = "\x1b[33m"
FgBlue = "\x1b[34m"
FgMagenta = "\x1b[35m"
FgCyan = "\x1b[36m"
FgWhite = "\x1b[37m"

BgBlack = "\x1b[40m"
BgRed = "\x1b[41m"
BgGreen = "\x1b[42m"
BgYellow = "\x1b[43m"
BgBlue = "\x1b[44m"
BgMagenta = "\x1b[45m"
BgCyan = "\x1b[46m"
BgWhite = "\x1b[47m"
)

This constants work fine on any unixy terminal. I am not a term
expert, so I am not sure whether a package like this should have
a more elaborate interface. But the constants above are very handy to
me.
You just say:

fmt.Printf(term.FgRed+"blah"+term.Reset)

Thoughts.

--Petar

[Ostsol]

I've played around with a similar idea, though I took a different
approach. I should note that text styles, and foreground and
background colours can be changed in a single call by inserted a
semicolon followed by the next option. Thus:

fmt.Println("\x1b[1;31;40mblah\x1b[0m")

. . . will print 'blah' in bright red on black. Perhaps in addition
to those constants one could have a function that constructs the
colour code based on style, foreground, and background choices.

One area that I spent much more research into was accessing termios -
without- cgo to enable raw input mode. Here's a pastie where I ported
some C code to Go in order to test my implementation.

http://go.pastie.org/813153

Of course, it isn't portable to Windows and neither are ANSI terminal
escape codes, though both can be hidden under sufficient code such
that the API is portable. The only problem is that the Win32 console
API must be linked to -- which at the moment means using cgo.

-Daniel

[Giles Lean]

I have horrible fears that somewhere down this path, we'll end up
wanting equivalent functionality to terminfo and {n,}curses. While
the APIs of both those packages are ancient, IMHO not very nice etc
etc, I'd be quite hesitant to add anything to Go *now* that isn't
either:

a) heading toward adoption of the widely known terminfo/curses API
(note there are open source non-GPL implementations around for both
(in C) if that helps)

b) have a plan to cover the functionality of terminfo/curses in a Go-
idiomatic way, presumably with automated translation of at least the
still useful parts of the terminfo database entries into something the
Go term package can use.

I grew up too late for it to be fashionable to write my own editor (I
wrote my own mail software instead :-) but I'm sure there are people
on the list who have implemented editors, and perhaps they'd like to
comment on what they'd want from Go to implement a UTF-8 editor,
ideally one that runs in an xterrm (Linux, FreeBSD), and Terminal.app
(OS X).

Windows ... is another ball of wax. Editors there might be best
treated as a separate problem and expected to implement their own GUI,
but I don't know. I vaguely recall that I've used alternate "shells/
consoles" on Windows, but not their names or actually how good they
were, or what editor(s) I used within them.

Giles

[Ethan Grammatikidis]

Resending to group, sorry. Didn't have this problem last week. >_>

On 20 Mar 2010, at 07:10, Giles Lean wrote:

> I have horrible fears that somewhere down this path, we'll end up
> wanting equivalent functionality to terminfo and {n,}curses.

Aye, a full-featured term package will require ncurses, it's the only
thing with some available support for all current X-terminals if
nothing else. Any fresh solution will either appear broken on some
terminals or will require a fresh terminal database to be maintained.

I won't say any more because I personally view it as quite astounding
that new virtual terminals are still being developed. I think I'd
rather develop a custom line protocol than use ncurses!

--
Simplicity does not precede complexity, but follows it.
-- Alan Perlis

[Ostsol]

The wide range support for various terminals comes from a package
within ncurses called terminfo, which (at least in Ubuntu) does not
seem to come packaged separately from ncurses itself. Terminfo's
data, however, is stored as a set of files, so it is conceivable that
one could create functionality to read them and use them, and thus be
able to support the same variety of terminals with a more modern and
Go-like API than ncurses.

-Daniel

[atomly]

I'm pretty sure Ken Thompson (ed) and Rob Pike (sam, acme) know a little something about writing editors...

--
:: atomly ::
www.atomly.com :: ato...@atomly.com
+1.676.575.9782 :: +49.176.65941389
+1.888.8ATOMLY :: +1.347.69ATOM1

> Are people interested in having a...

To unsubscribe from this group, send email to golang-nuts+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

[Ethan Grammatikidis]

On 20 Mar 2010, at 15:51, atomly wrote:

I'm pretty sure Ken Thompson (ed) and Rob Pike (sam, acme) know a little something about writing editors...

Aye, and that list reminds me of Plan 9 which has been kept scrupulously free of tty control codes and char-cell display support altogether.

[jkwon...@gmail.com]

I just made a little color formatter thing.
https://github.com/jaekwon/go-prelude/tree/master/colors

fmt.Println(Yellow("Inside yellow is ", Red("red text"), " and ", Blue("blue ", Cyan("(and cyan) "), "text"), ". This is still yellow."))
prints: Inside yellow is red text and blue (and cyan) text. This is still yellow.

- Jae