17 Oct 2024
patrickb Oh, there also a Terminal-Widgets TerminalEmulator.rakumod widget. 21:43
Next immediate todos: Implement changing the PTY window size and making it work on Windows, MacOS, OpenBSD. 21:45
18 Oct 2024
japhb Wow, patrickb, Awesome work! 01:35
Geth Terminal-ANSIParser/main: 4acf3773ae | (Patrick Böker)++ | lib/Terminal/ANSIParser.rakumod
Allow terminating OSC strings with BEL as well

XTerm accepts it and applications send it. See
  invisible-island.net/xterm/ctlseqs...m-Commands
22:08
Terminal-ANSIParser/main: 35e21cd4e6 | (Geoffrey Broadwell)++ (committed using GitHub Web editor) | lib/Terminal/ANSIParser.rakumod
Merge pull request #2 from patrickbkr/patrickb-OSC-BEL-termination

Allow terminating OSC strings with BEL as well
Terminal-ANSIParser/main: 4 commits pushed by (Geoffrey Broadwell)++ 23:05
Terminal-ANSIParser/main: dd78c33cf9 | (Geoffrey Broadwell)++ | .github/workflows/test.yml
Drop CI testing for several-year-old Rakudos
23:08
Terminal-ANSIParser/main: d8173e5ea1 | (Geoffrey Broadwell)++ | .github/workflows/test.yml
Bump to actions/checkout@v4 to silence CI warning
23:12
Terminal-ANSIParser/main: 12e33683b1 | (Geoffrey Broadwell)++ | .github/workflows/test.yml
Disable Windows CI to debug CI failure
23:27
Terminal-ANSIParser/main: 1df98886c1 | (Geoffrey Broadwell)++ | 3 files
0.0.4
23:37
Terminal-LineEditor/main: f822e98c1c | (Patrick Böker)++ | 2 files
Make the dependency chain free of native code

This means that installing this module won't require a C compiler toolchain anymore. Do so by replacing Term::termios with Terminal::MakeRaw.
23:52
Terminal-LineEditor/main: 9b51c78938 | (Geoffrey Broadwell)++ (committed using GitHub Web editor) | 2 files
Merge pull request #6 from patrickbkr/patrickb/makeraw

Make the dependency chain free of native code
19 Oct 2024
Terminal-LineEditor/main: 8000547c7d | (Geoffrey Broadwell)++ | 2 files
Update copyright years
00:02
Terminal-LineEditor/main: 80a9bbd917 | (Geoffrey Broadwell)++ | Changes
Update Changes for Terminal::MakeRaw change
Terminal-LineEditor/main: 0fda5facfc | (Geoffrey Broadwell)++ | 4 files
0.0.17
00:04
6 Nov 2024
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
7 Nov 2024
patrickb I wonder whether it might make more sense to have a generic Terminal::API module or some such. Having separate modules for each bit of functionality feels a bit inflationary. 08:40
japhb patrickb: ab5tract and I discussed at one point doing a T::P 2.x, taking everything we'd learned and redesigning it. But I realized that I had a *lot* more to learn about terminals at the time, so I built up the functionality layer by layer as I managed to grok each new thing. 17:38
That way I didn't break anything anyone depended on when I went "Dang it, I'm going to have to do that differently." Which indeed happened when I realized I needed a real ANSI parser to handle terminal queries correctly, for instance. Faking it as T::P does only gets you so far. 17:40
I figure however that when T-W gets to "mostly there" status, it might be time to go and do that, with an opportunity to put afterburners on the performance. 17:41
(T::P isn't by any means slow for a pure-Raku module, but that doesn't make it near as fast as it could be.) 17:42
patrickb Hm. That puts a bit of a different perspective on my current project. 18:07
But I guess tackling a T-W rewrite now is a bit too big bite for me at the moment given that my actual goal is "only" to create a decent TUI debugger. 18:09
I got into a lot more deep holes than I expected...
already
What would you think is a good way forward for me currently? 18:10
Just continue getting the current stack into a workable shape and Delay the rewrite for later? 18:11
(I'm not implicating *who* is doing any rewrites, only when.) 18:12
japhb Oh, definitely delay. Rewriting the stack will almost certainly derail the actual app you're working on. It's a much deeper hole than I thought when I started on all this. 22:16