Re: RFE: regex backrefs
On Wed, Jul 31, 2002 at 10:57:39AM -0400, Ricardo SIGNES wrote: I know this has been brought up before, but I just thought I'd voice my deep desire: mutt should be able to have backrefs to its regexen. If I get a 'vote' in future development, this is how I would cast it. My C is crappy, or I'd shut up and code it. Yup, can but agree to the world's regexes improving in power. However, (he says, feverishly attempting to disguise a but) is there any enthusiasm for employing a most commonly used regex library, such that any improvements can feed back into all the tools using it? While procmail seems to be out on a long plank in the middle of a swamp, it would be cosmically empowering to be able to move between mutt, vim, awk, and grep without tripping over too many differences in regex dialects. Is this too ambitious a wish? Regards, Erik
Re: RFE: regex backrefs
On Wed, Jul 31, 2002 at 03:57:13PM -0700, Michael Elkins wrote: While this might look simple, it's more difficult to implement than you might think. Why? Becuse the regexp here is not just one regular No, I know how difficult it is. ;) At any rate, your example above can be solved as follows: #!/bin/sh for i in ~/Mail/friends.*; do echo folder-hook $i my_hdr From: jsmith-`echo $i|sed 's;^.*\.;;'`@friends.domain.org; done Yeah, I do something roughly like that, now. I've just always thought it'd be more elegant and generically useful to have backrefs. :) -- rjbs msg30044/pgp0.pgp Description: PGP signature
RFE: regex backrefs
I know this has been brought up before, but I just thought I'd voice my deep desire: mutt should be able to have backrefs to its regexen. If I get a 'vote' in future development, this is how I would cast it. My C is crappy, or I'd shut up and code it. Imagine the power available in something as simple as: folder-hook =friends\.([a-z]+) my_hdr From: jsmith-\[EMAIL PROTECTED] This is only a tiny fraction of the Supreme Cosmic Power that this could unlock. -- rjbs msg29996/pgp0.pgp Description: PGP signature
Re: RFE: regex backrefs
On Wed, Jul 31, 2002 at 05:08:25PM +0200, Roman Neuhauser wrote: my deep desire: mutt should be able to have backrefs to its regexen. this reminds me: how hard would it be to make mutt use libpcre? And, how much would it slow down / bloat up mutt, if at all? -- rjbs msg29997/pgp0.pgp Description: PGP signature
Re: RFE: regex backrefs
Date: Wed, 31 Jul 2002 10:57:39 -0400 From: Ricardo SIGNES [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RFE: regex backrefs I know this has been brought up before, but I just thought I'd voice my deep desire: mutt should be able to have backrefs to its regexen. If I get a 'vote' in future development, this is how I would cast it. My C is crappy, or I'd shut up and code it. Imagine the power available in something as simple as: folder-hook =friends\.([a-z]+)my_hdr From: jsmith-\[EMAIL PROTECTED] This is only a tiny fraction of the Supreme Cosmic Power that this could unlock. this reminds me: how hard would it be to make mutt use libpcre? -- FreeBSD 4.6-STABLE 5:07PM up 1 day, 43 mins, 4 users, load averages: 0.04, 0.04, 0.01
Re: RFE: regex backrefs
* Ricardo SIGNES ([EMAIL PROTECTED]) [01 Aug 2002 01:21]: On Wed, Jul 31, 2002 at 05:08:25PM +0200, Roman Neuhauser wrote: this reminds me: how hard would it be to make mutt use libpcre? And, how much would it slow down / bloat up mutt, if at all? Strictly speaking, if used as a shared library, and existing regexp support is blown away and replaced, then it reduces bloat. The problem is, such a change would probably kill everyone's existing configurations. You'd need something like Vim's \m, \M, \v, \V escapes (magic, no magic, very magic, very no magic), only probably \P (use PCRE; assuming \P isn't taken by PCRE). cheers, -- Iain 'Spoon' Truskett. http://eh.org/~koschei/
Re: RFE: regex backrefs
Date: Thu, 1 Aug 2002 01:25:27 +1000 From: Iain Truskett [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: RFE: regex backrefs * Ricardo SIGNES ([EMAIL PROTECTED]) [01 Aug 2002 01:21]: On Wed, Jul 31, 2002 at 05:08:25PM +0200, Roman Neuhauser wrote: this reminds me: how hard would it be to make mutt use libpcre? And, how much would it slow down / bloat up mutt, if at all? Strictly speaking, if used as a shared library, and existing regexp support is blown away and replaced, then it reduces bloat. The problem is, such a change would probably kill everyone's existing configurations. You'd need something like Vim's \m, \M, \v, \V escapes (magic, no magic, very magic, very no magic), only probably \P (use PCRE; assuming \P isn't taken by PCRE). while i very much appreciate the fact that i can use 1.5 with .muttrc created for 1.2.5i (i think only noted one or two non-bugfix changes between 1.2.5i and 1.5.1i), such changes are what major version number bumps are for. btw, vim's regex support is completely b0rken IMO. its (no) magic switches... weird syntax... ugh. if PCRE was adopted, and used as the only regex library in the next major mutt version, such an escape wouldn't be needed. anyway, PCRE is quite ubiquitous (apache 2, postfix, python, php...), and a de facto standard. standards are god. -- FreeBSD 4.6-STABLE 5:40PM up 1 day, 1:17, 7 users, load averages: 0.00, 0.00, 0.00
Re: RFE: regex backrefs
On Wed, Jul 31, 2002 at 05:54:42PM +0200, Roman Neuhauser wrote: btw, vim's regex support is completely b0rken IMO. its (no) magic switches... weird syntax... ugh. Given that vim's regexes are based on vi's which are based on ed's, and ed was the first UNIX program to *have* regexes, it's hardly fair to call its regex support broken. It just has to be backward-compatible with a regex flavor that has been superceded, so it uses special escapes. It's the same reason that modern grep programs, which have features formerly found only in egrep, use \+ instead of +, \| instead of |, etc. Meanwhile, the 'magic' stuff was orignally put in vi to make the more common cases easier for new users, but it has been expanded in vim to the point where you can set it up to have a fairly modern regex syntax (with fewer backslashes, etc). Vim may not have modern innovations from Perl 5 like non-capturing grouping, lookaround, etc., but it's hardly broken. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754 -- Photographing a volcano is just about the most miserable thing you can do. -- Robert B. Goodman [Who has clearly never tried to use a PDP-10. Ed.]
Re: RFE: regex backrefs
* On 2002.07.31, in [EMAIL PROTECTED], * Roman Neuhauser [EMAIL PROTECTED] wrote: Strictly speaking, if used as a shared library, and existing regexp support is blown away and replaced, then it reduces bloat. Not necessarily. I'm not already using pcre, so it still bloats my system to load it whether it's dynamic or static. That's without getting into whether I'd *want* to compile with shared libraries, since I'm on Solaris (where you're bludgeoned into using shared libraries whether you want to or not). Anyway, my point is that this is probably beside the point. :) The problem is, such a change would probably kill everyone's existing configurations. You'd need something like Vim's \m, \M, \v, \V escapes (magic, no magic, very magic, very no magic), only probably \P (use PCRE; assuming \P isn't taken by PCRE). It seems that it should be a relatively simple matter to use pcre instead of the usual regex library on the basis of --with-pcre or somesuch -- that is, it doesn't need to be made the default in order to enable it. If I cared for Perl regexes, I might try to do that... but I like extended regular expressions just fine. However, if someone else wants to try it, it feels like it should work. -- -D.Fresh fruit enriches everyone. Takes the thirst Sun Project, APC/UCCO out of everyday time. A pure whiff of oxygen, University of Chicago painting over a monochrome world in primary colors. [EMAIL PROTECTED] We all know that. It's why everyone loves fruit.
Re: RFE: regex backrefs
Oops, I meant to reply to Roman's text, too, but my delete finger was hyperactive. * On 2002.07.31, in [EMAIL PROTECTED], * Roman Neuhauser [EMAIL PROTECTED] wrote: btw, vim's regex support is completely b0rken IMO. its (no) magic switches... weird syntax... ugh. What Mark said. if PCRE was adopted, and used as the only regex library in the next major mutt version, such an escape wouldn't be needed. anyway, PCRE is quite ubiquitous (apache 2, postfix, python, php...), and a de facto standard. standards are god. I don't think it's any kind of standard, just a somewhat widely-available option. I've never used it, for example -- not overtly, not unless it was sneakily included in the distribution of some software I compiled. Mutt has long tried hard not to require extra stuff to compile. Requiring a functional iconv (meaning installing libiconv if you're not on a complaint system) is a reasonable compromise, given Mutt's design goals. Likewise, you might need ncurses or slang if your native curses are sufficiently broken. But in general, mutt does not require extra software (not even gmake) to be installed before you can compile and/or run it, and that's very, very good. -- -D.Fresh fruit enriches everyone. Takes the thirst Sun Project, APC/UCCO out of everyday time. A pure whiff of oxygen, University of Chicago painting over a monochrome world in primary colors. [EMAIL PROTECTED] We all know that. It's why everyone loves fruit.
Re: RFE: regex backrefs
* Mark J. Reed ([EMAIL PROTECTED]) [01 Aug 2002 02:05]: [...] Vim may not have modern innovations from Perl 5 like non-capturing grouping, lookaround, etc., but it's hardly broken. Actually, vim has non-capturing grouping and look-ahead/behind. And with the various magic escapes, you can have it compatible with vi, or you can have it feel rather natural. I'll definitely agree it's not broken, and would say it's more powerful than a lot of other flavours of regex. Plus it has the features an editor needs (matching columns, matching as much of, etc.). I'm not sure mutt needs such features, mind you. The only extension I've needed to mutt's matching facilities was an extension to the patterns (matching a folder). I find the regexs fine. cheers, -- Iain 'Spoon' Truskett. http://eh.org/~koschei/
Re: RFE: regex backrefs
Ricardo SIGNES wrote: I know this has been brought up before, but I just thought I'd voice my deep desire: mutt should be able to have backrefs to its regexen. If I get a 'vote' in future development, this is how I would cast it. My C is crappy, or I'd shut up and code it. Imagine the power available in something as simple as: folder-hook =friends\.([a-z]+)my_hdr From: jsmith-\[EMAIL PROTECTED] While this might look simple, it's more difficult to implement than you might think. Why? Becuse the regexp here is not just one regular expression. The =friends\.([a-z]+) is actually expanded with the $default_hook variable, which by default is ~f %s !~P | ~P ~C %s, thus translating your example above into ~f =friends\.([a-z]+) !~P | ~P ~C =friends\.([a-z]+) So now what does \1 really refer to? It gets even worse when you have multiple *different* regular expressions in complex patterns. It's not that the Mutt developers don't think would be useful to do, its just a bear of a problem to tackle. At any rate, your example above can be solved as follows: 1) create a script which generats folder-hook commands for all of your `friend' mailboxes: #!/bin/sh for i in ~/Mail/friends.*; do echo folder-hook $i my_hdr From: jsmith-`echo $i|sed 's;^.*\.;;'`@friends.domain.org; done 2) source this script from your ~/.muttrc source ~/bin/hookgen.sh|
