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 |