play/queue multiple marked videos

[spiderbit]

if you use umpv as starter for mpv it does queue new videos in a playlist.

The problem is that you have to press 10 times enter as example to queue 10 videos you can't mark as example all videos in the result buffer and queue them with 1 shortcut.

I tried to add it then I realized that you don't use the tabulated-list: https://www.gnu.org/software/emacs/manual/html_node/elisp/Tabulated-List-Mode.html

Which would have made that easy to implement (copy and paste + small changes from my kodi-remote mode), would it make sense to use tabulated-list or do you think implement such marked mode would be easy doable without. I of course could fork it and rewrite it with tabulated-list-mode. I think having only 1 buffer for search results is ideal, so a buffer for search history where you can open with enter search results would probably good but then I would argue or question if there tabulated lists would not helpful, too.

Did you not know about tabulated-list-mode or do you have other reasons to not use it?

[grastello]

I honestly did not knew about tabulated-list-mode, I might look into it as it seems pretty interesting. I also never considered the idea of "mass actions" on the search results. Of course one could work around the issue with macros in some cases, but being able to mark stuff seems ideal now that you mention it.

About the history buffer: is it really necessary?

[spiderbit]

Well I added a cheap version of that in my copy:

(defun ytel-search-marked ()
  "docstring"
  (interactive )
  (let* ((query
      (buffer-substring-no-properties
       (region-beginning)
       (region-end))))
    (ytel)
    (ytel-search query)))

I as example search pretty regulary some band I like with reaction... so I have a text file with 5-10 line with: "React Nightwish date:today"

As example mark then call the function, I do that maybe every other day. having to write that each day even without the date thing is a bit annoying.

I also thought about getting your suggestions which would maybe do that a bit for you in a A.I learned way, but I think the upstream api allows to "login" yet. Would also be cool to mark files as watched and hide it then from the results, but I think there upstream must be improved for that.

Does we need such buffer I don't know but it would make it better, and I don't know how to revisit repeating searches in a better way. You could have some txt file with a history of searches that you then give as tab completion for the minibuffer, I think that could be work out, too. Then with tab-tab you would see also the whole list, maybe that would be easier?

Yeah it would be easier just write all the searches in a txt file, make sure that you only have unique elements in that list and then tab completion in the minibuffer something like that:

(let* ((completing-function 'ido-completing-read))
  (funcall completing-function "Search: " '("search1" "search2")))

you can also use completing-read or maybe there are other frameworks that have completing-read functions like ivy or so, you can default it to completing-read to have it more neutral and expose it as option:

(defvar completing-function 'ido-completing-read
  "Function to use for minibuffer capturing.")

Of course you have to read and write the options to complete form a file.

The only negative with this is that completion-read don't support space as input and ido-completion-read you have to press C-e to enter space and escape the completion, so maybe you would bind s for new searches and S for completing old searches... so you keep your current search save the texts in a text file /.emacs.d/ytel-searches.txt something like that:

(let* ((json-file "~/.emacs.d/ytel-searches.json")
       (searches (if (file-exists-p json-file)
          (json-read-file json-file) '()))))

and for writing: (json-write-file combined-search-term json-file t)

json is probably overkill for that thing just what I used in my last project: https://github.com/spiderbit/org-capture-ledger-shopping/blob/master/ledger-shopping-capture.el

I might write that later or in the next days, but talking about it helps to think it through.

[spiderbit]

So I know this bug report is maybe not the right place to further discuss this, but I just hacked together or modified your code to use tabulated-list: ytel-tabulated-list.jpg

currently it's around 80 lines of code change, but copied a few functions renamed and just modified it, so in reality it's more like 20-50 lines patch.

The shortening of the strings happens automatically, and works better to be frankly, you can sort the tabs, but that is the strings from the page it does at least yet not make a fresh api call.

I have to clean it up a bit but will then commit the code probably tomorrow.

[spiderbit]

ok have uploaded it https://github.com/spiderbit/ytel/tree/tabulated-list

Saves actually 35 lines of code for the same functionality, maybe if refactored a bit even a bit more.