emms-help
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Default info methods


From: Petteri Hintsanen
Subject: Re: Default info methods
Date: Mon, 08 Mar 2021 21:05:14 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Yoni Rabkin <yoni@rabkins.net> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]