On Tue, May 18, 2004 at 10:44:15AM EDT, Charles Cazabon wrote: > David Yitzchak Cohen <lists+mutt_users@xxxxxxxxxxxxxx> wrote: > Ugh. Thanks for clarifying; I thought the alternates/unalternates > functionality was more like: > > IF address matches an RE from the alternates command, > AND it does not match any RE from the unalternates command, > THEN the address refers to "me". That'd require an extra step to be implemented. > > If you want to exclude stuff, you'll need to explicitely exclude the gunk in > > your alternates statement using regex syntax. > > Okay. "Match everything but these strings" is one of the uglier things to do > with an RE, which is why I thought unalternates would work the way I read the > documentation -- it would be more usable, in fact. Maybe I should file a > request on mutt-dev. The thing is, Mutt's regex list handling code (which is now used for a bunch of things) is designed to work with positive matching lists, not exception lists. The unalternates statement simply looks through a preexisting regex list and tries to nuke a matching rule. If you wanted to make every regex list to actually be a set of two bound regex lists (one for matching and one for blacklisting), you'd be going from two possible operations (adding to the match list; removing from the match list) to four possible operations (adding to the match list; removing from the match list; adding to the blacklist; removing from the blacklist), which in turn would require either (a) two new statements (nonalternates and unnonalternates in this case, maybe?) for every statement pair that currently uses regex lists, or (b) a "clever" overloading of the current alternates and unalternates commands to make them do "the right thing" by trying to guess which operation you wanted to invoke. As you can tell, the ugliness factor here is even higher, since this really isn't the right place to solve the problem. The reason is simple: what matches and what doesn't match a conceptual "thing" is really one idea, tied directly to it. Regex languages allow us (albeit with rather clumsy notation) to store all the matching information (which _should_ include all exceptions, as I pointed out above without giving much of an argument - go [OT] if you wanna debate) right inside the matching rule, avoiding the complexity of having two lists (which you'll need to logically subtract in order to make a useful result) for identifying one thing. Obviously, another choice you have is to replace the regex library with your own (possibly calling the existing one at convenient points of interest - e.g., as the back-end for implementing the regex pair) implementing a much simpler exception syntax, allowing you to have your cake (not troubling Mutt with your "simplified" physical representation of a list as two subtracted lists) and eat it too (having a "simplified" regex syntax with separate regexes for matching and blacklisting). To clarify the user's view, you'd be able to do something like "alternates .*@goo\.com(?butnot)blah@goo\.com" and the regex wrapper would split it into a match rule (.*@goo\.com) and a blacklist rule (blah@goo\.com), and store each rule (itself a regex, physically) in the appropriate "slot" of the logical regex. No code outside of the regex library (and the definition of a regex, unless you're clever) would need to be changed, and the existing library could even be used almost unchanged (just renaming the functions to avoid clashes) as the back-end. (The fact that this solution is so elegant effortlessly should tell you something about the likely validity of the conceptual assertion I made earlier, BTW.) HTH, - Dave -- Uncle Cosmo, why do they call this a word processor? It's simple, Skyler. You've seen what food processors do to food, right? Please visit this link: http://rotter.net/israel
Attachment:
pgpM8Vr7DT0OO.pgp
Description: PGP signature