gnus-summary-respool-trace for nnimap?

gnus-summary-respool-trace for nnimap?

[Niklas Morberg]

I'm having some very weird problems with my
nnimap-split-fancy rules which I need to locate (when
checking a from address not containing any numbers against
the regex ".*[0-9]\\{2,\\}.*" it will incorrectly match,
probably because the from address contains the character
`ö', but I don't know).

I don't know how to easily find the problem. With
nnmail-split-fancy rules you can check where messages end up
with `B t' or `B q' (right?), but this does not work with
nnimap.

Any ideas on what to use instead?

Niklas

Re: gnus-summary-respool-trace for nnimap?

[Kai Großjohann]

Niklas Morberg <niklas.morberg@axis.com> writes:

> I'm having some very weird problems with my
> nnimap-split-fancy rules which I need to locate (when
> checking a from address not containing any numbers against
> the regex ".*[0-9]\\{2,\\}.*" it will incorrectly match,
> probably because the from address contains the character
> `ö', but I don't know).

If you do C-u g on the message, what do you see?  Maybe the ö is QP
encoded, as "=F6", which contains a digit...

But OTOH, that doesn't contain two or more digits.  Hm.  But maybe
the QP encoding has a leader like "=?iso-8859-1", which does contain
digits.

FWIW, I think you can replace ".*[0-9]\\{2,\\}.*" with
".*[0-9][0-9].*".

And the two ".*" are only needed because fancy splitting adds
invisible "\\<" and "\\>" around your regexp.

kai
-- 
Simplification good!  Oversimplification bad!  (Larry Wall)

Re: gnus-summary-respool-trace for nnimap?

[Niklas Morberg]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> If you do C-u g on the message, what do you see?  Maybe the ö is QP
> encoded, as "=F6", which contains a digit...
>
> But OTOH, that doesn't contain two or more digits.  Hm.  But maybe
> the QP encoding has a leader like "=?iso-8859-1", which does contain
> digits.

The from address does indeed start with "=?iso-8859-1?Q?", so
this would explain the unexpected behaviour. (And yes, the
`ö' is encoded as "=F6" as well.)

I'm guessing this means that I can't write a regex that
catches QP encoded characters? Using your message as an
example: doing C-u g tells me that your name is encoded as

"Kai =?iso-8859-1?q?Gro=DFjohann?="

which would mean that the regex "Groß.*" would not match
your name... Is there any way to let the regexes match
against what I see in the message buffer instead of the raw
contents?

(I could of course match against "=\?iso-8859-1\?q\?Gro=DF.*"
instead, but that seems a bit weird...)

> FWIW, I think you can replace ".*[0-9]\\{2,\\}.*" with
> ".*[0-9][0-9].*".

Would this increase the efficiency in any way, or is it
better for clarity?

Niklas

Re: gnus-summary-respool-trace for nnimap?

[Kai Großjohann]

Niklas Morberg <niklas.morberg@axis.com> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>
> which would mean that the regex "Groß.*" would not match
> your name... Is there any way to let the regexes match
> against what I see in the message buffer instead of the raw
> contents?
>
> (I could of course match against "=\?iso-8859-1\?q\?Gro=DF.*"
> instead, but that seems a bit weird...)

Decoding could take a lot of time, so the current strategy is to do
the matching on the raw message.

One must avoid to decode the body -- or do you want Emacs to play a
sound while splitting, just because the incoming message happens to
contain a sound?  As a less extreme example, rendering text/html is
computationally expensive.

>> FWIW, I think you can replace ".*[0-9]\\{2,\\}.*" with
>> ".*[0-9][0-9].*".
>
> Would this increase the efficiency in any way, or is it
> better for clarity?

My main motivation was clarity.  I don't think there is a significant
change in efficiency in this case.

kai
-- 
Simplification good!  Oversimplification bad!  (Larry Wall)

Matching split rules against decoded headers? (Was: Re: gnus-summary-respool-trace for nnimap?)

[Niklas Morberg]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Decoding could take a lot of time, so the current strategy
> is to do the matching on the raw message.

Would it be a viable option to have split rules do the
matching on decoded headers (still avoiding to decode the
message body)?

Niklas

Re: Matching split rules against decoded headers? (Was: Re: gnus-summary-respool-trace for nnimap?)

[Kai Großjohann]

Niklas Morberg <niklas.morberg@axis.com> writes:

> Would it be a viable option to have split rules do the
> matching on decoded headers (still avoiding to decode the
> message body)?

Maybe.  But don't count on it happening :-)

kai
-- 
Simplification good!  Oversimplification bad!  (Larry Wall)

Re: gnus-summary-respool-trace for nnimap?

[Paul Jarc]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote:
> Niklas Morberg <niklas.morberg@axis.com> writes:
>> Is there any way to let the regexes match against what I see in the
>> message buffer instead of the raw contents?
>
> Decoding could take a lot of time, so the current strategy is to do
> the matching on the raw message.
>
> One must avoid to decode the body -- or do you want Emacs to play a
> sound while splitting, just because the incoming message happens to
> contain a sound?  As a less extreme example, rendering text/html is
> computationally expensive.

Decoding is not displaying.  Or at least, it shouldn't be, I think.
Of course, we do still want to avoid decoding the body, just because
we're not interested in the body at this point, so it would be wasted
effort.


paul