Re: Deleting Mails and Syncing Folders to Disk

[David Pickens <dpickens iaesthetic com>]

On Fri, 28 Jan 2000, I.J. Campbell wrote:

> 
> Hi David, and thanks for your reply..
> 
> Firstly, I am using the latest CVS version of balsa...
> 
> Secondly I have cc'd this back to balsa-list, I hope you don't mind.

I don't mind at all -- generally I reply to the list, but I didn't in this
case only because I haven't been working with balsa and wanted to take a
look at the code before going into detail about it.  

> If I right click on a mailbox in the mailbox list then there is an option
> 'Edit Mailbox Properties' which brings up a dialog (code in
> mailbox-conf.[ch]) containing some (not many though) properites for the
> mailbox, I have added a check box 'Delete to Trash' to this and a field in
> the Mailbox structure.

I completely forgot about this dialog -- I guess I've just never had
reason to use it.  Although, this does raise an interesting UI issue --
most users will /not/ want to specify this on a per mailbox basis but they
might want to change the default behavior, so we should probably add
a 'move deleted messages to the Trash mailbox' option, and we'll have to
be careful to specify that this mailbox option overrides the default
behavior.  (I guess the preferences code should reset all mailboxes to
the default when the default option is changed.)


> 
> The only problem I am having is modifying the balsa_message_delete
> function to obey this new setting, you say it is posible, can you tell me
> how, or give me a pointer.
>

balsa-index-page.c around line 912.

Ideally, this option in the mailbox properties should be related to a
balsa_app member, and they should be saved and loaded in save-restore.

So, assuming that this has been done, do a:

if(!balsa_app.this_mailbox_uses_trash)
  to_trash = FALSE;

At the moment, it defaults to always moving to trash unless the current
mailbox IS trash, and this will have to be changed as well (lines 908-911)

 
> > I wrote the code for 'Trash' support -- but, the tendancy is to move balsa
> > away from a pine-like (ie text-based) model where things are flagged as
> > deleted and then later committed.  What would you think about simply
> > deleting the messages?
> > 
> 
> I wouldn't be too bothered if messages were just deleted (that is the
> behavior I have got so far), but I would rather have the option to delete
> it, flag it or move it to an arbitrary trash folder.
> 
> For example - I would like to keep my local inbox trash in the local trash
> folder, and I would rather that trash from mailing lists (which are in
> separate folders) was flagged in the mailing list folder, so it doesn't
> get mixed with my 'personal trash'. I also have an imap inbox which I
> would like to use the flagging behavior with.

Maybe we should get this working with the 'standard' delete vs. trash and
worry about flagging later.  I guess this would be an interesting debate
to have, but my attidute is that flagging was pretty useful for text-based
browsers over slow lines, but that with a gui agent it's pretty easy to
select multiple messages with a click and if you're worried about
un-deleting then you /should/ use trash. :)  The arguments about large
mailboxes and the efficiency of deleting don't necessarily wash either,
given that batched deletes are only synced together, and given the info.
below...

> > Are you using the CVS code?  There shouldn't, at this point, be a commit
> > current option given the changes I committed to the user interface (the
> > elimination of the notebook tabs, etc.).  Syncing folders is complicated
> > in that it's handled by mutt, and mutt has its own way of doing things.
> > It /is/ synced when changed, but it's not necessarly immediately written
> > to disk -- this should always happen correctly, though, when mailboxes are
> > opened and closed.  (And /this/ now happens in the background,
> > automatically, based on the time of the folders last use.  It's
> > automatically closed when it times out.)
> 
> I like the new tabless look etc, but there is still a 'Mailboxes -> Commit
> Current' menu item, which seems to be hooked to 'mailbox_commit_changes'
> which in turn calls 'mailbox_commit_flagged_changes'. Perhaps this could
> (should?) be changed to also sync the mailbox with the disk version?
> Perhaps also the mailbox could be sync'd (in the background) when it
> becomes non-foreground in the GUI?
>

Arg.  I really should have run balsa before sending the message.  Either I
missed commit current or left it there as a safety measure until I was
sure the new look worked -- in any case, I think this should go.

Here's the strange thing about mutt and syncing messages (you mentioned
trying mx_sync_mailbox) -- it doesn't appear to sync to the disk, but
rather, counter-intuitively, to 'sync' it's internal representation of the
mailbox by eliminating messages that are flagged for deletion etc.  We had
a problem where some messages weren't being deleted and in the process of
troubleshooting this I noticed that if you have 12 messages in a mailbox,
flag all 12 for deletion and call mx_sync_mailbox mutt responds as IF it
committed the changes, but the file remains its intial size on the hard
drive.  If you close and open the mailbox it is /actually/ written.  I
never had the patience to go through the mutt code to figure this out, and
you might have better luck than I did, but there is a convenience function
(really a complete hack) the forces a sync to the hard-drive by closing
the mailbox, removing the notebook tab, and re-creating the notebook tab:
balsa_index_page_reset(BalsaIndexPage *page).  If you have the mailbox and
need the page there's a function to find this for you, too.  (It does work
and it's pretty transparent to the user, but you can see this isn't the
best of all possible solutions.)
 
> I have also noticed that balsa doesn't always (more like never I think)
> notice new messages (delivered using fetchmail/procmail), unless I
> explicitly close the mailbox from the context menu and then re-open it,
> which is a pain. It would be nice if the 'check new mail' button would see
> if the foreground mailbox's disk file had been updated... I will try and
> look into that at some point.
> 
> Thanks, 
> Ian.

This would /great/!

David