Yoni Rabkin <[email protected]> writes:
> emms-info-native should be the default on a new install. Couple that
> with a manual which robustly explains the other info methods that people
> can use if they so choose either to replace emms-info-native or go
> beyond it.
>
> You can go ahead and make that change now so that people will have a
> month to play with it from the git repo before a release to elpa on the
> first of May.
Ok, I will do that.
> If course none of this should change anyone's existing setup, but we
> should also make people with existing setups aware that emms-info-native
> is now available.
Unfortunately it does: if someone uses (emms-all) without any custom
emms-info-functions, she will effectively get
(setq emms-info-functions ('emms-info-native))
instead of
(setq emms-info-functions '('emms-info-mp3info 'emms-info-ogginfo
'emms-info-opusinfo 'emms-info-cueinfo))
or some subset of that, depending on whatever software in installed on
her system.
However, in practice emms-info-native should provide everything except
id3v1 and cueinfo, so I think the new default is relatively safe and
does not break backward compatibility too much. I would also expect
that most people do have customized their emms-info-functions.
This can and should be described in the manual as well, including how to
get back to the previous default in case something broke.
> Looking forward, it may be a good idea to eventually expand emms-info to
> permit setups such as:
>
> (setq emms-info-methods '((("*.flac" "*.flc") . emms-info-metaflac)
> (t . emms-info-native)))
>
> Which would first hand specific jobs to particular backends, and finally
> use the "t" backend as the catch-all.
This is a good idea.
I was pondering an idea where emms-info-functions would be called one at
a time, like now, but instead of going through all functions, processing
would stop as soon as some function returns non-nil. So
emms-info-functions would be evaluated like short-circuiting OR
expression.
But your alist is much better solution.
--
Petteri
