new terminfo parser

[taylorchu]

https://github.com/taylorchu/terminfo

I write a parser that parses entire terminfo file, so it gives more information in boolean and number part. This implementation also does not read in the whole file to slice to save memory.

I would like to remove custom hand-coded definition, and just use system-provided terminfo file. If system does not have terminfo file ready, termbox-go can copy existed terminfo to the project.

[nsf]

I don't like the idea of removing the fallback database. Why do you want to do so? It''s very small and doesn't hurt anyone.

And why do we actually need to parse all the terminfo? What kind of additional information termbox could use from it?

[taylorchu]

http://godoc.org/github.com/taylorchu/terminfo#Number
http://godoc.org/github.com/taylorchu/terminfo#Boolean

I just dont want to have a partial hand-coded definition from terminfo as fallback database. We can just copy some selected terminfo in /usr/share/terminfo/. They are complete, and we can solve desync problem by simply copying.

[nsf]

http://godoc.org/github.com/taylorchu/terminfo#Number
http://godoc.org/github.com/taylorchu/terminfo#Boolean

Yes, I know terminfo has various entries. Which ones are useful to termbox in your opinion? Because so far we use none of them and there are no problems with that.

What problem are you trying to solve? Desync problem is an imaginary one - features termbox uses were not changing for years.

[taylorchu]

just some general ideas on less hard coding.

for example,

termbox-go/termbox.go

Line 83 in 9057ff8

func write_sgr_fg(a Attribute) {

I am unsure that whether all terminals behave this way to this escape
code. A more certain way is to look up terminfo. However, we only get
a few codes from terminfo and assume that all the rest should be the
same across all terms.

I think it is better to respect terminfo more, and only guess if that
cap is not available.

non-string
has_meta_key
buttons
*_glitch
color related (max_color)

string
contains much more like fg, bg ..etc

On Fri, Aug 15, 2014 at 2:43 PM, nsf notifications@github.com wrote:

http://godoc.org/github.com/taylorchu/terminfo#Number
http://godoc.org/github.com/taylorchu/terminfo#Boolean

Yes, I know terminfo has various entries. Which ones are useful to termbox
in your opinion? Because so far we use none of them and there are no
problems with that.

What problem are you trying to solve? Desync problem is an imaginary one -
features termbox uses were not changing for years.

—
Reply to this email directly or view it on GitHub.

[nsf]

I am unsure that whether all terminals behave this way to this escape
code. A more certain way is to look up terminfo. However, we only get
a few codes from terminfo and assume that all the rest should be the
same across all terms.

Find one which doesn't.

My problem with terminfo is that it's a turing complete language in there. And I wanted to avoid this complexity at all costs. First, it was just a built-in database. I've collected it by installing all of the terminals I could find in my linux distribution and testing on all of them. Then @guelfey wrote a simple terminfo parser, which was okay for me, because it was parsing only the part which doesn't require any evaluation (like SGR stuff), so here it was. Initially it deleted the fallback database, but we found out, that there are actually people with broken terminfos and I decided to put it back in.

Using full terminfo database means for me accepting the bullshit terminals are. I want this to be over, not supporting it. In practice what I do - works, because most people use gnome-based, kde-based, xfce4-based terminals or a handful of standalone ones like xterm, urxvt, aterm, eterm, screen, linux console.

I think it's a much better idea to limit the amount of supported terminals, than adding effectively a scripting language interpreter into the library.

Unless you have a very convincing argument for full terminfo support, I'm not chaning things the way they are. I see very little value in adding it. The best it gives us - a way to figure out that things do not work. Well, it's nice to know that, but I'm sure users can figure that out. When things do not work - they do not work. I do not need a boolean flag which tells me so.

[taylorchu]

sorry for a side question. why is terminfo turing complete? it is just a
format.

On Fri, Aug 15, 2014 at 4:27 PM, nsf notifications@github.com wrote:

I am unsure that whether all terminals behave this way to this escape
code. A more certain way is to look up terminfo. However, we only get
a few codes from terminfo and assume that all the rest should be the
same across all terms.

Find one which doesn't.

My problem with terminfo is that it's a turing complete language in there.
And I wanted to avoid this complexity at all costs. First, it was just a
built-in database. I've collected it by installing all of the terminals I
could find in my linux distribution and testing on all of them. Then
@guelfey https://github.com/guelfey wrote a simple terminfo parser,
which was okay for me, because it was parsing only the part which doesn't
require any evaluation (like SGR stuff), so here it was. Initially it
deleted the fallback database, but we found out, that there are actually
people with broken terminfos and I decided to put it back in.

Using full terminfo database means for me accepting the bullshit terminals
are. I want this to be over, not supporting it. In practice what I do -
works, because most people use gnome-based, kde-based, xfce4-based
terminals or a handful of standalone ones like xterm, urxvt, aterm, eterm,
screen, linux console.

I think it's a much better idea to limit the amount of supported
terminals, than adding effectively a scripting language interpreter into
the library.

Unless you have a very convincing argument for full terminfo support, I'm
not chaning things the way they are. I see very little value in adding it.
The best it gives us - a way to figure out that things do not work. Well,
it's nice to know that, but I'm sure users can figure that out. When things
do not work - they do not work. I do not need a boolean flag which tells me
so.

—
Reply to this email directly or view it on GitHub
#45 (comment).

[nsf]

Just a quote from man terminfo:

       The % encodings have the following meanings:

       %%   outputs `%'

       %[[:]flags][width[.precision]][doxXs]
            as in printf, flags are [-+#] and space.  Use a `:' to allow the next character to be a `-' flag, avoiding interpreting "%-" as an operator.

       %c   print pop() like %c in printf

       %s   print pop() like %s in printf

       %p[1-9]
            push i'th parameter

       %P[a-z]
            set dynamic variable [a-z] to pop()

       %g[a-z]
            get dynamic variable [a-z] and push it

       %P[A-Z]
            set static variable [a-z] to pop()

       %g[A-Z]
            get static variable [a-z] and push it

            The terms "static" and "dynamic" are misleading.  Historically, these are simply two different sets of variables, whose values are  not  reset  between  calls  to
            tparm.  However, that fact is not documented in other implementations.  Relying on it will adversely impact portability to other implementations.

       %'c' char constant c

       %{nn}
            integer constant nn

       %l   push strlen(pop)

       %+ %- %* %/ %m
            arithmetic (%m is mod): push(pop() op pop())

       %& %| %^
            bit operations (AND, OR and exclusive-OR): push(pop() op pop())

       %= %> %<
            logical operations: push(pop() op pop())

       %A, %O
            logical AND and OR operations (for conditionals)

       %! %~
            unary operations (logical and bit complement): push(op pop())

Does it remind you something? A programming language description. So, the color setting you were talking about (SGR). In order to actually interpret everything terminfo can possibly have written in that field, one has to implement an interpreter for this little scripting language.

[taylorchu]

I see. I thought you mean the file format.

Maybe dropping terminfo is an extreme but better option :)

