Filtered Recent Changes

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 WikiBadges 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.