Re: packages with binaries
Uday S Reddy writes:
Stephen J. Turnbull writes:
> I'm not talking about functionality (but since you mention it: for my
> taste, recent VM has added too much functionality, at least as
> default).
That is good to know. We get demands from users for new functionality, but
never complaints about excess functionality. So, if you can give me some
samples of what you would consider excessive in the recent VM, that would be
helpful.
Attachment thumbnails in the MIME buttons and the message history
buffer. The former I guess you can't avoid these days, but there
should be a way to turn them off -- they're slow and buggy (the bugs
may be in the external helper programs used, but PDF files are
frequently misparsed as PNG for some reason, and it blows everything
up). The latter doesn't seem at all useful to me, and having it pop
up by default was a huge mistake.
You can see the syntactic structure as soon as you look at a piece of
code.
Sure, but Lisp, even Common Lisp, is very syntax-poor as a language.
What ends up happening is that developers end up creating their own
syntax with defmacro or define-syntax depending on your preferred
method of suicide-by-spaghetti. So, I'm not interested in syntactic
structure of individual functions (which tends to be pretty simple
anyway); I'm interested in the call graph.
If the call graph is not semantic, what is?
To understand its semantic structure, you need to understand its
behavior
and see what happens when you tweak it.
I don't want to "tweak and see what happens". I want to design, and
see the code do what I designed it to do. Clear structure in the
surrounding code makes that a lot more likely to happen (although
you're right, it's always possible to write code that will fall
apart, and I've done it often enough myself even with the help of an
excellent existing infrastructure to fit my code into).
Having good syntactic structure doesn't mean that the code is
logically coherent. VM, on the other hand, has logical coherence
that continues to stand up when we tweak it.
I have no idea what you mean by "logical coherence" when you refer to
VM's code, except that people who work a lot on VM are able to add new
features without breaking old ones. But looking at the code itself, I
see things like:
$ grep -l vm-th lisp/*.el
lisp/vm-avirtual.el
lisp/vm-delete.el
lisp/vm-digest.el
lisp/vm-edit.el
lisp/vm-folder.el
lisp/vm-macro.el
lisp/vm-mark.el
lisp/vm-message.el
lisp/vm-motion.el
lisp/vm-mouse.el
lisp/vm-page.el
lisp/vm-ps-print.el
lisp/vm-sort.el
lisp/vm-summary.el
lisp/vm-thread.el
lisp/vm-vars.el
lisp/vm-virtual.el
lisp/vm.el
$
Code related to message threading is scattered all over the code base.
That doesn't strike me as logical or coherent. AFAICS, the vm-thread
library should get a list of messages, and use that to generate and
maintain a tree structure that vm-summary can present to the user.
What are the other 16 files doing in that list?
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.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta