vm team mailing list archive

["Tim Cross" <tcross@xxxxxxxxxxxxxxx>]

Uday S Reddy writes:
 > I understood your project to mean improving the user interface by
 > grouping custom options into manageable chunks.  Please don't attempt
 > code rerorganization, which involves all kinds of subtleties and can
 > potentially break things.
 >

Don't misunderstand, I'm not talking about wholesale re-organisation. However,
I do think the code should be getting better as we maintain it. It needs to be
left in a better state than we find it. The things I'm looking at are quite
straight-forward, even trivial. Note also that we are talking only about a very
small number of these defcustom definitions. My approach is to keep changes to
a minimum. I've noticed many 'issues' which I've left completely alone. Even
within the custom interface stuff, there are some things that should be
changed, but which I've left alone at this time because the impact of changing
could potentially introduce problems. My general rule of thumb has been to
only change things that make cusotm work correctly or that will make the
ability to customize work as it was meant to. 

Currently, there are problems with duplicate definitions of some variables and
custom groups. There are custom definitions that are later completely ignored
because of (setq blah) lines in a different file and even in the core vm
stuff, such as vm-toolbar.el, some of the defcustom definitions are in
vm-vars.el and some are in vm-toolbar.el. There are even custom definitions
where the form of the defcustom and the default value it is set to are not
consistent and we have things like some faces that are defined as 'real' face
and defface values and other faces that are defined as defcusotm variables
holding face names etc. While things like tag files can help, they don't if
you have multiple definitions of the same thing. We even have the same
variable defined twice in the same file (vm-vars.el).

The fact we have these inconsistencies is likely a significant cause of
maintenance problems and subtle bugs. 

Having said all of that, I would also point out that I have not moved any of
the definitions or re-organised anything. I have attempted to get direction on
which way to go. If you don't want this changed, fine, I won't change it.
However, I will argue about it if I disagree. Given we are simply
talking about defcustom/defface/defgroup forms, I think your being too
conservative. We are not talking about modifications to chunks of elisp, only
in (possibly) moving the location of some definitions so that, should we need
to change things in the future or track down problems, others can find the
task a little easier. Any problems with compilation, etc will show up during
testing and are unlikely to be a cause of subtle errors or bugs. Your point
regarding core and none-core VM stuff is a valid one and partially why I asked
for direction. I personally would work towards no non-core definitions being
in vm-vars.el. While they have been put in there at different times to get
around issues in building etc, I would prefer that we actually fix such issues
rather than paper over them. To some extent, this core/non-core distinction is
poorly defined. For example, I cannot run a VM that only consists of 'core'
stuff - at the very least, it will result in additional variables being
defined that are not required for the core system. 

I also think doing this in a dev branch is the
place to do it and would not be suggesting making such changes to a released
version. 

At some point, if we really want to maintain both a stable and extensible MUA
we are going to have to address these matters. Some of the contributed stuff
has significant problems, some of it is actually better than what is in VN
core. At some point we have to work out what to do about this kludge of
features and extensions and work out how to integrate into VM proper. We
should not be afraid to re-factor and improve things. We do need to ensure
quality and stability, but we can do this through care, peer review and good
testing. If we continue to keep tacking on bits and new features we will just
end up with a Frankenstein! The fact we distribute these non-core bits with
the main distribution I think also undermines our position somewhat. End users
are not going to make the distinction. They download the tar ball or install
the distro packaged version and expect it to work because we have contributed
it with the release. 

> Yeah, I know that Rob F wasn't up to date with documentation.  (He
> might have also found it harder to do, being a non-native English
> speaker.)  But, we are back to proper documentation now.  If there are
> any options or features missing in the VM core (not add-ons), then we
> should regard them as bugs in the documentation and fix them.

Actually, this stems back to Kyle's work. He didn't really maintain the
manuals that well (he maintained the web site version a bit more than the
bundled info version). He would frequently refer people to the vm-vars.el file
when they wanted to customize vm.

Tim


-- 
Tim Cross
tcross@xxxxxxxxxxxxxxx

There are two types of people in IT - those who do not manage what they 
understand and those who do not understand what they manage.