tube-get VS mpv

To understand why, I have a far simpler tool that focuses on a subset of sites (adult content video aggregators)

https://github.com/kristopolous/tube-get

It too deals with this problem but does so in a way that'd be easy to maliciously sabotage

Look right about here https://github.com/kristopolous/tube-get/blob/master/tube-ge...

Add to why this exists, this was originally written between about 2010-2015 or so so it technically predates the yt-* ecosystem.

The tool still works fine and it's not a strict subset of yt-dlp or YouTube-dl because being a different approach, although it's overall site coverage is smaller, I've had it be a "second try" system when yt-* fails and it comes up with success maybe about half the time

Based on my (limited) understanding of Kitty's image protocol[0] (a.k.a the "Terminal graphics protocol") video support could be potentially implemented via multiple approaches, including at least:

(1) Draw image repeatedly using the "don't move cursor" cursor movement policy[1a][1b].

(2) Draw image replacing an existing image with the same id.

(3) Use animation configured to use "loading mode"[2] ("in this mode when reaching the last frame, instead of looping, the terminal will wait for the arrival of more frames").

An actual terminal graphics/image protocol enables some IMO[3] pretty cool possibilities:

* A while back I implemented a proof-of-concept that displayed a simple interactive egui (a Rust immediate mode GUI project) GUI within WezTerm via the protocol.

* Later I discovered someone had gone as far as making a port[5] of the OpenGL gears demo to kitty terminal graphics protocol.

* And there's even a "full graphical web browser for Kitty terminal with mouse and keyboard support"[6][7].

---- footnotes ----

(Content advisory for links: Kitty terminal graphics protocol spec includes a sample image whose subject has requested that the image no longer be used for such purposes.)

[0] https://sw.kovidgoyal.net/kitty/graphics-protocol/#terminal-...

[1a] https://sw.kovidgoyal.net/kitty/graphics-protocol/#controlli...

[1b] This approach appears to be the method used by the mpv implementation: https://github.com/mpv-player/mpv/commit/874e28f4a41a916bb56...

[2] https://sw.kovidgoyal.net/kitty/graphics-protocol/#controlli...

[3] I'm aware that not everyone will think static or dynamic image display is something a terminal "should do" but to me it seems better to have actual image support in terminals rather than use (already currently used) existing "hacks" that provide a poor facsimile of support[4].

[4] Then again, I'm also of the opinion[4a] that perhaps terminals should support actual graphical UIs rather than the poor facsimile of them delivered by TUIs. *cough* :D

[4a] 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". (See also: "lab notebooks" & some tiling window manager features.)

[5] https://github.com/michaeljclark/glkitty

[6] https://github.com/chase/awrit

[7] Which I imagine DEC is turning in its grave about. :)

https://mpv.io/ has yt-dlp support, if yt-dlp is installed you just need to throw the URL at it and it plays the video (without download).

See https://github.com/mpv-player/mpv/issues/9053

I apologise for not following procedure. I am in the middle of building mpv 0.37 from source. Irrespective of the outcome I will document what I had to do in addition to the instructions on mpv.io and if the problem perststs, where it happens and where not with kernel version, mpv version taken from the screen, and the terminal output.

Use MPV. Partticularily shinchiro's builds. Extract the folder where you want its installation directory to be, if you decide to install it. Otherwise, just drag and drop files on top of its window or executable.

Author of ripgrep here.

Like automatic encoding detection and transparently searching UTF-16?

Or simple ways for composing character classes, e.g., `[\pL&&\p{Greek}]` for all codepoints in the Greek script that are letters. Another favorite of mine is `\P{ascii}`, which will search for any codepoint that isn't in the ASCII subset.

Or more sophisticated filtering features that let you automatically respect things like gitignore rules.

Those are all things that ripgrep does that grep does not. So I do not favor this explanation personally.

ripgrep has just about all of the functionality that GNU grep does. I would say the two biggest missing pieces at this point are:

* POSIX locale support. (But this might be a feature[1].)

* Support for "basic" regexes or some equivalent that flips the escaping rules around. i.e., You need to write `\+` to match 1 or more things, where as `+` will just match `+ literally.

Otherwise, ripgrep has unfortunately grown just about as many flags as GNU grep.

[1]: https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...

- https://github.com/mpv-player/mpv/issues/8692