Re: packages with binaries
Uday S Reddy writes:
as either being "part of VM" or "add-on for VM".
The message-history stuff
is an add-on, and you have to explicitly plug it in by adding invocations in
your .emacs or .vm file, which I suppose you did!
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. :-(
A piece of software is good semantically if it is doing the right
sequence
of operations in the right order.
Sure, but if you can't get a pretty good reading on that from
reviewing the program source, "open source" is meaningless.
But if the software had bad semantics to start with, I believe that
no amount of refactoring will fix it.
By definition, refactoring (and in general good structure) cannot fix
bugs. However, it can expose bugs to review *before* they manifest in
use, or make diagnosis and repair far easier. Malaria nets are far
more effective than slapping mosquitos when they bite you!
If you will indulge me, I can suggest some visual imagery. Think of
all
(the instances of) primitive operations as grains of sand. The code is the
mason that assembles these grains into a nice castle that the user will
enjoy using and the maintainers will enjoy tweaking. The beauty of the
castle is an entirely separate issue from the beauty of the mason. If the
mason is good-looking, I wouldn't complain, but if the mason is unkempt, it
wouldn't bother me much either.
I'll call your metaphor and raise you 10. Look up "Urayasu Japan
liquefaction" and see some "beautiful" pictures of what happens when
you let the grains of sand take care of themselves. Here's a cute one
of the sewers:
http://www.npr.org/2011/04/07/135181474/in-japan-shaken-soil-turned-soft-...
I am not saying you should tweak it to see what happens. But the
acid test
of your design is whether it can be tweaked in the future without making it
fall apart.
Sure, but good structure and clear style can help you assess whether
that is likely or not.
"Seeing the code do what you designed it to do" is a
short-term
goal, but that is not good enough, is it? Long-lived software
needs to be maintainable.
Hey, that's *my* line! :-)
> I can't imagine that this is the only example of excessive
coupling in
> the codebase, although I admit threading is what I've been working on
> most.
Oh, that is good to know. The threading code had lots of subtle bugs, which
took me ages to fix. In fact, I now regard the threads database as a
challenge problem for programming theorists like me.
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.
I hope you now have at least a reasonably correct code base to work
with.
Yes, I do. It's called jwz-thread.el, after the algorithm's original
author:-), and it implements RFC-5256-standard threading. It's less
than half the size of vm-thread.el, and about two-thirds of that is
documentation. It's noticably faster than vm-thread.el in building
the database. Best of all, it only took about 4 hours to code, and
another two to find and fix a few stupid mistakes, since Jamie did all
the hard work.
Making this actually work in VM is another question; I've spent about
20 hours on that, and I'm not close yet. Too much coupling....
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta