I freaking love this library! It reminds me of a time that I don't even know happened when computers seemed like a scifi possibility come true. So happy to see it on the front page.
One of the coolest things is not just the ability to pipe cat outputs into it, but that it doubles up as a python library- next time you're making a throw away CLI with print outs and prompts, why not make it insanely jazzy?
I agree, a serious tool should be taking into account the length of the output delay and reducing effects to match the conditions. But you can still do some of it, sometimes.
On the contrary, I am currently scaffolding out the template projects for a new system at $DAYJOB and I'm seriously considering putting it in the CLI tool template.
On the one hand, these tools are going to be used for Serious Business™ but on the other hand... I owe it to 14 year old me. I'll probably add something to allow disabling it with a flag file that can be created with the tool or manually. ¯\_(ツ)_/¯
I’ve no idea what I would really use this for, and yet it’s one of the coolest things I’ve ever seen. My eyes are forever improved from having seen this.
As soon as the VHS effect goes out of fashion in PS1 style indie horror games, the community will move on to C64 style cassette loading sequences… on steroids.
A few years ago, a submarine cable was knocked out, between our startup's MVP servers in Singapore AWS, and our networked factory stations in Asia.
In lieu of the submarine cable, something closer to a wet string was being routed over. It had such high latency and packet loss, that a watchdog timer I'd implemented on the stations was timing out.
Fortunately, the remote access we'd built into our stations (SSH and OpenVPN) still worked, albeit at slow speeds, like a 300 baud dialup, and crazy-high latency.
Having occasionally dealt with performance a bit like that as a kid, and knowing my way around Linux, it was like "I've been training my whole life for this moment."
So I just flexed the old command-line-and-editor-when-you-feel-every-byte-transmitted skill, and got the stations working, before the factory even knew about the submarine cable, saving our infinite-9s uptime.
It was nothing compared to what NASA does, but terminal animation effects would've ended both of our missions.
I'd take a solid 300 baud connection over a spotty cellular connection during most emergencies.
Having worked and played on flaky high-latency and low-throughput networks much of my life, I mostly visualize things in my head—as you likely mean by 'command-line-and-editor-when-you-feel-every-byte-transmitted'. Open a connection and queue your commands; wait for output. It works if you don't make any typos.
Preferably, when the connection is too slow or flaky (bad cellular), I make a local script and echo the script to be executed remotely to a file on the remote server, and then execute it with nohup - with the input to create the script and execute it coming from a pre-made file on my local machine redirected to SSH.
Bad cellular often works in bursts, in my experience. Also, redirect output to a file if needed.
This works nicely in situations where your connection may drop frequently for periods exceeding timeouts. On that note, keep ssh timeouts high. With really spotty cellular you might have the network drop for 5-15 minutes between reliable transmissions. SSH connections can stay alive nearly indefinitely if the timeouts allow for it and IP address don't change.
> local script [...] nohup [...] redirect output to a file
mosh hostname -- screen -S philsnow
I don't think I've had to use this over a truly terrible connection, but mosh worked a treat a ~decade ago while tunneling through DNS from a cruise ship that charged exorbitant rates for wifi while underway, but which allowed unlimited DNS traffic.
> It works if you don't make any typos
mosh helps a bit with that too: you get local predictive echo of your keystrokes and you can't "recall" keystrokes but you can queue up backspaces to cover up your typos. Doesn't help where a single typo-ed keystroke is a hotkey that does something you didn't want, though.
I did something similar once when something broke while I was on a plane. The plane wifi was blocking ssh (I HATE when they do this) so I opened up an existing digital ocean instance, sshed into my home computer from it via the web interface, then uploaded some large files from the home computer and did a kubectl apply. The latency was insane but luckily the file upload was fast since my home connection is fast.
It was fun to think about the path each packet was taking - from my laptop to the plane router, to a satellite, back to a digital ocean computer in the UK, to my home computer in NJ, and back. It wasn’t as bad when you think about the magic there.
Smart, and not something someone would realize if they'd been too insulated from how things work.
Regarding planes/cafes/guest/etc. WiFi, I now usually put any "emergency remote plumbing access" on port 443 (though usually not HTTPS), to reduce the likelihood of some random non-SPI ruleset blocking us in an emergency.
I think that by 2050, 443 will be the only port used by applications that require a non local connection, because the chance that some participant in the network has blocked any other port is simply too high.
Nothing like typing in an ssh prompt and each time you press a button on the keyboard you have to wait a few seconds for the char to appear on the screen, because it has to go to the server and back first... that't the true "blind typing" :)))
That needs a binary to run on the remote host for protocol support, doesn't it? I wonder how long that'd take to get transferred and running, over as slow a link as it sounds like this was.
Since you can reach the host, presumably it has some kind of access to system updates / packages. In that case, ideally you paste a command like "sudo apt update && sudo apt install -y mosh\n" or something. You can even paste the newline at the same time and save a round-trip.
It isn't perfectly clear even in the detailed description whether any other link was available, but I tend to suspect that if anything faster had been, then it would have been used in preference to the one that actually was.
It's a cable going between entire countries that got cut. Anything inside the country should still be full speed.
There is no link that could be used in preference. Any repo that the factory stations could access would be unusable by Singapore AWS. And any repo that Singapore AWS could access would be unusable by the factory stations. But the two ends of the link don't have to use the same repo.
"Be specific" sounds like a high-stakes interview, so I'd better answer. :)
* SITUATION: Factory reports MVP factory stations for pilot customer "not turning on" for the day, reason unknown.
* TASK: Get stations up in time for production line, so startup doesn't go out of business.
* ACTION: Determined cause was unexplained networking problem outside our control, and that was triggering some startup time checks. But that the stations were resilient enough that I could carefully edit the code on the stations to relax some timeouts, and enough packets were getting through that we might be able to operate anyway. After that worked for one station, carefully changed the remaining ones.
* RESULT: Factory stations worked for that production day, and our startup was therefore still in business. We were later advised of the submarine cable failure, and the factory acknowledged connectivity problems. Our internal post mortem discussions included why the newer boot code hadn't been installed, and revisiting backup connectivity options. From there, thanks to various early-startup engineering magic, and an exciting mix of good and bad luck, we eventually finished a year contract in a high-quality brand's factory production line successfully.
No technical wizardry in the immediate story, but a lot of various smart things we'd done proactively (including triaging what we did and didn't spend precious overextended time on), plus some luck (and of course the fact that some Internet infrastructure heroes' work had them routing any packets at all)... all came together... and got us through a freak failure of a submarine cable we'd never heard of, which could've ended our startup right there.
(Details on Action, IIRC: Assumed command of the incident, and activated Astronaut Mode manner. Attempted to remote access, and found network very poor. Alerted factory of network problem in their connectivity to AWS Singapore, but they initially thought there was no problem. Could tell there was some very spotty connectivity problems (probably including using `mtr-tiny`), so focused troubleshooting stations on that assumption. Realized how the station would behave in this situation, and that the boot-ish checks for various network connectivity were probably timing out. Or, less likely, there could be a bug in handling the exceptional situation. Investigating, very slowly due to poor Internet, found that the stations didn't have the current version of the boot code, which would've reported diagnostics better on the station display, so factory personnel might see it and tell us. Using `vi`, made careful, minimal changes to the timeouts directly on one station, in the old version of the the code on there (in either Python or Bash; I forget). Restarted station, and it worked. Carefully did the same to the other stations. Everything worked, and other parts of the station software had been done smart enough that they could cope with the production day's demands. Despite the poor connectivity, and the need to do network requests for each production item that passed through the station, before it could move on.)
What I'd really like to see is this supported in the terminal emulator itself as an idle mode, i.e. don't run this in the buffer directly, but rather as a second buffer. This could function like a "screen saver". Once you interact, your primary terminal would be fully restored.
I was thinking about how fun it would be to add this my Python CLI [0] I made for launching Fedora CoreOS locally with QEMU for testing ignition, but with a flag that is turned off by default. Using the burn effect in TTE when launching a VM with my CLI would be so cool.
This instantly reminded me about Ansible and how it annoyed me that ANSIBLE_NOCOWS had to be enabled to disable the default output of Ansible with cowsay [1].
How serious it is, and how seriously the people who make decisions take it, are if not strictly orthogonal then certainly not guaranteed to closely correlate.
On a further tangent, that reminds me of two of my favorite things to install on a Linux system, ponysay and ascii-pony/systempony. I set each of my systems to a different character to show on bash logins with systempony (WSL instances included)
A while back I install ponysay on one of my servers, and put fortune | ponysay in the .bashrc, so I get a quip from a random mlp pony whenever I log in. Brightens my day a little
Deployment scripts are what come to mind for me. I wouldn’t mind a cool loading screen that highlighted problem nodes in the burning font or something when I deploy to dev / test / hell, maybe even prod.
Anything that downloads from somewhere, eg rsync, wget, package managers, etc.
Anything that compresses or decompresses archives, like gzip/gunzip, tar, etc.
Anything that performs longer running recursive disk activities, like du, find, etc
I’m sure there are plenty more scenarios I haven’t thought of. Though to be clear, I definitely don’t want to see this as a default enabled option in any of these.
If things are working well, they are automated and I rarely see the real time output.
If I’m looking at real time output, it’s because I’m doing something manually because something isn’t working the way it’s supposed to, and I’m in no mood for anything that doesn’t help me understand and address the issue.
This work is impressive. I love it. For some reason I really like “printer.” I’d be all about it for games or toys. But too many tools for real work try to do cute Unicode things or fancy colors or animations. I don’t need it on anything I will ever have to develop or troubleshoot, personally. After the first lengthy wait for a broken container to come up, I’m well over the colorful attitude.
I deliberately mentioned stuff that people are likely to manually run on local and healthy systems. But yeah, I agree with you that the novelty of this stuff wares off quickly.
An example of this done well would be ‘pacman’ package manager where an Easter egg can be enabled to turn the progress bar into a little Pac-Man gobbling pills. It’s not there by default, but it can be enabled if you know how.
Personally, I’m in the same camp as yourself where I’d prefer our tools didn’t have all this cutesy stuff. But people like us seem to be a dying breed.
It could be cool for GUI programs, when run from a terminal, to show a terminal loading screen parallel to the gui loading screen. Totally unnecessary, but cool.
As a product engineer, I'd love the attention to detail much more when placed toward changes that improve my ability to sustain velocity, than when toward changes that actively cut against that.
In the old days, some software would actually check the terminal's baud rate (which you can see with 'stty') and behave differently on slow links. For example, vi would restrict itself to fewer lines of the screen so that drawing a new page didn't take as long.
Although I don't know if much software does it, that should still be possible to do it, so these animations could theoretically be auto-disabled on slow links. (And you could manually override the baud rate in your mosh terminal if necessary since it doesn't really have any other effect in a virtual terminal, not like when using an actual serial port, I mean.)
It shouldn't matter, should it? Mosh keeps the state and only sends the differences. You would miss most of the animations, and there would be the overhead of sending the colouring escape codes (a few percent extra), but other than that, it wouldn't be any slower than an unanimated version that I can see.
Imagine that the CLI tool you use most often every day - a compiler, a package manager, like that - adds animations like these in common operations. Now you have to wait for the animation to finish before you can continue your work. How do you feel about that?
It's not grumpy to prefer function over form in a tool. People optimize for different things. GP's comment is reasonable; they're optimizing for something different than you.
Those of us who live in the terminal do it because it's the fastest, most convenient option, not because it's pretty or to appear 1337. Animations like these get in the way. Cool project, but I would never use it.
Yeah. Animations covering time that'd be spent either way I see no problem with, so long as it's obvious the time would be spent either way. Animations that waste my time, not so much.
Better than either, of course, would be effort spent on speeding up the build in the first place. I realize that's less fun, though.
In general, the critical development path is not a place to thoughtlessly add friction.
?? Why would I imagine that? What does this have to do with using animations in production? What you are saying is "how would you feel about using animations in inappropriate places?"
> What does this have to do with using animations in production? What you are saying is "how would you feel about using animations in inappropriate places?"
Production will always be an inappropriate place. QED.
> The idea that anyone would use this during "common operations" is laughable
It's been a while since I dared assume anything at all was so obviously absurd that no one could ever think to do it - not least since significant portions of my career to date have consisted of cleaning up after people who had.
Prod should be as robust and straightforward as possible; no distractions, no noise, no extra overhead. This is neat, but not useful, and it adds distractions and delays.
Back in the day (around 1990) I implemented a gif-like effect for terminals, which happened to be old monochrome hardware terminals on slow (9600?) RS-232 ports, attached to a venerable PDP-11.
It took several text files with ASCII "pictures" (character data only, no control codes, 80x24) as animation frames, and calculated simple per-line "diffs". Then it generated a sequence of cursor movements to only update the affected areas, skipping large parts of the picture.
That made it much faster than the naive overwriting the whole screenfuls from top, with a visible delay between parts of the screen. My version was able to run "simultaneous" small animations quickly at distant parts of the screen, because they took very few bytes to navigate to and update.
*
*.
* o/
-/M
_H_
E.g. a "juggler" like this could juggle quickly, inside a mostly stationary "circus", with "flags" waving high above on top of it.
With current terminals giving you 60fps in true-color mode, it makes little sense, of course.
Not redrawing the parts of the screen that don't need to be redrawn. There's going to be a tradeoff between the amount of works the terminal has to do parsing the input stream, the amount of work the terminal has to do to redraw/update its own buffer, and the amount of work necessary in the program to compute the necessary move commands.
To be fair, the effects shown here update such a significant part of the screen that tracking the diffs might be bigger overhead than a full-screen refresh
This is cool! we can utilize the 'Burn' or 'ErrorCorrect' effects to highlight warnings or errors in logs dynamically, ensuring critical issues stand out in ongoing terminal output.
Haha..I get where you're coming from. However, tool that show reports and outputs, that are CLI-first, can get a lot of help in improving the developer experience. Honestly, I was looking for something like this for my tool!
All gorgeous, but I'd like to see more quick/simple ones like 'Expand' because the slower ones would probably become tedious real quick after the initial novelty wears off.
Dev here: I agree, it's actually a line item in my todo list. That being said, many of them can be made to be very quick via command line arguments without losing the spirit of the effect.
I have not implemented gravity, haha. I have actually worked on a custom terminal game engine in the past and realized with TTE I am very small amount of scope creep away from landing in that territory again. I promised myself I will not implement physics or collision. Keeping it simple. That being said, as with the example pour syntax above, all of the effects have a ton of config options to allow for most obvious variations.
Wow - this is very cool and gives me strong nostalgia for Commodore-64/128 demos and old-school BBS's. I remember spending hours on my Commodore 64 doing this sort of thing by hand for the little BBS that I ran out of my bedroom.
Incredibly goofy, I like it. Especially the demo gifs on the page. Wonder how long until I see it be the default output for a CLI I'm using. Got surprised to see someone using lolcat in the wild before.
That's nice, but can we add a feature to terminals that actually understands what it shows and can post-process/augment the data? E.g. when `curl -v` dumped 10k json, the terminal would be able to prettify it right in the terminal. When there's an output with seemingly table data, it would be able to show it as a table with sorting, aggregations and export functionality. If it's code, do some syntax. Logs? - collapse long lines and highlight the parts of them.
I believe what you're looking for is Jq for the json prettifying/manipulation, and nushell for tabular text (not sure about that one, I've only seen it mentioned occasionally).
I strongly believe this should not become the job of the terminal, as it makes it all the more complicated and would possibly deter people from writing the kind of specialized, portable tools that are Jq and nushell for instance.
At most, I think it should be a job for an ncurses application
Everyone is free to not use this feature when it eventually implemented in terminals. Just like syntax highlighting, code completion and AI copilots.
The thing is that as a heavy user I do use jq, terminal triggers and my own stdout colouring/parsing apps that e.g. highlight and parse timestamps or numbers. It all kinda works via endless Cmd+C, "pbpaste | jq" etc but it feels wasteful.
I want to interact with what terminal shows me, not just look at it and copy/paste with broken formatting to somewhere else.
It also has one of the best user-interfaces of a text-based roguelike ever. And when I say "interface" I don't just mean the graphic design, although that's amazing too.
Very cool! But I’m just a bit sad that this is “just” a set of effects implemented on top of the same old standard ANSI escape codes as primitives.
I’ve been waiting for one or more terminal emulators to get together and add some ridiculous new escape codes, such that animated effects (or things like collapsible sections, font size, “form-input-ness” and “form-button-ness” ala 3270, etc) all get treated as part of the state of a given character cell / run of character cells.
Heck, it’s 2024; an application should be able to use an escape code to set a soft-word-wrap mode for longer-than-viewport-width text, and have the TTY render text accordingly, rather than everything being hard-wrapped (baked mode) or not wrapped at all (raw mode) and only being able to get soft-wrapping using a pager!
(There’s precisely one thing like this I’m aware of terminal emulators adding in recent memory: clickable links, ca. six years ago.)
> (There’s precisely one thing like this I’m aware of terminal emulators adding in recent memory: clickable links, ca. six years ago.)
And they are often disabled by default, as a potential security risk. We don't get to have fun things, do we? (also worth read: CVE-2003-0063, abusing escape seq is unfortunately a valid concern against adding more stuff).
On the other hand, more and more emulators are adding support for various graphic protocols (sixel, iTerm2 format, kitty format).
> I’ve been waiting for one or more terminal emulators to get together and add some ridiculous new escape codes[...]
Well, it's not much, but mintty apparently has some interesting stuff like audio support[0], and codes for font size and font family[1][2].
iTerm2 also has a bunch of custom escape sequences of varying level of usefulness starting from displaying fireworks animation on cursor position to sending system notifications[3] (although sadly I could not get the last one to work for me).
For some semblance of forms, you can check bubbles[4] and gum[5] (binary to easily incorporate the components into shell scripts).
> And they are often disabled by default, as a potential security risk.
Well, that and a clickable link would conflict with mouse reporting if both were active at once.
Given that mouse reporting exists, and "has precedence" due to its age, I think iTerm's choice — to style the anchor-SGR text either way, but to only make them actually act like links rather than text if you hold a modifier key — is the only "correct" behavior for rendering anchor-SGR text, regardless of security concerns.
But that really wouldn't be true for most other potential novel graphical-rendition "styles." Anything that's non-interactive could certainly be on by default.
> [...] waiting for one or more terminal emulators to get together and add some ridiculous new escape codes [...]
I'm definitely of the opinion[0] that we haven't yet reached the limits of the "terminal emulator" UX paradigm.
The past few years do seem to have seen a resurgence in terminal emulator innovation due in part to a combination of new languages, the prevalence of GPUs, and a realisation that many of the existing terminal emulators weren't interested in any innovation in certain directions.
I've particularly been interested in the possibilities provided by the Terminal Graphics Protocol (which I discuss more in the linked comment).
A couple of years ago I switched to WezTerm[2] due to a combination of its graphics support, implementation language (Rust) and that its main developer seems to be interested in a combination of both solid support for existing standards & opportunities for innovation.
WezTerm also provides opportunities for customisation both in terms of shell integrations and of the application itself[3].
> [...] new escape codes [...]
Also, on this aspect, it may not even be necessary to create new escape codes--recently I discovered the `terminfo(5)` man page actually makes a pretty interesting read[7], in part because it lists some existing escape codes that seem like they have potential for re-use/re-implementation in the current day's more graphic-based systems.
---- footnotes ----
[0] As I mentioned in a recent comment on a thread[1] here:
"Motivated by the thought that at the current point in time perhaps the 'essence' of a 'terminal' is its linear 'chronological' presentation of input/interaction/output history rather than its use of 'text'."
[3] While I'm definitely not a fan of the choice of Lua as the extension language, I have now at least hit my head against the wall[4] with it enough that I can actually get more complex custom functionality working.
[4] I've started to write up some of my Lua-related[5] notes & more general WezTerm[6] notes so hopefully it'll eventually be an easier road for others. :)
[7] As one does. :) It was a fascinating/amusing time capsule in terms(!) of mentions of weird hardware terminal quirks that at one time ("before my time") needed to be worked around; interesting escape code discoveries; and, the mention of a term I had not thought of for decades but was at one time of importance: NLQ! :D
> [0] As I mentioned in a recent comment on a thread[1] here:
> "Motivated by the thought that at the current point in time perhaps the 'essence' of a 'terminal' is its linear 'chronological' presentation of input/interaction/output history rather than its use of 'text'."
I somewhat object to this.
If you think of a TTY/PTY as an Abstract Data Type, it's a very specific (and clever) one. It's not just a transcript of bytes that flowed through the wire.
Rather, a TTY/PTY is five distinct but inter-related things:
1. a (passive) character-cell viewport grid, of (at any given time) a fixed size, where each cell holds not only a character as data, but also a set of metadata/annotations attached to it (the particular metadata being dependent on the implementation)
2. an active "brush" state for the viewport grid — this includes things like a cursor position, an active foreground and background color, etc.
3. a byte pipe "but better" — in that it's actually a multi-subscriber byte message-queue, plus (only in baked mode) message persistence into an expandable ring buffer, with logical line-oriented consumer-group cursoring to trigger forward-truncation of said buffer
4. a rendering agent with a rendering ruleset (or, in old-school TTY terms, a "line discipline") that sits as one consumer of the byte pipe; reacts to characters in the byte pipe by writing them to the cursor position in the viewport grid; and reacts to in-band messages by manipulating the "brush", making big changes to the viewport grid (e.g. clearing it entirely), and/or swapping out the rendering ruleset itself
5. (the part everyone forgets about) a replay stream-conversion function, that can convert the current state of the viewport grid + its brush, into a stream of characters + in-band messages, such that the rendering agent would parse that stream back into the current viewport + brush state
The clever function you get from this set of components, can be seen in the case of attaching a "client" TTY/PTY to an existing persistent "server" TTY/PTY, such as is created by something like tmux or docker — or even by /bin/login on an old-school terminal server that you've dialed into.
When a client like telnet, ssh, docker-exec, tmux-attach, etc. attaches to an existing backing PTY (either locally or remotely), the client either establishes its own "replica PTY" or reuses the one it's running attached to, and then wants to establish replication from the backing PTY into this replica PTY.
To get a coherent replica, that doesn't just paint garbage at a random position with a random brush, several things need to happen:
• the client needs to reset its own local PTY a known-neutral brush state;
• the client needs to set an ACK position in the byte-stream, and a memorized brush state, for the remote PTY (usually both of these are done implicitly by the syscall on the remote end that opens the PTY for reading);
• the client needs to fetch from the backing PTY, an implementation-neutral byte stream representing the current contents of the character viewport grid of the PTY — and replay that (i.e. it needs to trigger the replay stream-conversion function) — this also happens implicitly, such that when the remote end open(2)s its its PTY, the current state is serialized and dumped into a buffer for read(2)s on the PTY to read;
• the client needs to set up its local terminal's brush to match the memorized one that was set as of its ACK position on the remote.
Once these four things happen, the client can in theory simply shunt the remote PTY's byte-pipe into the local PTY's byte-pipe, select(2)ing and write(2)ing in a loop on a thread; whereupon the local PTY's rendering agent will handle reducing that stream to the visual grid.
In practice, though, the rendering rules / line disciplines / syntaxes of local vs remote PTY aren't guaranteed to match (especially if the local PTY is actually a real physical TTY); and so in practice, clients doing PTY replication like this actually have their own translation function — logic that acts as a hybrid of a rendering agent and a replay stream-conversion function, taking the byte-stream from the remote, reducing it into a model of immediate state-change effects, and then re-serializing those immediate state-change effects as a byte-stream that the local PTY/TTY will understand. (With the first half of this usually being app-specific code, and the second half of this usually being done using some version of libcurses, to know exactly what rendering-rule syntax the local PTY/TTY claims to understand.)
---
Given all that, you could generalize a TTY/PTY to something other than "text". I've often myself considered a PTY where the "lines" are each (a binary, minimal encoding of) HTML body markup; or even where the "lines" are JSON-encoded log events with parent-node-IDs, and the "rendering" is of a default-collapsed hierarchical event history.
But you'd be losing a lot if you didn't bring across the concept of there being a message-stream + a "canvas" + a brush-state for that "canvas" + rules for two-way conversion between the message-stream and "canvas." Without the stateful canvas, you would need an unlimited-size transcript — and potentially hours of replay — to be able to "attach" a client to an existing backing PTY.
Does anyone know why the "ColorShift" style doesn't animate as shown? When I run this each row cycles through colors from top to bottom, but there is no left to right / right to left color change at all. That's the only style not rendering correctly among 10 different ones I tried.
Just applied to /etc/profile.d/ to all SSH servers in my team. I also added some conditionals so that it only runs on interactive shells, doesn't run in sudo -i or tmux/screen, and it only runs once per day per server.
Im really impressed how snappy it is, i played with it localy a bit cause you never know how the screencast was made etc;
I can confirm this looks just as good as the video, well done
I love terminals, but I have to say, I kind of hate this sort of thing? Where you need at least 256 colors, GPU acceleration, and 240 columns x 80 lines? At that point it's just a curiosity, anywhere you could do that in a terminal you could do it easier and better in a graphical window. I want my terminal apps to actually still work in an 80x24 monochrome VT220 at 19200 baud. I want them to use termcap instead of hardcoding xterm's extensions to ANSI.
As a former ASCII / ANSI artist, I wish this thing existed like 20 years ago and could make exportable animations for all my BBS needs. Can't wait to tinker!
One of the killer features of terminal for me is that it's always clean and polished without fancy animations. You can possibly use transparency but that's more than a visual effect, it can actually be useful to let you see what's happening in a background window.
So while technically amazing, I do hope these text effects will never land in real world application, unless it's related to video gaming.
Haha, a matrix effect is actually in progress. I want it to be as close to the original as possible. Most implementations actually miss some subtle details. I've watched the original effect in a clip repeatedly and it has surprised me with its complexity beyond what I originally thought. Sometimes the characters shift in place but other times the entire column drops. The top characters in a given column change brightness in interesting ways, too. It'll be in a future release, for sure.
I had a broad smile on my face while going through the effects. This is so playful and fantastic!
The fact that it comes with a command line tool makes it a lot more useful to play with. I can imagine this being used for short pieces of text and to make “hacker” scenes for others.
Now I want an ASCII Art generator built into this! :)
These are really cool, and I wish I could have used them when I ran a dial-up BBS. (Although I don't know if 14.4k or 28.8k were fast enough to handle these.)
But, if you're going to go through the trouble to use these in a command-line program, why not make a GUI?
Ours had PS-2s on a token ring network with a TUI to get to the word processor etc but it also had a “drop down to DOS” option that the teachers didn’t know about.
Barring a zoomed screenshot that shows otherwise, I'm quite certain it's per-character. Operating in true color mode is what makes the color transitions smooth enough to make the optical illusion work.
Amazing, does this type of thing exist for like my website that i can use in a css or something i can import? What a cool style... or if it doesn't exist how might we make something like that?
That was my first thought seeing the headline, but they are really clever. My first thought looking through the examples was that I wouldn't mind a progress bar that uses the swarm effect.
Next time someone donks Python for being incapable of building decent CLI tools, I'll burn their terminal using TTE.
I know Go has the crown for creating TUI apps, but Python isn't that awful. If the app doesn't need concurrency (like a terminal file manager [0] does), then Python is fine.
[0]: Yazzi (Rust) eats Ranger's (Python) lunch and dinner combined.
One of the coolest things is not just the ability to pipe cat outputs into it, but that it doubles up as a python library- next time you're making a throw away CLI with print outs and prompts, why not make it insanely jazzy?