erk__ · 2 years ago

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.

mickeyp · 2 years ago

Emacs has game of life also. M-x life.

natpalmer1776 · 2 years ago

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. ¯\_(ツ)_/¯

toast0 · 2 years ago

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.

keploy · 2 years ago

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!

nine_k · 2 years ago

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_

With current terminals giving you 60fps in true-color mode, it makes little sense, of course.

deathanatos · 2 years ago

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.

m463 · 2 years ago

I think the canonical way would be to ship this in some sort of hard-to-uninstall snap or flatpack package.

JTyQZSnP3cQGa8B · 2 years ago

As a developer-only tool, I’m sure most of my coworkers would love the attention to details.

radlad · 2 years ago

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/

traverseda · 2 years ago

No. I still sometimes need to use a TTY over MOSH over a satellite connection.

No.

throwanem · 2 years ago

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?

yjftsjthsd-h · 2 years ago

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.

hedora · 2 years ago

s/fully/gradually/

I’d love some of these effects to fade in/out within live terminal sessions.

hnlmorg · 2 years ago

As long as readability wasn’t affected though.

jimmaswell · 2 years ago

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...

Aeolun · 2 years ago

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

harwoodr · 2 years ago

Oddly enough, I was just thinking about that sort of thing...

flir · 2 years ago

BBS Doors! I knew this reminded me of something (in a good way).

layer8 · 2 years ago

You work on screensavers?

neilv · 2 years ago

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.

jimmaswell · 2 years ago

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.

mirekrusin · 2 years ago

It can work we just need brave soul to make it client side.

x187463 · 2 years ago

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 · 2 years ago

What if I want colors, but not animations?

guidoism · 2 years ago

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.

flir · 2 years ago

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 · 2 years ago

Dev here: You are correct. It's using 24-bit color ANSI escape codes.

https://en.wikipedia.org/wiki/ANSI_escape_code#24-bit

gary_0 · 2 years ago

It's not me that's too old, it's the world that's too young.

akira2501 · 2 years ago

I was hoping for the "no more secrets" effect.

https://www.youtube.com/watch?v=F5bAa6gFvLs

verst · 2 years ago

Cool, thanks for that!

jfl0 · 2 years ago

or even pay them!

nickstinemates · 2 years ago

It would be if I logged in a lot! and you can always ctrl+c if you're in a hurry.

nickstinemates · 2 years ago

I wrote a simple shell script which does it for me

michaelmior · 2 years ago

Well played…

nickstinemates · 2 years ago

I enjoyed that!

nickdothutton · 2 years ago

Wonderful.

crazygringo · 2 years ago

Kudos to you.

keeganpoppen · 2 years ago

you beautiful bastard... i knew what was going to happen, had multiple chances to not do it, but i just had to see it through...

vulkoingim · 2 years ago

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 · 2 years ago

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

    #!/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

wpm · 2 years ago

It's straight out of Sneakers (1992).

https://www.youtube.com/watch?v=GS3npSv8iuM

Anyone want to shut down the Federal Reserve?

derefr · 2 years ago

> 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.

derefr · 2 years ago

> [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.

emmelaich · 2 years ago

There's quite a few around the web.

Or just do `apt-get|dnf install caca-utils`

sph · 2 years ago

Also brogue tends to have very fancy ASCII art animation. Cogmind is not strictly ASCII per se.

vanderZwan · 2 years ago

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.

outworlder · 2 years ago

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.

stackedinserter · 2 years ago

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.