On Mon, Jan 19, 2009 at 08:59:38AM +0000, Eric Kow wrote: > Refactor actual_boring_file_filter. > ----------------------------------- > > +-- | From a list of paths, filter out any that are within @_darcs@ or > > +-- match a boring regexp. > > actual_boring_file_filter :: [Regex] -> [FilePath] -> [FilePath] > > hunk ./src/Darcs/Repository/Prefs.lhs 289 > > -actual_boring_file_filter regexps fs = > > - filter (abf (not.is_darcsdir) regexps . normalize) fs > > - where > > - abf fi (r:rs) = abf (\f -> fi f && isNothing (matchRegex r f)) rs > > - abf fi [] = fi > > > +actual_boring_file_filter regexps files = filter (not . boring) files > > + where boring file = is_darcsdir file || > > + any (\regexp -> isJust $ matchRegex regexp file) > > regexps > > No more normalize? Why not?
Zoiks! It was removed accidentally. > Also, you can eta-reduce your version if you want: > > actual_boring_file_filter regexps = filter (not . boring) I'm no longer a fan of eta-reduce. I tried point-free form (in the guise of Factor, a Forth-like language) and discovered that it makes my brain hurt when trying to trace execution. > Refactor darcs_binaries. > ------------------------ > > Trent W. Buck <[email protected]>**20090117135906 > > Ignore-this: 76174e648ec72ace6f26e6372a4e816 > > > > Instead of creating a very long list of simple regexps, this now > > creates two regexps of the form \.(a|b|...|z)$, the latter being > > uppercase. I have also combined some extension variants (e.g. .jpe?g > > instead of two entries .jpg and .jpeg) and sorted the extension list. > > > > I've elected NOT to use Emacs' regexp-opt to build a faster regexp, > > because that would make it very hard for end users to find and remove > > an extension from the default list. I think merging .jpe?g is OK. > > But would the very long list of simpler regexps easier for human beings > to work with? IMO no, because they scroll offscreen. If people favour the old approach, I at least advocate \.(png|PNG)$ instead of \.png$ \.PNG$ > (i.e. you look into binaries file and instantly understand > how to add something by copy and pasting... notably by inserting a whole > new line, not by modifying a pre-existing one) Hopefully the extended commentary makes it easier to understand how to work with the file (and indeed, what it does). > Also, I wonder if there is a way within the regexp to request case > insensitive matching Yes, but it's extraordinarily ugly: \.[pP][nN][gG]$ To add something like perl's /\.png$/i, where the 'i' signifies insensitivity, would require a change to the on-disk format of the _darcs/prefs/binaries file. Unless you want to change the *semantics* of that file, such that it ALWAYS matches case-insensitively? Under what circumstances would we want to mark as a binary (or as boring) paths by a case-sensitive regexp? I guess you wouldn't expect things like ./src/rcs/ to be ignored just because ./RCS/ is a metadata directory. _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
