8000 Idea for the future: Support only `cable channels` and `stdin` · Issue #253 · alexpasmantier/television · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
Idea for the future: Support only cable channels and stdin #253
Closed
@xosxos

Description

@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 ?

Metadata

Metadata

Labels

enhancementNew feature or requestin flightBeing addressed as we speak

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions

    0