00:43
lizmat joined
|
|||
patrickb | I'm wondering: Terminal-Print is only using a hand full of commands. My impression is that in today's time terminals are pretty much standardized. Could we just hard code the VT sequences for those few commands? That would rid us of our dependency on tput, curses and termcap/terminfo. | 14:19 | |
Oh, ab5tract is not lurking here... | 14:20 | ||
japhb | I have co-maint on T-P, FWIW. | 15:22 | |
Personally I have no objection to hardcoding the ANSI sequences, but that doesn't actually obviate tput without changing the architecture a bit -- there still needs to be a way to pull the terminal size. | 15:24 | ||
patrickb | Hi japhb! Always nice reading you. | ||
japhb | :-D | 15:25 | |
Ditto | |||
patrickb | Btw. I have changing the PTY size implemented. Next on my list: Porting all of the Terminal stuff over to Windows. | 15:26 | |
japhb | So ... T-LE and T-W just directly query the terminal for its size, but T-P wasn't originally written with query capability, and was output only. The ability to handle input at all was added later, but T-P remained procedural rather than event driven in general. | 15:28 | |
Go patrickb! | |||
(Of course, under *nix you can ask the terminal *driver* via API about the current terminal size, but that requires POSIX, so was considered less portable.) | 15:30 | ||
Your efforts to switch out Term::termios for Terminal::MakeRaw indicate it would probably be viable to just do the same thing with the terminal size API anyway .... | 15:32 | ||
The terminal landscape is indeed rather different than it once was. At this point I guess there's only ANSI for in-stream commands and POSIX or Windows for out-of-stream API. | 15:33 | ||
patrickb | Yes, I'd think the same. | 15:53 | |
japhb | Responded to your set-span-sgr PR | 23:00 | |
patrickb: ^^ and also: Want to make a Terminal::Size module or so? | 23:01 |