Zsh completion does not match enough extensions #2273
Comments
|
Generally mpv supports many more file extensions than that, but since file format detection usually works by content and not by extension, most extensions are not known. Which probably means the zsh script shouldn't white-list file extensions and just accept everything. |
|
mmhmm. maybe it would be better to have some option for this? "all files, try file extensions, detect ff, check fe then ff" I don't know how that would work in zsh though. |
|
Strongly agree that it should complete on all file types. When in doubt, don't try to be smart. I run into this issue often enough. For example, PNG/JPG files don't get detected even though I open them routinely. |
|
for file extensions, here is a list:
true, but probing all files actually requires more work. here are options as I see them:
I am in favor of options 3 and 6. 5 has all the downsides of 3 (i.e. may not match some files) with only the small upside of discarding irrelevant files. 4 is too slow when operating in large directories. for context, on my CPU, |
|
Wait, why is ffprobe being run when tab completing? That makes no sense to me. Can't it just display a list of files normally like every other completion script in the world manages to do so? |
|
it's not, at least now anyways; the idea is that completers should filter arguments to only those that the command can accept. I guess I'll add 7, "kick the file completer and show everything". |
|
Then I vote 7. When in doubt, don't try to be smart. Especially if it causes bad behavior. |
|
+1 |
|
Sorry, saw this yesterday but haven't had time. Just to be clear, what currently happens is matching files with a simple glob based on file extension, with a hardcoded list (shown in the OP) that probably came from an old mplayer completion script. Running ffprobe on every file for tab completion would be ridiculous, IMO. Tab completion isn't going to save you a whole lot of time if it takes several seconds to run. And imagine if you were on a network filesystem. I think file extension is the only thing we're going to be able to work with here. So the only thing to really decide here is whether or not it's worth trying to filter by extension at all. I'm not entirely sure how I feel about that, actually. I remember being mildly annoyed when I first started using the completion script and wishing it would just give me all files (as has been expressed in this thread already), but now that I've gotten used to it, it is kind of nice sometimes, to to weed out extra files if you're in a directory with a bunch of different stuff in it. Note that (at least in my zsh config), it will fall back to all files if nothing matches, so it will still complete files that don't have matching extensions if you type enough to eliminate any files that do (or are in a directory where there aren't any). If we are going to keep the extension-based filtering, putting that huge list in is definitely not going to work. One issue is that it probably depends on how ffmpeg was compiled, but even ignoring that, a lot of those don't actually make any sense. For example, I'm sure there's some media file out there that ends with .js, but realistically, a random .js file is probably javascript and better left out of the completion. Another example is subtitle files like .ass/.srt/.lrc, which can't be played by themselves. In fact, files like that may have the same name as a video file they go along with, and actually get in the way of completion for that file. One thing that might actually be cool would be if there is a video file and an audio file with the same name, only complete the video one, but I'm not sure if that'd be worth the effort to implement. Even with a manually maintained list of extensions, there isn't necessarily going to be a list that is perfect for everyone. For example, haasn wants PNG/JPG, but I don't use mpv on those very often, so I'd rather they be excluded if I'm in a directory that has those along with some video or audio files. If a given user cares enough, they can override the pattern using
In any case, customization is possible if you really care. However, the zstyle stuff is kind of weird and non-obvious, so you do have to really care; the majority of users likely won't even know they can change it, much less actually do so. (I didn't even know you could do that until I just looked it up.) So what it comes down to is, by default, do we want to provide a smoother common-case experience at the expense of possible annoyance/confusion, or be safe and show everything, but make people type more? |
Could it be possible to build this behavior right into the completion script? |
|
Probably, but it seems unnecessary when zsh already does it by default and allows the user to customize it. It's actually the same
|
|
Would it be possible to put the ones with the known extensions first in the lest, and any other remaining file after that? That way you can tap Tab once or twice in the common case, but still be able to complete those lesser used files. Do you thing something like that would be possible/useful? |
That should be possible, at least if the user's configuration agrees. The But having two separate lists will break alphabetical order, which could be confusing, and then there's also the question of where in the order to put directories. Also, it doesn't have all the advantages of normal filtering. It might help in the case that you're tabbing through a list, but it doesn't reduce the amount you have to type if you want to narrow it down that way. The advantage of filtering based on extension is not just a smaller list, but (perhaps more importantly) that if a matching and non-matching file share some prefix, you can complete the matching file right away by typing that prefix, instead of having to disambiguate. Basically, I don't think there's any way we're going to get around making a trade-off here. So I'd rather not do something like that. I understand the want for a compromise, but I think it's giving up a lot of the benefit of extension filtering and adding potential confusion, in exchange for better results in what I think would be a pretty rare case. |
|
As OP has pointed out youtube-dl downloads m4a and webm. And aac is also popular enough to add it to the default list. |
|
#3459 reminded me of this. I'm now leaning toward getting rid of the extensions entirely as well. I realized that the current behaviour still surprises me sometimes; even though I immediately know what happened, it makes me stop typing and think. I'll probably still try to customize it for my own config, but we can't come up with any such config that suits everyone, and it's probably better to have people who want customization do it themselves, rather than make everyone else "customize" things to remove behaviour that doesn't do what they expect. I can put some examples on the wiki for people who do want to customize. You can also obviate much of the need for this kind of filtering if you use a clever matcher-list that allows you to easily complete against extensions. I think I'll PR that next weekend if there isn't a ton of complaining in the meantime. Calling @wgmk here because he/she might have an opinion. |
ghost
closed this as 
right now it only matches
asf|asx|avi|flac|flv|m1v|m2p|m2v|m4v|mjpg|mka|mkv|mov|mp3|mp4|mpe|mpeg|mpg|ogg|ogm|ogv|qt|rm|ts|vob|wav|webm|wma|wmv. more common audio extensions:3gp|act|aiff|aac|amr|au|awb|m4a|mpc|oga|opus|ra|webm. more video extensions:rmvb|m4v.not sure if all are actually supported by mpv, but at least youtube-dl saves files as
m4aandwebm.The text was updated successfully, but these errors were encountered: