There was always some semblance that two blank lines has some kind of
meaning or structure that's different from single blank lines, but
in reality it was mostly arbitrary and I can't stand to look at it
any more.
Any properties that are different in wide/narrow mode should be defined
in the correct media query. I got tired of having wide mode be the
default and then narrow mode having to unset/initial all the attributes
that aren't relevant to narrow.
First of all, I realized the return statement was using the
outdated singular name of the method. But anyway, I don't like the
idea that this method would sometimes return a single album by id
or a list of albums by path. If you want to get by path, use
get_albums_by_path explicitly.
I have always felt bad about forbidding unicode in tag names,
but I want to make sure I have a grip on sanitization / preventing
abuse before allowing it. I think stripping control characters is
enough and any abuse can be handled manually.
Of course that's all fiction because there are no users except myself.
When I first added album cards I left this line on the to do list
because I wasn't sure if I would wind up scrapping them. Although they
still need refinement, I know they'll be sticking around so let's
remove this.
Let's see if this inode tracking thing works out, and it might be
an adequate solution to the problem. As long as non-unix filesystems
work reliably and you aren't moving files across partitions.
Hashing is still an idea on the table.
It turns out you can't adjust foreign_keys while a transaction is active,
so the upgraders that need to disable and re-enable them were not
working right and encountering foreign key violations.
