* gnus-summary-respool-trace for nnimap?
@ 2001-11-21 10:49 Niklas Morberg
2001-11-21 12:40 ` Kai Großjohann
0 siblings, 1 reply; 7+ messages in thread
From: Niklas Morberg @ 2001-11-21 10:49 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gnus-summary-respool-trace for nnimap?
2001-11-21 10:49 gnus-summary-respool-trace for nnimap? Niklas Morberg
@ 2001-11-21 12:40 ` Kai Großjohann
2001-11-21 13:33 ` Niklas Morberg
0 siblings, 1 reply; 7+ messages in thread
From: Kai Großjohann @ 2001-11-21 12:40 UTC (permalink / raw)
Cc: ding
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)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gnus-summary-respool-trace for nnimap?
2001-11-21 12:40 ` Kai Großjohann
@ 2001-11-21 13:33 ` Niklas Morberg
2001-11-21 15:31 ` Kai Großjohann
0 siblings, 1 reply; 7+ messages in thread
From: Niklas Morberg @ 2001-11-21 13:33 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gnus-summary-respool-trace for nnimap?
2001-11-21 13:33 ` Niklas Morberg
@ 2001-11-21 15:31 ` Kai Großjohann
2001-11-21 15:58 ` Matching split rules against decoded headers? (Was: Re: gnus-summary-respool-trace for nnimap?) Niklas Morberg
2001-11-21 18:43 ` gnus-summary-respool-trace for nnimap? Paul Jarc
0 siblings, 2 replies; 7+ messages in thread
From: Kai Großjohann @ 2001-11-21 15:31 UTC (permalink / raw)
Cc: ding
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)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Matching split rules against decoded headers? (Was: Re: gnus-summary-respool-trace for nnimap?)
2001-11-21 15:31 ` Kai Großjohann
@ 2001-11-21 15:58 ` Niklas Morberg
2001-11-21 16:33 ` Kai Großjohann
2001-11-21 18:43 ` gnus-summary-respool-trace for nnimap? Paul Jarc
1 sibling, 1 reply; 7+ messages in thread
From: Niklas Morberg @ 2001-11-21 15:58 UTC (permalink / raw)
Cc: ding
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gnus-summary-respool-trace for nnimap?
2001-11-21 15:31 ` Kai Großjohann
2001-11-21 15:58 ` Matching split rules against decoded headers? (Was: Re: gnus-summary-respool-trace for nnimap?) Niklas Morberg
@ 2001-11-21 18:43 ` Paul Jarc
1 sibling, 0 replies; 7+ messages in thread
From: Paul Jarc @ 2001-11-21 18:43 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2001-11-21 18:43 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-11-21 10:49 gnus-summary-respool-trace for nnimap? Niklas Morberg
2001-11-21 12:40 ` Kai Großjohann
2001-11-21 13:33 ` Niklas Morberg
2001-11-21 15:31 ` Kai Großjohann
2001-11-21 15:58 ` Matching split rules against decoded headers? (Was: Re: gnus-summary-respool-trace for nnimap?) Niklas Morberg
2001-11-21 16:33 ` Kai Großjohann
2001-11-21 18:43 ` gnus-summary-respool-trace for nnimap? Paul Jarc
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).