vm team mailing list archive

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

Tim Cross writes:

> I agree. The problem is that all the global definitions are not in
> that file!  This was my main point. I don't mind which approach we
> take, but I do think it should be consistent. Currently, we have
> some files that use custom that have their defcustom and defgroup
> definitions in other files apart from vm-vars.el.  In some cases,
> they duplicate the defgroup definitions and cause some confusion by
> overriding definitions in vm-vars.el. In at least one case, we have
> some of the defcustom for the same file in vm-vars.el and some in
> the 'features' main source file, for example vm-toolbar.el
> 
> What I would like to do is make things consistent. From what you
> indicate, this would be to put all the definitions in vm-vars.el,
> which was the default
> way I was going to go if nobody had any other preference.

I don't see consistency as being that important.  For my own work, I
just build a TAGS file and do M-x find-tag to go to the definition.
It doesn't matter which file it is in.  On the other hand, there are
good reasons why *all* the definitions should *not* be in vm-vars.el. 

1. The lisp directory contains core VM as well as various add-on's for
VM.  They should be kept separate as far as possible.  I have added a
note at the top of each lisp file indicating which is which.  The
author name also indicates that.  Kyle Jones is the original author
for all of core VM.  The definitions in the add-ons should stay there.
There is no need for them to corrupt core VM.

2. If some definition is local, i.e., used only in a particular .el
file, there is no reason for it to go into vm-vars.el.  Only *global*
definitions, in the sense that they are used all over VM, need to go
into vm-vars.el.

3. There are various practical compromises that have been made over
the years in order to get compilation to work correctly or for the
defaults to get loaded at the right time.

So, there are lots of subtleties here, which I don't understand enough
myself.  We shouldn't attempt wholesale reorganization of code until
we get enough exprience with all its aspects.

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.

As I have said many times, what we value about VM is that it is
reliable.  It is not beautiful code, and it will probably never be. 

> In principal I agree. However, in the past, the VM distribtuion has
> included a copy of the vm-vars.el file in its documentation (usually
> in /var/share/doc/vm on debian and red hat based systems) and the
> README use to tell people to look at that file to work out how to
> configure things. While you have updated the manual, I was thinkinig
> about other longer term users who may have gotten use to using
> vm-vars.el rather than the manual.

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.

Cheers,
Uday