What if there were, in addition to the "regular" RecentChanges page, an arbitrary number of FilteredRecentChanges pages? A FilteredRecentChanges page would be a page where the current contents of RecentChanges were passed through a filter supplied by the user. Here are some possible filters that strike me as interesting:

* '''FilterByCategory''': Shows only those RecentChanges that contain a particular category tag or tags.
* '''FilterByContributor''': Shows only those RecentChanges that were made by the particular contributor, identified by either UserName or IP address.
* '''FilterByContent''': Shows only those RecentChanges that contain certain text.
* '''FilterByDeletion''': Filter out pages that have been deleted at any time today?
* '''FilterByWikiBadge''': GoogleScript it so pages with WikiBadge''''''s like CategoryOffTopic can be voluntarily filtered out.
* '''FilterByPersonalWatchList'''
* others?

You get the idea. It also occurs to me that the inverses might be helpful:

* '''FilterWithoutCategory''': Exclude a particular category tag or tags from RecentChanges.
* '''FilterWithoutContributor''': A particularly effective way of limiting the impact of certain individuals
* '''FilterWithoutContent''': Listed here for symmetry.


I wonder if there might be a mechanism to allow the filters chosen by a particular user to be persistent. The UserName mechanism itself already depends on cookies; perhaps the UserName page could be adjusted to also store filters along with the cookie. Meanwhile, a FilteredRecentChanges could provide space on the form itself to key in various expressions.

I know some similar ideas were discussed a few years ago, I just wondered if this might be a constructive way to address some of the issues that have surfaced since Christmas. -- TomStambaugh

''I like the filter approach, just not the cookie approach. I delete all my cookies on browser startup(and I can't isolate to save certain ones), so UserName is already broken for me, or at least very cumbersome.''

Suggestion: fix your browser instead of dragging down the progress.

Would you find a username/password combination (prior to editing, for example) preferable to persistent cookies (the site would still probably need a cookie for the duration of a single session)?

Hrm. How about a mechanism for defining the filter based on tags in a person's user page? Then we'd only have to worry about one cookie, and it could be used for other things.... Although this seems kind of messy.
----

The problem with the technicalities behind FilteredRecentChanges is that they address the wrong problems. They do not address the issues defined in SensitiveOffTopic.
----

And now for something completely different... A lynx -dump (LynxBrowser) piped to a grep RegularExpression can be used for interesting filtering, although it will not produce clickable links. A CeeShell (tcsh) example:

 lynx -dump 'http://c2.com/cgi/wiki?RecentChanges' | grep -E '( November [1-9])|(\*.+ipt\.aol\.com$)'
Result:
   November 23, 2004
     * [99]WorkOnCategoriesDiscussion . . . . . . aca9f6c5.ipt.aol.com
     * [122]AugustaAdaByron . . . . . . aca633e0.ipt.aol.com
     * [130]CategoryGardeningMetaphor . . . . . . ac816bd5.ipt.aol.com
   November 24, 2004
     * [184]VotingMachineDiscussion . . . . . . acc23f12.ipt.aol.com
     * [322]CategoryCategory . . . . . . ac935c61.ipt.aol.com
   November 25, 2004
     * [390]CorelDraw . . . . . . aca98fa4.ipt.aol.com
     * [394]CornerStone . . . . . . aca98fa4.ipt.aol.com
     * [406]DesqView . . . . . . aca90fac.ipt.aol.com
     * [413]GwBasic . . . . . . aca90fac.ipt.aol.com
     * [420]CategoryOldSoftware . . . . . . ac90128a.ipt.aol.com
   November 26, 2004
     * [622]MsDos . . . . . . ac961c14.ipt.aol.com
   November 27, 2004
     * [854]NortonCommander . . . . . . ac91213e.ipt.aol.com
     * [857]RapidFile . . . . . . ac91213e.ipt.aol.com
Not to pick on ipt.aol.com, but this listing does have its beauty. Come to think of it, this trick ''does'' produce clickable links if you paste the results into a wiki page.