FYI: small terminfo changes

29 views
Skip to first unread message

Elliott Hughes

unread,
Sep 10, 2018, 3:41:24 PM9/10/18
to terminat...@googlegroups.com
i added support for ESC[?1047h, 1048, and 1049 and switched ti/te over to using them rather than the old skool combinations of ESC7 and ESC[?47h. i tested that vim and less correctly use the newer sequences, and that the behavior seems unchanged.

what's the difference? 1049 is a combination of the other two, and 1047/1048 differ from their historical equivalents in that xterm lets you disable them. [it turns out that "titeInhibit" is "terminfo ti/te inhibit", not some odd Americanism like "ez" or "lite".] given that we don't have titeInhibit (nor does it seem particularly useful to add, especially when you see that there's also an escape sequence to change the titeInhibit setting), and the escape sequences are the same length, what's the benefit? nothing really, except that i'm seeing more folks hard-code escape sequences these days on the assumption that everything's roughly xterm-ish for the basics, and they're more likely to use the modern sequences (presumably because they look at what vim does with TERM=xterm).

i also _removed_ is1 because i couldn't find any documentation of what it's supposed to do, and xterm doesn't have it. i left is2 because xterm does have that. (there's also an is3 according to the man page, but no-one seems to know what the differences between the three were meant to be.)

i also added support for the ESC [ \d SP q sequences for programmatically changing the cursor. this means we now support a bar cursor too, though i didn't touch the preferences if there's anyone who wants that to be their default. no corresponding terminfo changes.

i was also going to add bracketed paste, but i see mad beat me to it. (thanks!) unfortunately, nothing seems to realize we have it, and i don't see any way to declare it in our terminfo?

anyway, since there doesn't appear to be a supported way to get mail for each github commit, i thought i'd explicitly send out a heads up for these terminfo changes.

--

Phil Norman

unread,
Sep 10, 2018, 3:48:58 PM9/10/18
to terminat...@googlegroups.com
Good to know, thanks. Particularly since I still can't even build terminfo on bad, due to some assertion that some specific sequence must be present.

Is there any canonical place where terminfo is documented, with actual explanations for what different sequences mean and how they interdepend? I've not found anything useful along those lines; I have a feeling it might be useful.

Ta,
Phil

--
You received this message because you are subscribed to the Google Groups "terminator-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to terminator-use...@googlegroups.com.
To post to this group, send email to terminat...@googlegroups.com.
Visit this group at https://groups.google.com/group/terminator-users.
For more options, visit https://groups.google.com/d/optout.

Elliott Hughes

unread,
Sep 11, 2018, 4:07:51 PM9/11/18
to terminat...@googlegroups.com


On Mon, Sep 10, 2018 at 12:48 PM Phil Norman <phil...@gmail.com> wrote:
Good to know, thanks.

(i did introduce one bug; if you find your cursor is the wrong color when your window isn't focused, `git pull` again for the one-line fix.)
 
Particularly since I still can't even build terminfo on bad, due to some assertion that some specific sequence must be present.

which sequence?

(also, lol at "bad" for "bsd".)
 
Is there any canonical place where terminfo is documented, with actual explanations for what different sequences mean and how they interdepend? I've not found anything useful along those lines; I have a feeling it might be useful.

i often found that old AIX or Solaris documentation was good because they were old enough to have dealt with all kinds of ancient hardware. there's the man7.org terminfo page, and BSD has its own copy from the same (ncurses) source: https://www.freebsd.org/cgi/man.cgi?query=terminfo&sektion=5 

but, for example, if you look at the is1 vs is2 vs is3 example i was talking about the other day, you'll see there's bugger all of any use in there.

(while i'm here i'll mention that i `git clone`d vim last night to try to answer my bracketed escape question, and it seems like the answer -- for vim at least -- is that unless you lie convincingly enough that vim thinks you're a genuine xterm, your users need to explicitly enable this stuff by setting vim variables along the lines of internal terminfo entries. there doesn't appear to be a "proper" terminfo way to do things.)

Elliott Hughes

unread,
Sep 12, 2018, 1:59:33 AM9/12/18
to terminat...@googlegroups.com
On Mon, Sep 10, 2018 at 12:41 PM Elliott Hughes <elliott....@gmail.com> wrote:
i added support for ESC[?1047h, 1048, and 1049 and switched ti/te over to using them rather than the old skool combinations of ESC7 and ESC[?47h. i tested that vim and less correctly use the newer sequences, and that the behavior seems unchanged.

what's the difference? 1049 is a combination of the other two, and 1047/1048 differ from their historical equivalents in that xterm lets you disable them. [it turns out that "titeInhibit" is "terminfo ti/te inhibit", not some odd Americanism like "ez" or "lite".] given that we don't have titeInhibit (nor does it seem particularly useful to add, especially when you see that there's also an escape sequence to change the titeInhibit setting), and the escape sequences are the same length, what's the benefit? nothing really, except that i'm seeing more folks hard-code escape sequences these days on the assumption that everything's roughly xterm-ish for the basics, and they're more likely to use the modern sequences (presumably because they look at what vim does with TERM=xterm).

i also _removed_ is1 because i couldn't find any documentation of what it's supposed to do, and xterm doesn't have it. i left is2 because xterm does have that. (there's also an is3 according to the man page, but no-one seems to know what the differences between the three were meant to be.)

i also added support for the ESC [ \d SP q sequences for programmatically changing the cursor. this means we now support a bar cursor too, though i didn't touch the preferences if there's anyone who wants that to be their default. no corresponding terminfo changes.

i was also going to add bracketed paste, but i see mad beat me to it. (thanks!) unfortunately, nothing seems to realize we have it, and i don't see any way to declare it in our terminfo?

i've documented what i learned from reading the vim source in our FAQ: https://github.com/software-jessies-org/jessies/wiki/TerminatorFAQ#vim
 
anyway, since there doesn't appear to be a supported way to get mail for each github commit, i thought i'd explicitly send out a heads up for these terminfo changes.

--

Phil Norman

unread,
Sep 15, 2018, 5:14:02 AM9/15/18
to terminat...@googlegroups.com
On 11 September 2018 at 22:07, Elliott Hughes <elliott....@gmail.com> wrote:


On Mon, Sep 10, 2018 at 12:48 PM Phil Norman <phil...@gmail.com> wrote:
Good to know, thanks.

(i did introduce one bug; if you find your cursor is the wrong color when your window isn't focused, `git pull` again for the one-line fix.)
 
Particularly since I still can't even build terminfo on bad, due to some assertion that some specific sequence must be present.

which sequence?

$ tic -v1 terminator.tic 

"terminator.tic", line 8, terminal 'terminator': missing sgr string


Apparently it's for setting video attributes. In fact, looking at the documentation you linked on freebsd.org, it seems it needs to be a sequence of references to other escape sequences, to tell ncurses (or whoever) what the terminal supports in the way of underline, bold etc. It actually looks feasible to figure out a sensible value there. Thanks for the link.
 

(also, lol at "bad" for "bsd".)

Typical android/linux bias :-)
 
 
Is there any canonical place where terminfo is documented, with actual explanations for what different sequences mean and how they interdepend? I've not found anything useful along those lines; I have a feeling it might be useful.

i often found that old AIX or Solaris documentation was good because they were old enough to have dealt with all kinds of ancient hardware. there's the man7.org terminfo page, and BSD has its own copy from the same (ncurses) source: https://www.freebsd.org/cgi/man.cgi?query=terminfo&sektion=5 

but, for example, if you look at the is1 vs is2 vs is3 example i was talking about the other day, you'll see there's bugger all of any use in there.

(while i'm here i'll mention that i `git clone`d vim last night to try to answer my bracketed escape question, and it seems like the answer -- for vim at least -- is that unless you lie convincingly enough that vim thinks you're a genuine xterm, your users need to explicitly enable this stuff by setting vim variables along the lines of internal terminfo entries. there doesn't appear to be a "proper" terminfo way to do things.)
 
Ta,
Phil

On Mon, 10 Sep 2018, 21:41 Elliott Hughes, <elliott....@gmail.com> wrote:
i added support for ESC[?1047h, 1048, and 1049 and switched ti/te over to using them rather than the old skool combinations of ESC7 and ESC[?47h. i tested that vim and less correctly use the newer sequences, and that the behavior seems unchanged.

what's the difference? 1049 is a combination of the other two, and 1047/1048 differ from their historical equivalents in that xterm lets you disable them. [it turns out that "titeInhibit" is "terminfo ti/te inhibit", not some odd Americanism like "ez" or "lite".] given that we don't have titeInhibit (nor does it seem particularly useful to add, especially when you see that there's also an escape sequence to change the titeInhibit setting), and the escape sequences are the same length, what's the benefit? nothing really, except that i'm seeing more folks hard-code escape sequences these days on the assumption that everything's roughly xterm-ish for the basics, and they're more likely to use the modern sequences (presumably because they look at what vim does with TERM=xterm).

i also _removed_ is1 because i couldn't find any documentation of what it's supposed to do, and xterm doesn't have it. i left is2 because xterm does have that. (there's also an is3 according to the man page, but no-one seems to know what the differences between the three were meant to be.)

i also added support for the ESC [ \d SP q sequences for programmatically changing the cursor. this means we now support a bar cursor too, though i didn't touch the preferences if there's anyone who wants that to be their default. no corresponding terminfo changes.

i was also going to add bracketed paste, but i see mad beat me to it. (thanks!) unfortunately, nothing seems to realize we have it, and i don't see any way to declare it in our terminfo?

anyway, since there doesn't appear to be a supported way to get mail for each github commit, i thought i'd explicitly send out a heads up for these terminfo changes.

--

--
You received this message because you are subscribed to the Google Groups "terminator-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to terminator-users+unsubscribe@googlegroups.com.
To post to this group, send email to terminator-users@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "terminator-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to terminator-users+unsubscribe@googlegroups.com.
To post to this group, send email to terminator-users@googlegroups.com.


--

--
You received this message because you are subscribed to the Google Groups "terminator-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to terminator-users+unsubscribe@googlegroups.com.
To post to this group, send email to terminator-users@googlegroups.com.

Martin Dorey

unread,
Sep 15, 2018, 10:40:07 AM9/15/18
to terminat...@googlegroups.com
terminal 'terminator': missing sgr string

That's familiar.  Where was it?

...

You'll find the expert's answer as to what our sgr should be in:


Do please feel encouraged to go further in integrating Dickey's insights, especially now you have a concrete reason to make a change.

 
Ta,
Phil

To unsubscribe from this group and stop receiving emails from it, send an email to terminator-use...@googlegroups.com.
To post to this group, send email to terminat...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "terminator-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to terminator-use...@googlegroups.com.
To post to this group, send email to terminat...@googlegroups.com.


--

--
You received this message because you are subscribed to the Google Groups "terminator-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to terminator-use...@googlegroups.com.
To post to this group, send email to terminat...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "terminator-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to terminator-use...@googlegroups.com.
To post to this group, send email to terminat...@googlegroups.com.

Phil Norman

unread,
Sep 15, 2018, 10:58:22 AM9/15/18
to terminat...@googlegroups.com
On 15 September 2018 at 16:39, Martin Dorey <marti...@gmail.com> wrote:
terminal 'terminator': missing sgr string

That's familiar.  Where was it?

Trying to run 'tic -v1 terminator.tic' on FreeBSD (or FreeBAD as Android would have it).
 

...

You'll find the expert's answer as to what our sgr should be in:


Do please feel encouraged to go further in integrating Dickey's insights, especially now you have a concrete reason to make a change.

Wow, just copy/pasting the 'sgr' and 'sgr0' strings into our terminfo makes it compile fine. Excellent. Thanks very much for the pointer: that's saved me a whole bunch of time.

There are some other modifications too, including changing smacs and rmacs: I note that in our copy, there are two entries for smacs, the latter of which is the same as the debian version. I'm going to assume that duplicate entries are ignored (probably taking the last), and keep only the smacs conforming to the debian version, and I'll change the rmacs to the debian version too.

The other two changes in Debian are the removal of 'bce' and 'km'. Our version claims "We support back color erase (bce, I guess) since 2018-11-07", so I'm inclined to leave that as it is. The 'km' capability is "Has a meta key (ie sets 8th bit)", and I don't believe we do anything that sinister (it'd play havoc with utf8, after all, and we support that), so I'm going to nuke that one too.

OK, I'll get this submitted, and remove the bit of makefile that avoids running tic on FreeBSD.

Yay!

 

 
Ta,
Phil

To unsubscribe from this group and stop receiving emails from it, send an email to terminator-users+unsubscribe@googlegroups.com.
To post to this group, send email to terminator-users@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "terminator-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to terminator-users+unsubscribe@googlegroups.com.
To post to this group, send email to terminator-users@googlegroups.com.


--

--
You received this message because you are subscribed to the Google Groups "terminator-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to terminator-users+unsubscribe@googlegroups.com.
To post to this group, send email to terminator-users@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "terminator-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to terminator-users+unsubscribe@googlegroups.com.
To post to this group, send email to terminator-users@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "terminator-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to terminator-users+unsubscribe@googlegroups.com.
To post to this group, send email to terminator-users@googlegroups.com.

Phil Norman

unread,
Sep 15, 2018, 11:44:14 AM9/15/18
to terminat...@googlegroups.com
Bah, except I now discover (having actually done a make clean && make) that FreeBSD generates terminfo.db hashed binary files, instead of the dir structure Linux prefers. This is a compile-time option for tic, according to its man page, and seemingly not something that can be detected without running it and seeing what it does.

I've hacked up the makefile so if it see FreeBSD, it'll look for the terminfo.db file rather than the terminfo/... directory, and the 'make install' works correctly too, copying to $HOME/.terminfo.db.

If anyone knows of a prettier way to do this (maybe handling both nicely rather than having OS-name-specific hacks), then please feel free :-)

Cheers,
Phil

Phil Norman

unread,
Sep 17, 2018, 4:35:27 PM9/17/18
to terminat...@googlegroups.com
Of course, little did I expect that the terminator/bin/terminator script tries to install the terminfo, and fails if it can't find the .generated/terminfo/terminator file (which doesn't exist on FreeBSD, as it creates .generated/terminfo.db).

Even less did I expect that the 'show_alert' function (which was trying to print out the error about the missing .generated/terminfo/terminator file) has a specific list of actions for showing an error dialog on Windows, Linux and Mac, but for all other OSs it defaults to silently dropping the error message. Fixed both though - I now have an updated Terminator running from HEAD, with a terminfo.db compiled on the same machine, not copied over from Linux. And if it fails to start up, it'll now tell me.

Martin Dorey

unread,
Sep 18, 2018, 12:59:19 PM9/18/18
to terminator-users
silently dropping the error message

Ouch.  Looks like it's been like that since 2006, before which it was hard-coded to run zenity... which would have worked fine for you and at least have generated an error message for any other poor bugger.

I looked at your changes and didn't spot anything that made my coding finger itch except for one code-comment ~requesting that I do this:

 
Ta,
Phil

To unsubscribe from this group and stop receiving emails from it, send an email to terminator-use...@googlegroups.com.
To post to this group, send email to terminat...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "terminator-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to terminator-use...@googlegroups.com.
To post to this group, send email to terminat...@googlegroups.com.


--

--
You received this message because you are subscribed to the Google Groups "terminator-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to terminator-use...@googlegroups.com.
To post to this group, send email to terminat...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "terminator-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to terminator-use...@googlegroups.com.
To post to this group, send email to terminat...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "terminator-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to terminator-use...@googlegroups.com.
To post to this group, send email to terminat...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "terminator-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to terminator-use...@googlegroups.com.
To post to this group, send email to terminat...@googlegroups.com.

Phil Norman

unread,
Sep 18, 2018, 1:00:48 PM9/18/18
to terminat...@googlegroups.com
Oh thanks, I was hoping you'd do something like that.

Phil Norman

unread,
Sep 20, 2018, 8:49:20 AM9/20/18
to terminat...@googlegroups.com
On 10 September 2018 at 21:41, Elliott Hughes <elliott....@gmail.com> wrote:
i was also going to add bracketed paste, but i see mad beat me to it. (thanks!) unfortunately, nothing seems to realize we have it, and i don't see any way to declare it in our terminfo?

Aha! That might be what's been annoying me. Ever since... some unknown event months and months ago, if I paste a command into Terminator including a newline, bash doesn't immediately execute it. As someone who often composes commands in Evergreen to execute them by middle-button-pasting them, and who never pastes stuff into a terminal from a browser, this is really annoying. Many times I've spent minutes waiting for a program to start up, before realising bash is waiting for me to hit 'return'.

Is it the bracketed paste mode that's causing this? If so, maybe this should be an option. Or, if anyone knows a way of telling bash to ignore it and just execute immediately, please let me know.

Thanks,
Phil

Martin Dorey

unread,
Sep 20, 2018, 11:21:58 AM9/20/18
to terminat...@googlegroups.com
> Is it the bracketed paste mode that's causing this?

Very probably.

> if anyone knows a way of telling bash to ignore it and just execute immediately, please let me know.

The check-in comment, found by searching GitHub for "bracketed":


... suggests the same hint about turning it off as a quick Google did.  Interestingly different that it's on by default for you.

I've been meaning to have a go with Elliott's suggestion from 
https://github.com/software-jessies-org/jessies/wiki/TerminatorFAQ#how-do-i-disable-auto-indent-when-pasting-in-vim instead of the pathogen nonsense mentioned by the check-in comment, which still yaks when I start vim on other machines.  Looks like there's one vimrc insight from the check-in comment that wants hoisting to the FAQ though...

--

Phil Norman

unread,
Sep 20, 2018, 12:14:47 PM9/20/18
to terminat...@googlegroups.com
Not having known about .inputrc, I had tried 'set enable-bracketed-paste off' directly in bash, and that had no effect at all. Which is why my own google searches yielded nothing apparently useful.

Since then, I've learned that the correct fix is:

echo "set enable-bracketed-paste off" > .inputrc

I think 'bracketed paste' is probably on by default due to either some change in debian, or some company policy thing. Not sure which.

Cheers,
Phil

To unsubscribe from this group and stop receiving emails from it, send an email to terminator-users+unsubscribe@googlegroups.com.
To post to this group, send email to terminator-users@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "terminator-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to terminator-users+unsubscribe@googlegroups.com.
To post to this group, send email to terminator-users@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages