feat(tea): add provisional support for customizing tea runtime options

[gustavosbarreto]

This adds support for changing some tea options (WithFPS and WithAltScreen) via options for all tea-based gum commands.

Context

I'm working on a TUI that spawns many gum instances in parallel, potentially hundreds, depending on the number of users. In this context, reducing FPS is essential because gum/tea default to 60fps, but we found 20fps gives a good balance between responsiveness and CPU usage.

We also needed to force alternate screen mode in some tea-based gum commands that don’t use it by default to improve integration in full window environments.

[caarlos0]

Hey, thanks for the input and for the PR!

As a small note, we try to start things as discussions, so we can think about things from a cleaner slate.

That being said, I believe this feature can be kind of hidden, probably only reading from env, e.g. GUM_FPS & GUM_ALTSCREEN, and not via flags.

I would also add a comment to where this is implemented (e.g. the gumtea pkg) that reads somewhere in the lines of:

This feature is provisional. It may be altered or removed in a future version of this package.

So, tl;dr on that:

• remove the Tea gumtea.Options thing
• make it work with env vars only
• add a comment saying its provisional

Finally, if you don't mind me asking, what's the use case of that many gum instances in parallel? Without more info, it sounds like this could probably be its own app, but anyway, I'm curious :)

Thank you!

[gustavosbarreto]

@caarlos0,

As a small note, we try to start things as discussions, so we can think about things from a cleaner slate.

Just to confirm, is there a contribution guide I should follow? I’d like to avoid submitting another PR that doesn’t align with the project’s expectations

Finally, if you don't mind me asking, what's the use case of that many gum instances in parallel? I'm curious :)

I'm working on a some sort of terminal multiplexer... that's about all I can say for now :P

Without more info, it sounds like this could probably be its own app

Would you be interested in me updating the PR based on your suggestions? If so, I’ll go ahead.

[caarlos0]

Ah, that's odd, it should be showing you this: https://github.com/charmbracelet/.github/blob/main/CONTRIBUTING.md

Will look into it internally.

I'm working on a some sort of terminal multiplexer... that's about all I can say for now :P

interesting... 🤔

Would you be interested in me updating the PR based on your suggestions? If so, I’ll go ahead.

sure, go for it :)

[gustavosbarreto]

@caarlos0,

Hey! I was thinking about two different ways to implement this and wanted to get your take.

The first (and simpler) one is what I went with: just read GUM_FPS and GUM_ALTSCREEN directly using os.Getenv inside gumtea.NewProgram. That way we don't need to touch the CLI struct at all (no new fields, no extra wiring). All commands just pick it up automatically.

The other option I considered was making those part of the main struct Gum and letting kong handle them as hidden env-bound flags. But since that struct lives in package main, we’d have to either export it, or move it into the gumtea package, or even just unify everything under a single package gum that contains both the struct Gum and this provisional logic.

So yeah, wanted to check what you think. Stick with the current env-only approach? Or do you think it’s worth letting kong handle it, even if it means moving some things around?

[caarlos0]

yes I would keep the env only only approach... we can always move it later if it makes sense.