> You're missing the point, which is that the EFL library just has media playback built into it - for a lot of different formats.
As far as I understand, you're missing the point. Every format that someone now wants to handle on terminal, needs to be supported by the EFL library?! Does it support LO spreadsheets? PDFs? Audacity projects? Raw camera images? HTML? Yes? And now I want to switch away from LO to some very new office tools, and I cannot, because EFL doesn't support it yet?
And all that just in order to show some previews in a terminal emulator instead of the graphical environment around it that is perfectly capable to do so since half a century? Where all the applications already exist?
> tycat doesn't need to know or care about file formats, nor does terminology
Fine. Just replace tycat with EFL in what I wrote before.
> I was playing around a while back with embedding GUI elements like buttons inside terminology. [...] Limited real-world practical value, perhaps, but interesting IMO.
Yes, it sounds like an interesting puzzle. But it's artificial. It solves a problem that just doesn't exist at all, and it doesn't actually improve anything, as long as it's not universally supported (at least in an actual Linux virtual terminal outside of X11/Wayland).
> Rasterman and I have both given examples of how this improves the terminal experience.
But why are you trying to improve the horse riding experience, if you actually have a car that is just artificially stripped down to feel like a horse? Just use the car as a car instead! ;)
What context switch are you talking about? Your eyes moving to where the new window opened? srsly?
Why can't the same folks not improve keyboard support in e.g. VLC? If it's actually so bad... Is it? I rarely feel the desire to keyboard control a media player, admittedly... But I would be surprised if VLC is worse in that regard than some terminal thingy that is a niche inside a niche inside a niche... A terminal media player needs the same explicit development work to get it right. It's not magically keyboard-friendly just because it involves antiquated technology for displaying.
> and time of having to fire up a media player to preview a file
You fire up a new tycat instance instead. What's the difference? Here VLC takes, idk, 500ms?! Half of it is the window animation that I could turn off, if I would dislike it (I don't).
> I mentioned the kitty terminal emulator before. It's doing similar things. And it's quite popular with the kids. These enhancements to terminals are a good thing!
Yeah, make them universally work on any virtual terminals, and then it'd be at least an interesting discussion whether this was an actual improvement or not. As long as I need some E terminal, or a particular terminal that is "popular with the kids", I really don't see at all why this is a good idea to spend any efforts for. Just use the car as a car, instead of disabling the engine, pretending it to be a horse, and then find clever ways to make it feel more like a car again. It already _is_ a car. Don't make up artificial restrictions that do not exist, just in order to find mediocre ways to somehow patch parts of them away a bit.
Give Dolphin a chance! It's like the kids' vi setup, just with slightly different shortcuts, and without all the weaknesses. It even can render actual icons without a patched terminal font! And if keyboard support is weak, then this is not because it's not a terminal application. Make them a bug report. Or, if appropriately skilled, send them a patch! Then we all profit from it.
Bonus: It can display emojis, without breaking alignment in half of the terminal emulators, because the actual glyph width differs from what the "API" (i.e. dancing some escape sequences and somehow intercept the answers from somewhere) tells you.