Re: Clarification on tag-prefix-cond vs. tag-prefix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday, February 15 at 10:47 AM, quoth Jan-Herbert Damm: With gratefulness an admiration i studied this manual-worthy explanation! Glad to help! In this case, the match-type-specifier is ~r. In the manual though they call it pattern-modifiers. Meh, a rose by any other name... I just made up match-type-specifier, because it made more sense to me as a description of what that thing does. And Simple patterns seem to be specifically associated with certain keywords replacing ~,%,= expressions. Keywords? Replacing? No, the ~ or % or = don't get *replaced*. We must be talking past each other here. ~Kyle - -- Dealing with failure is easy: Work hard to improve. Success is also easy to handle: You've solved the wrong problem. Work hard to improve. -- Alan Perlis -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iEYEARECAAYFAkmYRmIACgkQBkIOoMqOI168QgCfS1n6TQ3K+HZvxqguTtwM8sGB mY8AoLCOGuBmZOh2mcz6thR6PIaA4IDq =Vl2b -END PGP SIGNATURE-
Re: Clarification on tag-prefix-cond vs. tag-prefix
Hello, And Simple patterns seem to be specifically associated with certain keywords replacing ~,%,= expressions. Keywords? Replacing? No, the ~ or % or = don't get *replaced*. We must be talking past each other here. indeed, I was being unprecise. The manual (Chapter Advanced Usage) is saying this about simple *searches* not simple *patterns*. I still find it confusing if not contradictory, because the searching by keywords (= not valid patterns) is explained directly below the heading Simple Patterns. Thus i conclude a seemingly invalid pattern must be the announced simple pattern as in simplified pattern. --snip from the manual-- 2.2. Simple Patterns Mutt supports two versions of so called ``simple searches'' which are issued if the query entered for searching, limiting and similar operations does not seem to be a valid pattern (i.e. it does not contain one of these characters: ``~'', ``='' or ``%''). [...] Table 4.2. Simple search keywords ++ | Keyword | Pattern modifier | |-+--| | all | ~A | |-+--| --snip--- but i guess i am splitting hairs as we say in german. Yet i stumble on things like this and start in the wrong tracks... jan
Re: Clarification on tag-prefix-cond vs. tag-prefix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday, February 15 at 07:45 PM, quoth Jan-Herbert Damm: 2.2. Simple Patterns Mutt supports two versions of so called ``simple searches'' which are issued if the query entered for searching, limiting and similar operations does not seem to be a valid pattern (i.e. it does not contain one of these characters: ``~'', ``='' or ``%''). [...] Table 4.2. Simple search keywords ++ | Keyword | Pattern modifier | |-+--| | all | ~A | |-+--| A, *those* things. Think of them as common aliases for simple patterns. all gets translated into ~A. You're right, it can be confusing. :) ~Kyle - -- It is not bigotry to be certain we are right; but it is bigotry to be unable to imagine how we might possibly be wrong. -- Gilbert Chesterton -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iEYEARECAAYFAkmYef8ACgkQBkIOoMqOI141+ACg3cVvXVxQ09Mh5ZdQbUB463I5 pUoAn2JFxurBc/PrBL5PRwjPZzB+xHfa =oPHq -END PGP SIGNATURE-
Re: Clarification on tag-prefix-cond vs. tag-prefix
Hi, * Jan-Herbert Damm wrote: indeed, I was being unprecise. The manual (Chapter Advanced Usage) is saying this about simple *searches* not simple *patterns*. I still find it confusing if not contradictory, because the searching by keywords (= not valid patterns) is explained directly below the heading Simple Patterns. Thus i conclude a seemingly invalid pattern must be the announced simple pattern as in simplified pattern. (What Kyle calls simple pattern is not the same thing as in the manual.) Oh, this is very good catch, thanks. The simple patterns headline doesn't make any sense and it conflicts with the complex patterns headline because they explain totally different things. Now we only need some new good headlines. How about simplified patterns and boolean operators and nesting. I'm thinking about re-ordering the sections so we first have simplified patterns, then pattern modifier and boolean operators and nesting to go from simple to more complex ways of finding messages/things. Opinions? Rocco
Re: Clarification on tag-prefix-cond vs. tag-prefix
* Rocco Rutte pd...@gmx.net [02-15-09 15:46]: Now we only need some new good headlines. How about simplified patterns and boolean operators and nesting. I'm thinking about re-ordering the sections so we first have simplified patterns, then pattern modifier and boolean operators and nesting to go from simple to more complex ways of finding messages/things. Opinions? I believe that it would present a clearer avenue to learning, small steps progressively more complex, and ordered method. -- Patrick Shanahan Plainfield, Indiana, USAHOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535@ http://counter.li.org
Re: Clarification on tag-prefix-cond vs. tag-prefix
Kyle Wheeler: ... However, because I use tag-prefix-cond, when there aren't any tagged messages (i.e. the pattern ~r 3m didn't match anything), mutt will stop processing that hook and none of the rest of it will happen. Does that make sense? yes it does! thank you so much for posting this help on archiving. i learned a lot from reviewing it very slowly. if you don't mind, can you explain the pattern ~r 3m equally well? i know i could figure it out by RTFM but it would take forever. Jan
Re: Clarification on tag-prefix-cond vs. tag-prefix
On Fri, 13 Feb 2009 19:20 +0100, Jan-Herbert Damm jan-h-d...@web.de wrote: Kyle Wheeler: ... However, because I use tag-prefix-cond, when there aren't any tagged messages (i.e. the pattern ~r 3m didn't match anything), mutt will stop processing that hook and none of the rest of it will happen. Does that make sense? yes it does! thank you so much for posting this help on archiving. i learned a lot from reviewing it very slowly. if you don't mind, can you explain the pattern ~r 3m equally well? i know i could figure it out by RTFM but it would take forever. in less than 1 minute - from TFM: ~r MIN-MAX messages with date-received in a Date range 3m greater than 3 months.
Re: Clarification on tag-prefix-cond vs. tag-prefix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday, February 13 at 07:20 PM, quoth Jan-Herbert Damm: if you don't mind, can you explain the pattern ~r 3m equally well? Well, that's pretty simple. First, mutt uses what it calls simple patterns to match messages. (That's what you search for in the manual if you want to find more information.) That right there is a simple pattern. Simple patterns are a match-type-specifier (for lack of a better term) and, for most match types, a match specification. In this case, the match-type-specifier is ~r. These match-type-specifiers are *generally* a tilde and a letter. That's significant, but I'll get to that in a moment. Some simple patterns only need the specifier. For example, ~N is a pattern that matches all new messages. There's nothing more to it. The ~r match-type means messages with 'date-received' in a Date range. In other words, the ~r pattern matches against the date that a message was received (how that date is calculated is somewhat complicated, but let's ignore that). But this pattern takes an argument, so you can specify a range of dates it should match. In the manual, this is described as MIN-MAX, but really, it takes a date range, which is described in more detail a little later in the manual. A date range is fairly complex and flexible. It can be specified either by listing the bracketing dates (literally MIN-MAX), or by specifying one-end of the range, OR by specifying an age relative to the current time. And dates can be given error ranges. The match I used is fairly basic. 3m means greater than 3 months ago, and is specifying an age relative to the current time. 4m would mean greater than 4 months ago. You could also do 3m, which would mean less than 3 months ago, or =3m (exactly 3 months ago). The unit, m in this case, can also be y, w, or d (for years, weeks, or days). But you can see why you'd want an error range. For example: =3m*1w, which would match that two-week range exactly 3 months ago (the * means you're expanding the match in both directions; if you use a - that means only further-into-the-past, and + means the opposite.). Exact dates must be specified in DD[/MM[/[cc]YY]] form. Each bracketed section there means an optional field; any ommitted field is assumed to be the current one. So, for example, ~r 10 would match any email received on the 10th of this month. ~r 10/01 would match any email received on January 10th of this year. ~r 10/01/08 would match any email received on January 10th of 2008, and ~r 10/01/1908 would match any email that appears to have been received back before email existed. So, if I wanted to match all messages received in the entire year of 2008, I could do it a couple different ways. One way would be to specify a date range: ~r 01/01/2008-31/12/2008, or I could use an error-range to accomplish the same thing: ~r 01/01/2008+1y For what it's worth, there's another match-type that also uses this same way of specifying dates: ~d, which matches the Date header (which, unless it's incorrect, usually means the time the message was *sent*, rather than received). With me so far? Now, I said that in the match-type-specifier, the tilde was important, and it is, but now we're getting into *general* simple patterns. *SOME* match-type-specifiers have alternate forms. For example, ~b specifies a match against the message body. It takes a regular expression as an argument (instead of a date range), which mutt then uses to analyze every message. However, if messages aren't available *locally* (e.g. if you're reading your mail via IMAP), that can cause you to download every message so that mutt can search through it trying to match the regular expression. There's an alternate form of that match, that only works on IMAP servers, =b. That version also searches the body of the message, but asks the *server* to do the search (thus saving bandwidth). Since the IMAP protocol doesn't allow you to specify a regular expression, the =b simple pattern only matches an exact string. As another example, ~C is a match-type-specifier that specifies a match against the To: and CC: headers. Like ~b, it takes a regular expression. However, mutt also allows you to define named groups (which is a whole other ball of wax). Thus, there's a variant of ~C that will take a group name instead of a regular expression: %C. For example, I defined a group that contains the addresses of all of my family members. Thus, I can match any message that is addressed To or CC'd to my family members with the following simple pattern: %C family There's a full list of simple pattern types in the manual (I usually use the muttrc man page as a reference for that; search for simple pat to take you to the right spot quickly). So-called simple patterns like this can also be combined. For example, the pattern ~r 2w ~b mutt will match any message received in the last two weeks that contains
Re: Clarification on tag-prefix-cond vs. tag-prefix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday, February 12 at 08:15 PM, quoth John J. Foster: Am I nuts, or are these functionally equivalent? You're nuts. :) But they *are* very similar. Tag-prefix, of course, means that the next command will apply to all of the tagged messages. But what if there AREN'T any tagged messages? Well then, the next command will apply to whatever message happens to be highlighted! This is usually the right thing to do when working interactively with the user, but when used as part of scripts, lots of times there may not be any tagged messages and in that case, the subsequent action should not occur. THAT is what tag-prefix-cond does: if there aren't any tagged messages, the command buffer is flushed without doing anything (in other words, whatever hook you're in stops dead in its tracks). Take for example the folder-hook that I posted earlier today. The idea is that I want mutt to automatically move any messages that are older than 3 months into the archive folder. To refresh your memory, here's what it looks like: folder-hook =Sent 'push tag-pattern~r 3mentertag-prefix-condsave-message=Archive.Sententeruntag-pattern~Aenter' So what happens if there aren't any messages that are older than three months? If I had used tag-prefix instead of tag-prefix-cond, what would happen is that whatever message happened to be highlighted when I entered that folder would get moved to the archive folder. In my case, I have mutt highlight the first new or unread message when it opens new folders, so if I used tag-prefix, that new message would get moved to the archive folder. However, because I use tag-prefix-cond, when there aren't any tagged messages (i.e. the pattern ~r 3m didn't match anything), mutt will stop processing that hook and none of the rest of it will happen. Does that make sense? ~Kyle - -- I'm as pure as the driven slush. -- Tallulah Bankhead -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iEYEARECAAYFAkmU6P0ACgkQBkIOoMqOI14LpgCggHeM04zyhj5Nf28lItyG9xU5 ELEAoJMDmPmv4IxNzGlRExla4t3uZ1fN =qqzw -END PGP SIGNATURE-
Re: Clarification on tag-prefix-cond vs. tag-prefix
On Thu, Feb 12, 2009 at 09:29:01PM -0600, Kyle Wheeler wrote: On Thursday, February 12 at 08:15 PM, quoth John J. Foster: Am I nuts, or are these functionally equivalent? You're nuts. :) But they *are* very similar. Tag-prefix, of course, means that the next command will apply to all of the tagged messages. But what if there AREN'T any tagged messages? Well then, the next command will apply to whatever message happens to be highlighted! This is usually the right thing to do when working interactively with the user, but when used as part of scripts, lots of times there may not be any tagged messages and in that case, the subsequent action should not occur. THAT is what tag-prefix-cond does: if there aren't any tagged messages, the command buffer is flushed without doing anything (in other words, whatever hook you're in stops dead in its tracks). Take for example the folder-hook that I posted earlier today. The idea is that I want mutt to automatically move any messages that are older than 3 months into the archive folder. To refresh your memory, here's what it looks like: folder-hook =Sent 'push tag-pattern~r 3mentertag-prefix-condsave-message=Archive.Sententeruntag-pattern~Aenter' So what happens if there aren't any messages that are older than three months? If I had used tag-prefix instead of tag-prefix-cond, what would happen is that whatever message happened to be highlighted when I entered that folder would get moved to the archive folder. In my case, I have mutt highlight the first new or unread message when it opens new folders, so if I used tag-prefix, that new message would get moved to the archive folder. However, because I use tag-prefix-cond, when there aren't any tagged messages (i.e. the pattern ~r 3m didn't match anything), mutt will stop processing that hook and none of the rest of it will happen. Does that make sense? Yep - and I'm nuts regardless! Thanks for the explanation Kyle. festus -- I just want to break even. Richard Manuel pgpfmxmwtA6TC.pgp Description: PGP signature
