Few people used dmail filters (~900 users in 5 years) and even fewer
used them correctly. Most people used them to try to block dmail spam,
but usually they either blocked too much (by adding common words that
are present in nearly all dmails, causing all mails to them to be
filtered) or too little (blocking specific email addresses or urls,
which usually are never seen again after the spammer is banned).
Nowadays the spam detection system does a better job of filtering spam.
* Rename 'privacy mode' to 'private favorites'.
* Make the private favorites setting only hide favorites, not favgroups
and not the user's uploads on their profile page.
* Make the favgroup is_public flag default to true instead of false and
fix existing favgroups to be public if the user didn't have privacy mode
enabled before.
* List _all_ public favgroups on the /favorite_groups index, not just
favgroups belonging to the current user.
* Add a /users/<id>/favorite_groups endpoint.
* Remove 'Change password' and 'Delete account' tabs.
* Put 'Change password' under the Basic section.
* Put 'Deactivate account' under the Advanced section.
* Add help text to various settings.
Mark all tag <input>s with a `data-autocomplete` attribute, instead of
hardcoding a list of html IDs to autocomplete in javascript.
This way should be less error prone. It fixes autocomplete in several places:
* Autocomplete for the search box on /posts didn't work in the
responsive layout. This was because /posts has two search boxes that
both have the id `tags`: one in the normal sidebar, and one in the
responsive tag list. $("#tags") only initialized autocomplete on the
first one.
* Autocomplete didn't work on the aliases or implications pages. This
was due to selecting the wrong html ids.