On Fri, Aug 15, 2014 at 7:04 PM, nsf notifications@github.com wrote:

Just a quote from man terminfo:

   The % encodings have the following meanings:

   %%   outputs `%'

   %[[:]flags][width[.precision]][doxXs]
        as in printf, flags are [-+#] and space.  Use a `:' to allow the next character to be a `-' flag, avoiding interpreting "%-" as an operator.

   %c   print pop() like %c in printf

   %s   print pop() like %s in printf

   %p[1-9]
        push i'th parameter

   %P[a-z]
        set dynamic variable [a-z] to pop()

   %g[a-z]
        get dynamic variable [a-z] and push it

   %P[A-Z]
        set static variable [a-z] to pop()

   %g[A-Z]
        get static variable [a-z] and push it

        The terms "static" and "dynamic" are misleading.  Historically, these are simply two different sets of variables, whose values are  not  reset  between  calls  to
        tparm.  However, that fact is not documented in other implementations.  Relying on it will adversely impact portability to other implementations.

   %'c' char constant c

   %{nn}
        integer constant nn

   %l   push strlen(pop)

   %+ %- %* %/ %m
        arithmetic (%m is mod): push(pop() op pop())

   %& %| %^
        bit operations (AND, OR and exclusive-OR): push(pop() op pop())

   %= %> %<
        logical operations: push(pop() op pop())

   %A, %O
        logical AND and OR operations (for conditionals)

   %! %~
        unary operations (logical and bit complement): push(op pop())

Does it remind you something? A programming language description. So, the
color setting you were talking about (SGR). In order to actually interpret
everything terminfo can possibly have written in that field, one has to
implement an interpreter for this little scripting language.

—
Reply to this email directly or view it on GitHub
#45 (comment).

[nsf]

Well, I don't want to drop it completly. I like what we have right now. A simple parser which parses only what we need and it all works nicely. There are areas which require some work. Mostly testing to see what's wrong and how we can fix it, e.g. putty and ssh usage on windows, but overall it all works just fine.