[HN Gopher] TTE: Terminal Text Effects
___________________________________________________________________
TTE: Terminal Text Effects
Author : makapuf
Score : 1687 points
Date : 2024-05-28 17:31 UTC (1 days ago)
(HTM) web link (chrisbuilds.github.io)
(TXT) w3m dump (chrisbuilds.github.io)
| tambourine_man wrote:
| This is awesome. Thanks
| devdao wrote:
| Love it, thanks for posting!
| jimbobthrowawy wrote:
| 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.
| PhilipRoman wrote:
| Great work, this will make a lovely splash screen for my tty-only
| machine.
| mickeyp wrote:
| In a similar vein in Emacs: M-x zone
|
| Every time you run it, it triggers a random screen saver effect.
| Fun when it's on a timer and triggers so your work colleagues
| wonder wth is going on.
| dmd wrote:
| I just get a blank emacs buffer when I run that.
| erk__ wrote:
| Even if you run it in a buffer that is already full with
| text? Zone mode only really works if you have text in the
| buffer.
| dmd wrote:
| ohhhhhhhhh
| wwarner wrote:
| dude thanks
| Exuma wrote:
| Or neovim ... cellular automaton
| mickeyp wrote:
| Emacs has game of life also. M-x life.
| gothicbluebird wrote:
| and animate.el by mister Stallman, see it in action with
| M-x animate-birthday-present
| gothicbluebird wrote:
| good one! The editor macros collection never ceases to amaze
| even after years of working daily in it.
| teddyh wrote:
| > _M-x zone_
|
| Available in the menu: Tools - Games - Zone Out
| nanna wrote:
| Thanks for everything you do for the Emacs community, mickeyp.
| I've learned so much from https://www.masteringemacs.org/
| behnamoh wrote:
| 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.
| benrutter wrote:
| 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?
| endgame wrote:
| It's fun for silly stuff, but I've definitely been on enough
| slow links that I wouldn't put it in a serious tool.
|
| EDIT: Don't get me wrong, I think it's really cool, but I
| wouldn't use it as a universal hammer.
| natpalmer1776 wrote:
| 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(tm) 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.
| -\\_(tsu)_/-
| gbalduzzi wrote:
| I love this kind of things the first time I see them but I
| would hate it in a tool used everyday
| natpalmer1776 wrote:
| ./myfancytool -disablefx
|
| ./myfancytool -showfx
|
| Or have an "on first run only" configuration that
| disables it for subsequent usage of the tool -\\_(tsu)_/-
| toast0 wrote:
| 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.
| xoac wrote:
| Someone will add this to their javascript framework cli
| sciencesama wrote:
| Now we need this in esp32 !!
| filoleg wrote:
| This is great, thanks!
|
| My favorite is Beams (the one at the very top of the page),
| reminds me of MGS1 "game over" screen animation a lot.
| keploy wrote:
| 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.
| panki27 wrote:
| No. No, you don't. No one investigating log files wants
| animations playing in them.
| keploy wrote:
| 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!
| leetrout wrote:
| I'm glad to see we all take the same approach to these sorts of
| things ^_^ self.move_cursor_to_top()
| sys.stdout.write(output_string) sys.stdout.flush()
| cl3misch wrote:
| Would there be a more canonical way do do this?
| nine_k wrote:
| 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.
| deathanatos wrote:
| 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.
|
| IIRC, ncurses does this under the hood.
| vanderZwan wrote:
| 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
| m463 wrote:
| I think the canonical way would be to ship this in some sort
| of hard-to-uninstall snap or flatpack package.
| cl3misch wrote:
| Flatpak is actually pretty nice and not affiliated with
| Canonical. No forced automatic updates with a daemon and
| easy to manage.
| throwanem wrote:
| This is amazing! Please never ever use it in production.
| distortionfield wrote:
| Idk I wouldn't mind one or two of these as loading screens or
| something.
| JTyQZSnP3cQGa8B wrote:
| As a developer-only tool, I'm sure most of my coworkers would
| love the attention to details.
| PartiallyTyped wrote:
| I actually love it.
| throwanem wrote:
| 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.
| johnmaguire wrote:
| What CLI tools have a slow enough boot to require a loading
| screen? I'm sure there are some but...
|
| The only one that comes to mine for me is FileBot[0] - and if
| the loading screen made it take ANY additional time, I'd be
| annoyed.
|
| [0] https://www.filebot.net/
| distortionfield wrote:
| 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.
| hnlmorg wrote:
| 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.
| jmbwell wrote:
| 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.
| hnlmorg wrote:
| 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.
| rafark wrote:
| Not for booting but for processing (downloading files,
| processing a directory, waiting for an api, etc)
| lupusreal wrote:
| 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.
| traverseda wrote:
| No. I still sometimes need to use a TTY over MOSH over a
| satellite connection.
|
| No.
| adrianmonk wrote:
| 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.)
| solresol wrote:
| 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.
| ykonstant wrote:
| Why not?
| throwanem wrote:
| 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?
| makapuf wrote:
| Of course it would be obnoxious.
|
| As an "about" screen, or in a opt-in funny theme why not !
| chambored wrote:
| The idea that anyone would use this during "common
| operations" is laughable, but as one offs during specific
| operations, maybe.
| throwanem wrote:
| > 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._
| ykonstant wrote:
| ?? 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?"
| yjftsjthsd-h wrote:
| > 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.
| Szpadel wrote:
| I actually did some color animations to status bar of build
| tool I created while ago. In my opinion this distracted
| enough to make build feel faster
|
| Edit: popular example of less invasive animations would be
| new docker cli, (pulling, buildx build)
| throwanem wrote:
| 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.
| reddalo wrote:
| Also, I don't want to even imagine how it would look on a
| SSH connection.
| distortionfield wrote:
| It's trivial to add in a keypress that short circuits the
| animation. God, this website is full of the grumpiest
| people on the planet.
| cornstalks wrote:
| 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.
| worksonmine wrote:
| 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.
| yjftsjthsd-h wrote:
| 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.
| echelon wrote:
| These are beautiful.
|
| 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.
| hedora wrote:
| s/fully/gradually/
|
| I'd love some of these effects to fade in/out within live
| terminal sessions.
| hnlmorg wrote:
| As long as readability wasn't affected though.
| jdoss wrote:
| 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].
|
| [0]: https://github.com/quickvm/bupy
|
| [1]: https://github.com/ansible/ansible/issues/10530
| jimmaswell wrote:
| 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)
|
| https://github.com/erkin/ponysay
|
| https://blog.yjl.im/2016/01/ascii-pony-systempony-
| screenshot...
| voidUpdate wrote:
| 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
| Aeolun wrote:
| Hot damn, I have to respect the author for shutting down any
| attempt to make him give in to the pressure.
|
| All these serious enterprise people worried about their cows,
| but then they do install 'cowsay' on their systems xD
| fragmede wrote:
| The people complaining probably don't have the authority to
| remove it from the base image they're forced to use,
| unfortunately.
| Aeolun wrote:
| How serious can your enterprise be if they install cowsay
| on their base image?
| throwanem wrote:
| 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.
| barryrandall wrote:
| Please use this to reboot Trade Wars 2002.
| harwoodr wrote:
| Oddly enough, I was just thinking about that sort of thing...
| flir wrote:
| BBS Doors! I knew this reminded me of something (in a good
| way).
| johng wrote:
| LORD
| cyanbane wrote:
| 100% Gimmie some Red Dragon.
| Aldipower wrote:
| You do not know how my production looks like. I _will_ use it
| in production!
| layer8 wrote:
| You work on screensavers?
| hedora wrote:
| Don't we all?
|
| https://xkcd.com/722/
| layer8 wrote:
| Who wants to actually read text anyway.
| notnmeyer wrote:
| all my run books use this
| neilv wrote:
| I propose that developers are allowed to use it in
| production... so long as they do all the development work on a
| 9600 baud dialup with a VT102.
| neilv wrote:
| 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.
| Dylan16807 wrote:
| I think my first action in a situation like that would be
| an attempt to install mosh from a local mirror.
| throwanem wrote:
| 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.
| philsnow wrote:
| 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.
| Dylan16807 wrote:
| "from a local mirror" does not involve transferring the
| binary over the slow link.
| throwanem wrote:
| 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.
| ultra_chad wrote:
| How exactly did you get the stations working? Be specific.
| neilv wrote:
| "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.)
| 8372049 wrote:
| I love the five point order-esque style, warms my
| military heart
| darkwater wrote:
| Is it me reading it wrong or are you using two "startup"
| meanings in sentences very close to each other?
| neilv wrote:
| I realized that, and so tried to say "boot" for one of
| the term senses, but missed an occurrence, which might've
| made it even more confusing.
| cdelsolar wrote:
| 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.
| neilv wrote:
| 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.
| beacon294 wrote:
| You can also proxy 443 out with ssh.
| fragmede wrote:
| Or setup a web ssh client and actually run HTTPS over
| port 443.
| randomtoast wrote:
| 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.
| skissane wrote:
| Future generations will ask - "why does every packet
| header have this 2 byte reserved field with a fixed value
| of 01BB?"
| cmrdporcupine wrote:
| It would truly have been elite if you'd have to pull out
| Kermit and use that.
|
| "line is ~300 baud but only transmitting 7 bit but we need
| to send this critical file.. which is in EBCDIC!"
| lm411 wrote:
| I'm very glad that TCP is so robust.
|
| 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.
| philsnow wrote:
| > 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.
| firewolf34 wrote:
| https://mosh.org/
| nneonneo wrote:
| If you ever find yourself needing to tunnel via DNS, try
| iodine: https://github.com/yarrick/iodine
| ivanhoe wrote:
| 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" :)))
| lupusreal wrote:
| TERM=dumb seems like a good idea in a situation like that.
| jimmaswell wrote:
| I actually am getting a VT320 soon that I hope to be able to
| use for my terminal at work. I'll run these over it if I
| remember.
| kps wrote:
| It won't work. It assumes 24-bit colour support, even if
| you have `TERM=vt320` or something else without it.
| jimmaswell wrote:
| Damn, just a programming oversight? You don't need colors
| to get a lot of these effects. Maybe I'll fork it.
| x187463 wrote:
| There's a --no-color argument.
|
| Example: ls | tte --no-color slide
|
| I'll add environment variable checks to the todo list.
| mirekrusin wrote:
| It can work we just need brave soul to make it client side.
| 1propionyl wrote:
| Agreed. It's not nearly as battle-tested as key operations
| tooling like `sl` and `gti`.
| m463 wrote:
| Uh, we accidentally shipped it as our fintech startup screen.
| omoikane wrote:
| Please do use it in demoscene productions. We need more
| textmode demos.
| voidhorse wrote:
| It would be great for the startup screens of terminal games.
| xyst wrote:
| Challenge accepted.
| emmelaich wrote:
| It'd be good if it recognised https://no-color.org/ and just
| didn't do anything. Or maybe replaced with <cool effect removed
| here>
|
| Maybe it does, I didn't check.
| x187463 wrote:
| It does have a --no-color flag.
|
| That being said, there are some environment variables that
| could be referenced. I'll add this one to the list for a
| future update.
| xigoi wrote:
| What if I want colors, but not animations?
| smrtinsert wrote:
| But if you do, include emoji animations
| noufalibrahim wrote:
| I'd love to use it while teaching.
| natpalmer1776 wrote:
| > ./myfancytool -nofx -doingbusiness -pwn "the_ops"
| terminaltrove wrote:
| The effects on this project is incredible, thanks for building
| this!
| bredren wrote:
| These effects remind me of some of the first programming I ever
| did: animated ASCII art for local BBS's.
|
| I remember dumping an entire day into something resembling
| Spider-Man. Was very exciting when a sysop put my work into their
| login sequence.
| guidoism wrote:
| Reminds me of the drip.com TSR program that I put on some of the
| school computers circa 1990.
| glonq wrote:
| Yeah in 1991 our college lab's MSDOS PC's were unsecured
| (unsecurable!?), so our prof quickly learned to regret teaching
| us how to write TSR's in ASM.
| guidoism wrote:
| 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.
| guidoism wrote:
| I also got in trouble for playing Leisure Suit Larry in 6th
| grade computer class.
| glonq wrote:
| LOL brute-forced the "adult knowledge" questions at
| startup, huh?
| makach wrote:
| oh how fun this must have been to implement these effects.
| absolutely love it!
| nickdothutton wrote:
| So much energy going into the command line/terminal at the
| moment. Reminds me a lot of BBS art of my youth. Where are my
| TheDraw crew?
| vunderba wrote:
| These effects would pair really well with an old school bbs/mud
| simulation.
| flir wrote:
| Retro-cyberpunk aesthetic.
|
| Hacking game?
| Gormo wrote:
| Or a non-simulated BBS or MUD.
| TeeMassive wrote:
| Kind of tools I wish I had a use case for.
| cbm-vic-20 wrote:
| There's a bit of lag on my VT420.
| lsllc wrote:
| Even at 19200 baud?
| eliasson wrote:
| Wow, this is astonishing!
| influx wrote:
| Code looks very clean, congrats. I wish for selfish reasons this
| was written in Go, so I could stuff the binary somewhere easily
| :)
| chambored wrote:
| I could see this idea being used in a lot of the charm.sh
| products.
| glonq wrote:
| 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.
| x187463 wrote:
| 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.
| flir wrote:
| That's a delightful thing you've made.
|
| Have you added a command-line switch for the direction of
| gravity?
|
| Some of the animations (eg Pour), could fall up the screen
| instead of down it. That way, the user can start reading the
| text immediately.
| x187463 wrote:
| ls -latr | tte pour --pour-direction up
|
| 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.
| flir wrote:
| I thought there might be one :)
|
| 3d... 3d... 3d... you know you want to.
| junon wrote:
| Chalk maintainer here. These are incredible. Some of the best
| I've ever seen. Kudos.
| sghiassy wrote:
| What magic sorcery are you using here!?!
|
| Bravo!
| liveoneggs wrote:
| brings the magic of an ANSI BBS to your terminal and more
| aryeshalev wrote:
| Exactly what I was thinking. Used to make ANSI animation with
| THEDRAW back in the day
| p2hari wrote:
| This is so cool. Thanks for this.
| jhallenworld wrote:
| The descriptions are fun. So it needs the "Bounty Bob Stikes
| Back!" effect: birds deliver each letter, then stand proudly on
| top of the sign:
|
| https://www.youtube.com/watch?v=18n-MBlVIvw
| redconfetti wrote:
| truly l337
| MikeTheGreat wrote:
| This is awesome. I'm like 99% sure I saw some of these effects in
| some of my late-80's CRPG type games :)
|
| It looks like the color gradient is per-pixel, not per-character.
| Would anyone have any idea how the package does that?
| chuckadams wrote:
| 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.
| x187463 wrote:
| Dev here: You are correct. It's using 24-bit color ANSI
| escape codes.
|
| https://en.wikipedia.org/wiki/ANSI_escape_code#24-bit
| g3ol4d0 wrote:
| fucking amazing
| buildsjets wrote:
| Rather reminds me of Nick Black's Notcurses library.
|
| https://nick-black.com/dankwiki/index.php/Notcurses
|
| https://github.com/dankamongmen/notcurses
| buildsjets wrote:
| Video Demo: https://www.youtube.com/watch?v=dcjkezf1ARY
| jamboca wrote:
| 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?
| porcoda wrote:
| 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.
| TazeTSchnitzel wrote:
| If ascii art animation brings joy to you, you might enjoy "BB:
| the portable demo". On Debian, it's `sudo apt install bb` I
| think.
| gary_0 wrote:
| No "The Matrix" effect? That was one of the earliest programs I
| wrote back in 2000, and I was so proud of myself.
| hinkley wrote:
| I can tell I'm too old now because I expected the Matrix
| projection to be in the first four examples and it's not even
| on the page.
| gary_0 wrote:
| It's not me that's too old, it's the world that's too young.
| akira2501 wrote:
| I was hoping for the "no more secrets" effect.
|
| https://www.youtube.com/watch?v=F5bAa6gFvLs
| hinkley wrote:
| _Peace on Earth, and goodwill toward men._
|
| I'll see what I can do.
| x187463 wrote:
| The decrypt effect is a faithful recreation of that exact
| scene at the 45 second mark. Just different colors, which
| can be set.
|
| Here it is with adjusted colors:
|
| ls -latr | tte decrypt --ciphertext-colors 808080 --final-
| gradient-stops 1e90ff
| x187463 wrote:
| TTE dev here:
|
| 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.
| verst wrote:
| Looks amazing!
|
| 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.
|
| I tried with iTerm2 and Terminal app.
| x7001 wrote:
| That demo isn't actually the default config. Here's how you can
| recreate it.
|
| ll | tte colorshift --travel --travel-direction radial --loop
| divbzero wrote:
| Awesome! Someone please use this in a film or TV show.
| yumraj wrote:
| While making sure to credit the author..
| alfalfasprout wrote:
| Now this is the kind of stuff I want to see more of on HN. Really
| cool!
| hinkley wrote:
| I'm imagining several genres of text based adventures that could
| make very good use of this library. Cyberpunk, fantasy, and
| horror.
|
| Very subtle uses of this could go a long way.
| koromak wrote:
| I was immediately thinking of ADOM and NetHack. Would have been
| so cool.
| joquarky wrote:
| I was suddenly reminded of ZZT while watching the demos.
| jasonjmcghee wrote:
| Would love to see a falling sand simulator- many of the effects
| look like great candidates for making it feel satisfying.
| nickstinemates wrote:
| I integrated this[1] with my MOTD on ssh login.. :) With random
| effect each time.
|
| 1: https://keeb.dev/static/login.mp4
| dxxvi wrote:
| looks both cool and frustrating :)
| nickstinemates wrote:
| It would be if I logged in a lot! and you can always ctrl+c
| if you're in a hurry.
| shibeprime wrote:
| Cool use case! How do you make it choose a random effect?
| nickstinemates wrote:
| I wrote a simple shell script which does it for me
| m-GDEV wrote:
| This is super cool
| xyst wrote:
| getting this into my production system now ...
| fragmede wrote:
| I also integrated on my ssh server. try sshing to
| funky.nondeterministic.computer
| michaelmior wrote:
| Well played...
| nickstinemates wrote:
| I enjoyed that!
| nickdothutton wrote:
| Wonderful.
| crazygringo wrote:
| Kudos to you.
| yumraj wrote:
| How do you do that? If possible share the script please..
| vulkoingim wrote:
| You can do something like: printssh() {
| tte --input-file YOUR_FILE --frame-rate=500 $(echo "beams
| binarypath blackhole bouncyballs bubbles burn colorshift
| crumble decrypt errorcorrect expand fireworks middleout
| orbittingvolley overflow pour print rain randomsequence rings
| scattered slice slide spotlights spray swarm synthgrid
| unstable vhstape waves wipe" | tr ' ' '\n' | shuf -n 1)
| ssh "$@" } alias ssh="printssh"
| nickstinemates wrote:
| Anything in your ~/.bashrc or ~/.zshrc gets executed in
| sequence, so at the bottom of it I have
| /home/keeb/code/projects/login/motd.sh
|
| And the contents of that file is...
| #!/usr/bin/env zsh values=("bubbles" "slide"
| "beams" "rain" "pour" "synthgrid" "unstable" "poop")
| len=${#values[@]} index=$(( (RANDOM % (len - 1)) + 1
| )) selected=${values[$index]} cat
| /home/keeb/code/projects/login/motd | tte $selected
| adr1an wrote:
| Can't wait to find these in TV shows!
| Bytamine wrote:
| Yeah, I can see some "hacker" using Decrypt effect.
| wpm wrote:
| It's straight out of Sneakers (1992).
|
| https://www.youtube.com/watch?v=GS3npSv8iuM
|
| Anyone want to shut down the Federal Reserve?
| voxadam wrote:
| Anybody want to crash a couple of passenger jets?
| kstrauser wrote:
| "Why's everyone upvoting some article about text? ... OMG I LOVE
| THIS."
|
| That's brilliant. I love it. This is the kind of whimsical thing
| done purely for the love of it that makes my day.
| dancemethis wrote:
| One of the most pleasing things I've seen in a long, long while.
| no-dr-onboard wrote:
| Part of me hopes this reignites a new era of scareware. The other
| part says wow this would be really cool for a SSH banner
| xyst wrote:
| nickstinemates already beat you to it [1]
|
| [1] https://keeb.dev/static/login.mp4
| AYBABTME wrote:
| I want this in charm.sh
| xyst wrote:
| Reminds me of my old geocities site when I was a kid. Copy and
| pasted HTML from many websites to get that "hax0r" feel.
|
| Now I can get that nostalgia in my terminal
| spudlyo wrote:
| export TERM=dumb
| fragmede wrote:
| A quick peruse through the code doesn't reveal checking of the
| TERM environment variable.
| derefr wrote:
| 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.)
| emmelaich wrote:
| "Ask HN: Recommendations for Good TUI Libraries (Text User
| Interface)?"
|
| 93 points by andrewstuart on Sept 8, 2020 | hide | past |
| favorite | 63 comments
|
| https://news.ycombinator.com/item?id=24412687
| mkotowski wrote:
| > (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).
|
| [0]: https://github.com/mintty/mintty/wiki/CtrlSeqs#audio-
| support
|
| [1]: https://github.com/mintty/mintty/wiki/CtrlSeqs#font-size
|
| [2]: https://github.com/mintty/mintty/wiki/Tips#alternative-
| fonts
|
| [3]: https://iterm2.com/documentation-escape-codes.html
|
| [4]: https://github.com/charmbracelet/bubbles
|
| [5]: https://github.com/charmbracelet/gum
| derefr wrote:
| > 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.
| follower wrote:
| > [...] 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'."
|
| [1] https://news.ycombinator.com/item?id=40475538
|
| [2] https://wezfurlong.org/wezterm/
|
| [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. :)
|
| [5] https://gitlab.com/RancidBacon/floss-various-
| contribs/-/blob...
|
| [6]
| https://gitlab.com/RancidBacon/notes_public/-/blob/main/note...
|
| [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
| srcreigh wrote:
| is it just me, or is the Spotlights effect in a league of its own
| here?
|
| Kudos to the author!
| emmelaich wrote:
| Does this have some overlap with libcaca? cacademo and cacafire
| are especially impressive. Also has Python bindings.
|
| https://github.com/cacalabs/libcaca/tree/main
|
| [edit, also https://en.wikipedia.org/wiki/AAlib]
| cdchn wrote:
| Serious lack of screenshots here.
| emmelaich wrote:
| There's quite a few around the web.
|
| Or just do `apt-get|dnf install caca-utils`
| est wrote:
| That's so cool, I wonder if this can be pulled off on web pages?
| Non fixed width font would fail all over the places with quirks
| of css.
| cdchn wrote:
| I'm dying for a menu system like this that lets me select items
| old school BBS "light bar" style.
| ein0p wrote:
| I did not expect this much variety and sophistication.
| epiccoleman wrote:
| Absolutely awesome, I've gotta figure out a use for this!
| booleanbetrayal wrote:
| 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!
| CGamesPlay wrote:
| Would be cute to integrate this with streaming output, so I could
| tail a log file and have it appear like this (or stream an LLM
| output, maybe).
| zoom6628 wrote:
| Gorgeous and brilliant. Hats off to the developer.
| AnonC wrote:
| 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! :)
| maxglute wrote:
| Incredible. Is there site that collects different ascii art
| techniques?
| chauhankiran wrote:
| Movie material!
| capitol_ wrote:
| I would love to have these effects as an option when viewing man
| pages.
| thunkle wrote:
| I feel like a good use case for this would be on an oldskool
| roguelike.
| Pwntheon wrote:
| Cogmind is a newer roguelike that uses lots of effects like
| this. It looks amazing
| sph wrote:
| Also brogue tends to have very fancy ASCII art animation.
| Cogmind is not strictly ASCII per se.
| vanderZwan wrote:
| 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.
| hereme888 wrote:
| Can't think of a more HackerNews worthy project.
| vim-guru wrote:
| Wow! I did that Matrix-effect once in C#/mono. It turned out to
| be way more complicated than I initially thought. Well done!
| giamma wrote:
| 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.
| mrjin wrote:
| Oh dear, why would any terminal user want that?
| joveian wrote:
| 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.
|
| https://chrisbuilds.github.io/terminaltexteffects/img/effect...
| abelcha wrote:
| 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
| cpill wrote:
| I'll be looking for this in Hollywood movies
| _bax wrote:
| Wonderful !
| ivanjermakov wrote:
| Reminds me a lot of Cogmind's[1] level entry visuals, love it!
|
| [1]: https://www.gridsagegames.com/cogmind/
| busfahrer wrote:
| Reminds me of notcurses:
|
| https://www.youtube.com/watch?v=b4lmMADP1lA
|
| Mind you, this rendered entirely in a terminal. You can try it
| yourself on most systems by installing notcurses and then running
| `notcurses-demo`.
| tokai wrote:
| Reminds me of Caves of Qud.
| NoGravitas wrote:
| 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.
| barbs wrote:
| I wonder if there is a similar, more lightweight library that
| has cool effects that work with the minimum specs you've
| specified?
| outworlder wrote:
| AAlib can probably be used for that, although it doesn't have
| those text effects coded.
|
| The demo, BB, should be more like it.
| https://www.youtube.com/watch?v=9ukhOAUseKY
|
| AAlib, as far as I know, works in VT220.
| adhambadr wrote:
| omg I'll finally look as cool as my parents think I am when I'm
| pinging google.com to know how bad the wifi is.
| gwbas1c wrote:
| 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?
| anamexis wrote:
| > But, if you're going to go through the trouble to use these
| in a command-line program, why not make a GUI?
|
| Because this is more fun.
| bux93 wrote:
| I look forward to seeing this in future movies and forensic
| procedurals. "The hacker left a virus in the mainframe!"
| stackedinserter wrote:
| 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.
| dvqc wrote:
| 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
| stackedinserter wrote:
| 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.
| bubblebeard wrote:
| 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.
| ljm wrote:
| 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.
| nextaccountic wrote:
| Maybe you would use if you were filming a hacker movie? Or
| something like that
| jaimehrubiks wrote:
| 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.
| indoorcomic wrote:
| I miss when the internet was full of whimsical stuff like this.
| Great library, thanks for sharing!
| swayvil wrote:
| This is so darn cool. Better than 99% of modern computer art.
| Really says something about good graphic design.
| anthonypz wrote:
| Amazing. I've seen similar effects used in production on
| https://musicforprogramming.net/ which looks like the
| RandomSequence effect.
___________________________________________________________________
(page generated 2024-05-29 23:02 UTC)