vm team mailing list archive

[Uday S Reddy <u.s.reddy@xxxxxxxxxxxxx>]

Tim Cross writes:

> 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. 

If it is only a small number of defcustom definitions, then I am not
sure why we need such a big discussion about it.  In fact, I just went
to see how many core VM defcustom's are outside vm-vars.el, and found
only two.  So, just go ahead and move them.  It is not a big deal.

> My approach is to keep changes to a minimum. 

Good. That is what I am recommending as well. 

> 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.

vm-toolbar.el has only one defcustom definition and it is not
duplicated in vm-vars.el.  So, I am not sure what you are after.  Can
you please be more specific when you make proposals, so that we can
move faster in discussions?

> 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).

If there are problems like multiple definitions for the same thing, we
should definitely fix them.  But, please tell us what these problems
are, specifically.

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

The consistency that I would like is that if I go to look up the
variables or custom's of a particular kind, say vm-pop, then I would
prefer to find all of them in one place.  Whether they are in
vm-vars.el or vm-pop.el doesn't concern me too much.  

> 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. 

Yes, anything you can do to separate the core VM from the add-ons
would be very welcome.

> 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. 

All that sounds very good.  The real limitation we have is that we are
only a few people who have other real jobs and we can only devote so
much time for this.  

I think Rob F was wanting to integrate all the add-on's into the VM
core, but he didn't actually manage to do very much about it.  So, we
are left with a hodge-podge of stuff in the VM distribution.  I have
integrated a few features from vm-rfaddons, but found it to be too
much work.  So, I am only going to do such integration for the
features that I think are really important.

> 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.

Sorry, I don't agree.  The VM core is solid, and all the new features
that I am adding or I am overseeing are integrated properly.  No
Frankenstein here.  

The VM core is what is described in the VM manual and the end users
will need to learn the distinction between it and the add-ons, if they
haven't figured it out already.  

Cheers,
Uday