rwithers12 at attbi.com wrote:


> I'll have to see it.   I am only just getting use to the idea of filters
> as the core mechanism to read my mail.  I think I like it, but still
> miss the other idiom.

The old idiom is still there, even though it's not right in your face. 
If you put a category filter in the list, you can change folders my
"modify"-ing the category filter.  Also, you can browse a different
folder in a new window by doing "new filter list" and repeating the
process there.  It's slightly slower, but not by much.


> 
> > Yes, having read and unread categories that are automatically maintained
> > would be a nice addition.  It doesn't have to be a separate mechanism.
> 
> So I guess you really want them to be categories. :)   I suppose it
> would be difficult to add data to the existing message headers in
> Celeste DBs the world over.

That's an issue, though that's not the biggest reason.  The main thing
is that categories handle it very simply, so why have a separate
mechanism?  It would be like having syntax for if statements, when you
have blocks.


Making extensible index files is definitely on the list.  And
incorporating the full-text searcher, as Bijan has begun to mess with,
would also be very nice.  But these are major time takers, and this is a
spare-time kind of project competing with other spare-time projects.


> 
> > Maybe I wasn't clear on the suggestion.  You can save message rules
> > underneath names -- that's what a named filter is.  There's simply no
> > mechanism in there for moving those messages anywhere.
> 
> Ok, and I just found we can do this in the normal Celeste with custom
> filters.  cool.

Oh, right, sure.



> 
> > 	3. You may want to be more selective in what you move; e.g., you may
> > want to move only those messages which you have read, or which have a
> > certain keyword in the subject.
> > 
> > 	4. Why move them anyway?  I read my mailing lists straight from the
> > "new" category, and it works great.
> 
> Mmm,  Perhaps it works.  It takes being a very diligent email manager,
> but I have that same issue in Outlook.  After going away for 5 days, the
> old email can really stack up.  I'll keep going the way it is, and check
> my feeling in a week or so.

I have, uh, 405 messages in my in-box at the moment.  This is fairly
low; a few days ago I approached 1000.  If you have an "important"
filter that is accurate, then this isn't a big deal.  "new" is my
"unread" category.


> > Hmm, if your image crashes while you are writing a message, it would get
> > lost.  Also, if you restart an old image under Squeak3.2gamma, I don't
> > know if the on-disk files will be reread.
> 
> No, they aren't, so there is one good fix to bring forward.

Ugfh.  Well just to mention a point of philosophy, I think Filtering
Celeste is stepping forword aver the in-image Celeste in every way, so
I'm not going to spend time maintaining the in-image version.  I'm not
finding time to implement even the features I want, much less backport
them. The key issue for getting Filtering Celeste in the main image is
the LargeList changeset, which touches some core classes.  Maybe in 3.3
we could go for it....

Alternatively, quite a lot of the changes should backport pretty easily,
should someone care enough to try.




> > By the way, a more drastic measure is to run "compact and salvage".  
> 
> I did this.  It worked!   I found my lost mail or it found me,

Great to hear!  Though it sucks that the UI didn't bring out this
feature....  

Once upon a time, John Maloney made a tutorial for Celeste that was in
the form of a Celeste database.  You open the database, and the messages
in the database would step you forward.

OR!!  Make it a Squeak project and post it on a super-swiki somewhere. 
That would probably be the best thing.  There would still be a sample
database involved, but the project could download that database
automatically.


-Lex