Re: Balsa's thread handling very buggy.

[Peter Bloomfield <PeterBloomfield bellsouth net>]

On 07/18/2003, Miquel van Smoorenburg wrote:
[ snip ]
> Yes, but I mean if I have
> 
> m1
> m2
> m3
> a
>  b
>   c
>  d
>   e
> m4
> m5
> 
> and I delete a I get
> 
> m1
> m2
> b
>  c
> m3
> m4
> d
>  e
> m5
> 
> and I'd prefer
> 
> m1
> m2
> m3
> b
>  c
> d
>  e
> m4
> m5
> 
> or even
> 
> b
>  c
>  d
>   e
> 
> It's kind of hard to explain what makes the most sense - IMHO, how  
> mutt does it is the most 'natural' way. If you have mutt installed  
> perhaps you should try it to see what I mean, with the following in . 
> muttrc
> 
> set sort=threads
> set sort_aux=last-date-received
> 
> Mike.

Thanks for the patient explanation! Yes, I *do* have mutt installed,
but I've never invested the time to set it up in parallel w/Balsa!

The issue is that Balsa lets the GtkTreeView do the sorting, and just
provides pairwise comparison functions for the different sort criteria.
To sort children of a missing parent together, some kind of thread
identification would have to be added to the message structure at the
time of threading.

Incidentally, when mutt (or whatever) has decided that b and d should  
be adjacent, how does it decide to place them both where a was located,  
between m3 and m4, when b sorted naturally between m2 and m3, and d  
sorted naturally between m4 and m5? I would have thought that the  
location of either b or d in the natural sort (and arguably b) would be  
the logical place. The existence of a can be inferred from the message  
references, but not, I believe, its sorted location.

One way to implement such sorting would be to add to the message  
structure a pointer to a list of siblings, used only when the parent is  
missing. Messages that share such a list would be sorted naturally, but  
other comparisons would be based on a distinguished (the lowest- 
sorting?) member of the list.

Peter