Idea for the future: Support only cable channels and stdin

[xosxos]

Hey,

I am proposing a major change so this is a long one....

I have been absolutely awestruck how good the idea of custom channels, with a custom preview and custom run options is. I feel TUI applications are often cumbersome to use and not good for customization. So, shell functions combined with pipes and aliases and all the unix stuff is the daily driver for me.

However, the way this apllication is designed actually invites all the unix love into a TUI. I can create countless applications for countless use cases (git, docker, ps) in the same general framework of television. And I think that's the kicker here. I believe television should take a more frameworky approach.

What I am suggesting is to ditch the hard coded channels and concentrate on the cable channels via a config. This would greatly reduce code complexity and code duplication both in the channels and previews section. I think it would also eliminate the need for the procedural macros written to hide this complexity in TelevisionChannel. This would be beneficial because generative code is much harder to reason about in relation to normal code.

The thought came up when I was creating a shitty implementation of #16 and I realized I have to either support all the hard-coded variants currently present and FUTURE ones as well. Which would mean more code complexity. That's when I tried implementing the hard-coded channels via the config file and I could do a 1-to-1 replication of many of them (but not all, and colors don't work!).

[[cable_channel]]
name = "my_repos"
source_command = 'fd git ~/ --type d --no-ignore --hidden | rg "\.git/"'
preview_delimiter = ":"
preview_command = "cd {} && git log -n 200 --pretty=medium --all --graph --color"

[[cable_channel]]
name = "my_envs"
source_command = "printenv | sort | sed \"s/=/: /g\""
preview_delimiter = ":"
preview_command = "echo {1}"

[[cable_channel]]
name = "my_alias"
source_command = "fish -c alias"
preview_delimiter = ":"
preview_command = "echo {0}"

So, I think it would be good to have a single very customizable Previewer, which would support cable_channels and stdin with full feature parity. Meaning, all options in the config would be available as parameters for the clap app. This would solve #190 as well, because instead of implementing it on the application side (by adding more code), it can, and I think should be, implemented OUTSIDE the application:

[[cable_channel]]
name = "my_hidden_files"

# DONT SHOW HIDDEN FILES (here using fd-find, but can be done with GNU find)
# source_command = "fd . --type f"

# SHOW HIDDEN FILES
source_command = "fd . --type f --hidden"

preview_delimiter = ":"
preview_command = "bat {0}"

What I am envisioning is for example creating a program manager under the television framework:

[[cable_channel]]
name = "manager"
source = "ps -ax -o pid,command | sed 's/^ * //g' | sed -r 's/ +/;/'"
delimiter = ";"
preview = "echo {0}"
run = [
  "kill {1}",
  "kill -9 {1}",
  "tail -f /proc/{1}/fd/1"
]
deduplicate = false

However,

1. I don't know what this means for windows support, as it might not have such standard software available as unix does.
2. I don't know what this approach would mean for transitions and how they could be defined via the config.
3. Hunders of potential other problems unforeseen here

That's my two cents, and it might not align with the future planned for this project, but thanks for writing an inspiring application!
Any general thoughts on this @alexpasmantier ?

[alexpasmantier]

@xosxos I agree with most of your points, and am pretty much on board with the overall idea but need to put a bit of thinking into it before I come up with a more detailed response.

Thanks for sharing this 🙏🏻

[alexpasmantier]

The way I see this:

• I agree the overall vision is a desirable goal
• I think the builtin previewers are important to keep (as they provide robust defaults such as the builtin :files: syntax highlighting one)
• I feel like a more generic approach to transitions could solve the cable channel transitions problem (i.e. systematically allowing to send to any channel the currently shortlisted entries and allowing to customize what gets passed via the config in a way similar to how the preview command picks and choses bits from entries using that format syntax). That would allow people to optionally define custom transitions in their config between cable channels using something like:

[[cable_channel]]
name = "channel_A"
# ...

[[cable_channel]]
name = "channel_B"
# ...
transitions_into = {
    channel_A = {
        format_entry = "{0}",
        delimiter = "\t"
    }
}

• since 0.9.1 people can now override builtin channels with a cable channel which I believe is a first step in the right direction (it allows to eventually smoothly transition to a cable-only world)

If we're heading that way, I feel like the best route to get there would be to work our way towards feature parity between builtin and cable channels before anything else (and work on "commands to run on selection" on the way there).
That would include, among other things:

• transitions for cable channels (see above)
• parsing ansi formatting in entries and applying that formatting to the results list
• bulking up the default cable channels list to still provide a nice batteries-included default user experience

[xosxos]

Glad to hear you think this could be a way forward!

For now I forked, refactored things and turned this into a mono repo (not saying its desirable). Compilation dependencies went down to ~260. I don´t think I removed any major dependency either so it´s probably an issue with the workspace not resolving dependencies optimally. I will continue to see how lean this can get while maintaining feature parity.

I also implemented in application logging but I´ll get back to you when I have solid code. I plan on working on bits and pieces until I have what I want, and then, if some refactors and implementations make sense for television, pieces can be merged in. After I have a full understanding of the code I can do patches for the main as well.

• I think the builtin previewers are important to keep (as they provide robust defaults such as the builtin :files: syntax highlighting one)

I agree on the previewers. I think the implementation however could be a single struct. Then in the config, the :files: syntax would just initiate the previewer with the appropriate settings.

• I feel like a more generic approach to transitions could solve the cable channel transitions problem.

The config draft makes sense. I don't quite understand the transitions as I haven´t used them. It´s something my brain might not be able to handle while working. I.e. take these files, then search for this string. I would just construct a pipe for this. But I feel there is potential I cannot quite grasp yet. Especially if a single channel with a preview and run commands is considered a single "application", then the transitions could be considered as dynamic piping. If you would add transition commands separately (in relation to run commands), it would be like dynamic piping on steroids I suppose.

• transitions for cable channels (see above)
• parsing ansi formatting in entries and applying that formatting to the results list
• bulking up the default cable channels list to still provide a nice batteries-included default user experience

Fully agree on all points. And the default channels would probably have to be running GNU applications which kinda sucks in the year 2025, but what can you do.

All in all, I guess the features that would make me happy are:

1. Run commands
2. Cable transitions
3. Cable channel can be constructed identically from both stdin and config file
4. Feature parity between the built-in channels and the config based replacements
5. Bonus: Transition commands
6. Bonus: Simple in application logging for dev builds

And on the code side:

1. A single channel (not sure if stdin requires its own), i.e. cable-only refactor.
2. A single very configurable Previewer struct with quality presets to be used in the config
3. Refactoring out the procedural macros (we'll see how this works out, as the remote also uses them). For now, I just switched to enum_dispatch crate to forward the OnAir trait in the same way as it´s done now.