Re: Today's articles/mails..

[Tassilo Horn]

bgmrao@gmail.com writes:

Hi Madhu,

> Sorry, I meant summary buffer. (getting back to using gnus after a
> long while).
>
>     > ,----[ (info "(gnus)Limiting") ]
>     > | `/ t'
>     > |      Ask for a number and then limit the summary buffer to articles
>     > |      older than (or equal to) that number of days
>     > |      (`gnus-summary-limit-to-age').  If given a prefix, limit to
>     > |      articles younger than that number of days.
>     > `----
>
>     > So in your case, `C-u 7 / t' would limit the current summary to messages
>     > from the last week.
>
> Thanks for all the info (I feel stupid having asked, I had used many
> of this a few years ago and should have re-read the manual before
> posting).

You're welcome.  No need to feel ashamed.

> However, if I have to see _all_ of this weeks articles
> (read/ticked/dormant), I have to bring them up in the summary and then
> limit to this week.

Yes, right.  Limiting works only on articles already shown.

To get enter a group showning only the "right" articles, there's no
general way, I guess.  At least for IMAP groups, you might be able to
use a search on a group (`G G') instead of entering it (at some point in
the future, cause date searches seem to be not implemented right now).

,----[ C-h f nnir-imap-make-query RET ]
| nnir-imap-make-query is a compiled Lisp function in `nnir.el'.
| 
| (nnir-imap-make-query CRITERIA QSTRING)
| 
| Parse the query string and criteria into an appropriate IMAP search
| expression, returning the string query to make.
| 
| This implements a little language designed to return the expected results
| to an arbitrary query string to the end user.
| 
| The search is always case-insensitive, as defined by RFC2060, and supports
| the following features (inspired by the Google search input language):
| 
| Automatic "and" queries
|     If you specify multiple words then they will be treated as an "and"
|     expression intended to match all components.
| 
| Phrase searches
|     If you wrap your query in double-quotes then it will be treated as a
|     literal string.
| 
| Negative terms
|     If you precede a term with "-" then it will negate that.
| 
| "OR" queries
|     If you include an upper-case "OR" in your search it will cause the
|     term before it and the term after it to be treated as alternatives.
| 
| In future the following will be added to the language:
|  * support for date matches
|  * support for location of text matching within the query
|  * from/to/etc headers
|  * additional search terms
|  * flag based searching
|  * anything else that the RFC supports, basically.
`----

Bye,
Tassilo