On Saturday 9 September 2000 A . Curtis Martin wrote:
> You mentioned that it fails to work. I'm clearing this up by indicating
> that it *does* work once you know what it really does. How it is
> implemented to work is a different matter.
Ah well, as we both seem to agree, even when you know what it really
does, it doesn't actually work! ;-)
> I personally have no problem
> with how it works at present, since the formal search applet is pretty
> much there for you to use as well and it supports full header and
> whatever searching that you like. It will display the results in a
> message list fashion etc.
The problem here is that I might actually want a drill down in the
current view, not an external search. (Picky, picky, I know.) The full
search is also noticeably slower (even on a single folder) - there is
a significant difference between searching the whole message base, and
searching an index of it. This is of course why indexes are
implemented. But I think the full addressing information ought to be
indexed, rather than just the display-name. I think that's a fairly
minimal extra amount of information to index (I can't say for sure,
but I suspect it actually *is* indexed already, just not checked in
the filter), nowhere near equivalent to allowing arbitrary searches
(equivalent to the full search window) in the filter.
> It is in fact consistent behaviour if you ask me. Among the *message
> list* display options is an advanced display filtering option which
> intuitively implies that it's filtering strings in the message list
> display. I personally didn't expect it to work otherwise. I guess the
> developers and I are on the same wavelength. <shrug>
I should point out that I too am a developer, and do understand the
issues involved. However I don't believe the current behaviour of this
feature is as intuitive as you seem to think.
Think about what you're actually trying to achieve by Alt-Clicking on
one of the address columns. Not what you expect, within your
experience, a computer program to do, but what you really want it to
do. (Within my experience it could do anything right up to making
dragons fly out of your nose. Do you think that's too cynical?)
What I want is to drill down to all messages from that one person. I
don't care how they've chosen their display-name today, many people
seem to change theirs on a daily basis. If your TB archives go back
far enough, look at some of Max's posts - he changed his display name
from "Max Masyutin" to "Maxim Masiutin" sometime around March. It's
more accurate in this case to determine equivalence by the email
address rather than display name. So the current rule is:
* Messages are equivalent if the senders' display-names are the
same.
I'd like to extend that to:
* Messages are *also* equivalent if the display-names differ, but
the email addresses are the same.
That really would be too hard to implement, and I think would have
minimal impact on performance, but a great improvement in usability.
Of course, some people have several email addresses which they use
from time to time. So I'd also like to see:
* Messages are *also* equivalent if the display-names and/or email
addresses differ, but the selected person is in my address book,
and the two email addresses are both listed as alternative
addresses for that person.
Again, that should be much faster than a full trawl through the
message base (which is slowed down mainly by the sheer volume of data
to get through - my message base is currently at 230Mb) but a little
less easy to implement. I'd be temporarily satisfied if the second
point was implemented. If you think that's demanding, then I can
still raise the bar: the address book matching should include
wildcards/regexps, for those with virtual mailbox support.
<*@kanargh.force9.co.uk> are (mostly) equivalent, and one host I know
allows its users to use <[EMAIL PROTECTED]> so they can filter
based on "keywords".
(Of course, you'd want to be able to turn these off, for those rare
times when you really want to search on *this* string and nothing but
*this* string.)
There is a similar philosophy already behind the Subject column - TB
tries to strip out Re:, Re[n]:, Fwd:, because it knows that if the
subject texts are the same apart from these bits, two messages do have
the same subject.
JS>> And this also fails to address the fact that a single message
JS>> remains visible, that in no way at all satisfies the filter
JS>> criteria!
> Well, I did say that I considered that to be a bug. :-) See:
ACM>> If there is no match when the filtering is done, only the last
ACM>> message in the list is displayed. This is a bug, IMHO, because it
ACM>> confuses the user into thinking that it's a match.
Sorry, missed that the first time round. Guess I was too quick to the
trigger.
John
--
you gave me something that i could touch in a world where i'd had too much
something i could feel with my broken hands full of lost ideals but soon i'm
returning to you my friend and we'll go where the rivers end in the silver sea
and i'll carry you if you carry me
--
--------------------------------------------------------------
View the TBBETA archive at http://tbbeta.thebat.dutaint.com
To send a message to the list moderation team double-click HERE:
<mailto:[EMAIL PROTECTED]>
To Unsubscribe from TBBETA, double-click HERE:
<mailto:[EMAIL PROTECTED]>
--------------------------------------------------------------
You are subscribed as : [email protected]
