Re: packages with binaries
Stephen J. Turnbull writes:
I did have a customization of vm-message-history-max to 1 (custom
wouldn't accept nil or 0, and now it doesn't recognize that
variable!), but that was *after* the stupid thing started popping up
and covering the whole screen. I've removed that, we'll see if it
goes away now. (Anyway, a size configuration should not enable a
major feature like that!)
> The thumbnails are a part of core VM, but I have added a way
to
> disable them. (Set `vm-mime-thumbnail-max-geometry' to nil.)
That's hardly discoverable. :-(
Agreed. Please feel free to report such issues on viewmail-bugs or
viewmail-info mailing lists!
Sure, but if you can't get a pretty good reading on that from
reviewing the program source, "open source" is meaningless.
I think VM was designed to be just free software. "Open source" is a newer
concept. I would agree that VM doesn't meet the standards of open source.
Perhaps, one day it will, if we keep rewriting things. That is a good goal!
By the way, one reason this seems so hard is because VM treats
threading as a kind of sorting, and you're tweaking that. But thread
structure is non-linear: it's a tree structure, and the usual order in
summaries is generated by traversing the tree in pre-order. Lisp is
quite fast at doing that kind of thing -- it's not at all clear to me
that functions like deleting or editing a message need to know
anything about threading (just regenerate the summary from scratch,
which you're most likely going to do anyway), and there is a well-
known algorithm (RFC 5256) for generating the tree which is robust to
occasionally-bogus data.
The trunk version of VM you are using does not treat threading as a form of
sorting any more.
I didn't know about RFC 5256, but I ran into Jamie Zawinski's web page on
the threading algorithm and used its ideas. But, VM's algorithm was pretty
similar to it already. VM predates Netscape, does it not? And, Jamie was a
VM user. I don't know if he still is.
The current status of threading in VM is that it is treated as a form of
grouping, and all VM operations (deleting, saving, printing and what have
you) can operate on threads. `vm-enable-thread-operations' enables it. So,
the threads database is maintained at all times, and it is updated
consistently during additions and deletions. There is also a host of
"cached" information (the visible lineage of each message, the subtree
rooted at each message etc.) which needs to be updated consistently.
All kinds of problems cropped up in the corner cases (dealing with duplicate
copies of messages, or subject line changing in the middle of a thread etc.)
and each of them took me ages to fix. I came to the point of throwing away
the old code and rewriting it from scratch several times. But I was hopeful
that the problems were minor and I was converging on the right code. I
think I did. But, still, I hope to rewrite it from scratch some day and
think about why it proved to be so hard.
Cheers,
Uday
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta