9b83cef was a little too aggressive; we need most objects to go through
unconverted so '{0.title}' and such still work in format strings. This is now
just a targeted workaround for the case I encountered.
The beets loggers now, as proposed in #1044, do their utmost to avoid crashing
when logged values are not valid Unicode or Unicode-convertible. This came up
urgently when a `CalledProcessError` could not be logged with `'u{}'.format()`
(!!!) so we needed to some manner of conversion, but it should be possible to
log paths without `displayable_path`. In fact, it may be time to retire
`displayable_path` for the most part.
We were being sloppy about bytes output from the process. Also, it seems like
the tools outputs the path also, so it's necessary to break on whitespace to
actually get the key name.
Use config.__class__.__name__ instead of "ConfigView" in __repr__().
Before:
>>> from beets import ui
>>> c
<ConfigView: root>
>>> c['foo']
<ConfigView: foo>
After:
>>> from beets import ui
>>> c
<LazyConfig: root>
>>> c['foo']
<Subview: foo>
As per PEP234 (https://www.python.org/dev/peps/pep-0234/) if an object
has __getitem__() but not __iter__() then the former will be used to
build an iterable, invoking it with 0, then 1, ... until a KeyError is
raised. Lazy configuration makes it never happen, and list(config) runs
indefinitely, hogging all memory.
Implement __iter__(), which raises a TypeError, to solve that problem.
I inserted musicbrainz.searchlimit at the wrong place, breaking the
hyperlink target `match-config` - and I also forgot to add a hyperlink
target for `searchlimit`.
This avoids bugs when the filename contains spaces, etc.
Pinging @Kraymer: I gave this a brief test, but can you check whether I messed
anything up more subtly?
Came up when looking at #1241.
It has been a while since I have looked at these, and many of the FIXMEs no
longer make sense to me. Better to open issues if there's really something to
fix.
