Package Details: mpv-bash-completion-git 8:3.3.17-1

Git Clone URL: (read-only)
Package Base: mpv-bash-completion-git
Description: Bash completion for the mpv video player
Upstream URL:
Keywords: bash mpv
Licenses: GPL
Conflicts: mpv-bash-completion
Provides: mpv-bash-completion
Submitter: 2ion
Maintainer: 2ion
Last Packager: 2ion
Votes: 18
Popularity: 0.301290
First Submitted: 2015-03-12 15:14
Last Updated: 2018-06-02 09:31

Latest Comments

1 2 Next › Last »

2ion commented on 2018-08-29 20:10

@gesh: Why would you want to retain a completion definition if you uninstalled the package? I can't think of a good reason right now.

Besides, due to how /usr/share/bash-completion/bash_completion works, the file will be sourced regardless of its extension, so now you'd end up with a .pacsave that's still getting sourced and need to care about it -- one more thing to think about.

I don't see any upside in terms of user experience in your suggestion.

gesh commented on 2018-08-29 18:44

Hi. Instead of deleting /etc/bash_completion.d/mpv using a .install file, wouldn't it be possible to just install an empty file in the package and use the hook to populate it? Judging by pacman(8)'s description of how it handles .pacnew files, this should Just Work(TM), but I haven't actually tried it. Thanks for the package!

2ion commented on 2017-10-29 15:23


1. Both and mpv-bash-completion are ugly hacks. They both rely on parsing mpv --list-options or mpv --$option help, the format of which changes all the time, there's no standard, just patterns to cobble together. Something is broken all the time. The thing that's ultimately needed is an API which exports the mpv option tree completely, options plus parameters plus parameter defaults plus parameter types plus alias information, following some defined schema, which can be used as the input for any completion generator. I don't want to upstream ugly hacks.

2. mpv-bash-completion is more complex than, part of that being due to Bash providing almost no completion framework at all and part being due to mpv-bash-completion probably having more features (filter and object parameter completion) (I didn't check). To upstream it, the code would need refactoring and documentation. And then it needs to be maintained, with frequent fixes due to (1), which brings me to

3. I don't want to relinquish ownership of the code and go through mpv maintainers all the time to fix things. Again, if we had solved (1), the code could be written correctly, upstreamed and just work.

I'm hoping to invest time into (1) at some point, but that'll happen in 2018 at the earliest.

sl1pkn07 commented on 2017-10-28 16:59


one question. why not try to make include this into mpv sources like zsh completion?


2ion commented on 2016-06-27 15:08

Version 3 is a full rewrite in Lua which fixes many incorrect or missing completions. Also, this package installs a pacman hook which automatically updates the completion between mpv version upgrades.

2ion commented on 2016-03-06 04:55

@sekret: Sorry about the version number messup; I forgot to push the last change to the PKGBUILD last night which normalized versioning.

As for the (ab-)use of the epoch field: Until the introduction of hooks, the package needed to be rebuilt manually for any update to mpv that changed the set of available options. In order to be able to see if the currently installed completion was out-of-date, the pkgver was set to the version of the mpv package the completion was generated from. Accordingly, whenever I made a substantial improvement to the upstream source or the PKGBUILD (both of which I own, and I'm using the PKGBUILD to install it on my system) I'd liked to push to every user, I'd increment the epoch in order to force rebuilds as I couldn't know what actual version number the package on users' systems would have. The weird package number you saw earlier was the version from my own mpv package mpv-legacy-af-git, a slip-up.

From now (epoch 8) onward, with hooks for triggering rebuilds having been made available and implemented here, versioning will (roughly) follow packaging guidelines. pkgver is now a static field.

sekret commented on 2016-03-05 23:49

And how did you come up with this pkgver 0.16.0+1 ??? When I run makepkg on your PKGBUILD, I get 0.16.0 , so what is this "+1" ??? With this pkgver you provide cower always reports your package as outdated on my machine, although I'm up to date.

sekret commented on 2016-03-05 19:02

One quick question: Why do you use epoch so much? epoch is supposed to be used for e.g. forced downgrades, so pacman or yaourt or whatever still "sees" it as an "update". You seem to use it all the time, which is really not necessary! As long as $pkgver-$pkgrel goes up, there's no need to bump epoch!

2ion commented on 2016-03-05 14:47

From epoch 4 onward, we utilize pacman/libalpm hooks for generating the completion file both after installing this completion package for the first time and also automatically whenever you update mpv.

Because there are various flavours of mpv around when including the AUR, the rebuild trigger acts on all packages matching 'mpv' and 'mpv-*'. This is due to the libalpm trigger not being able to act on packages which just 'provide' mpv.

In my opinion, this solution works well enough.

2ion commented on 2016-02-07 11:42

Reflected changes in recent versions of mpv which should fix a lot of erroneous completions.