vm team mailing list archive

[Tim Cross <tcross@xxxxxxxxxxxxxxx>]

From: Uday Reddy <u.s.reddy@xxxxxxxxxxxxx>
Subject: Re: VM custom definitions
Date: Sat, 19 Jun 2010 13:53:38 +0100

> Hi Tim,
> 
> My principle is that we shouldn't do refactoring or reengineering of this kind
> unless there is a clear benefit to be gained. VM hasn't been designed using
> software engineering principles and it won't be easy to redo it to follow
> them.
>

I agree. However, maybe I wasn't clear enough, especially given your comments
below! 
 
> Further more, there is a good reason why all the global variable declarations
> are kept in one file. It is so that we can "require" it in the compilation of
> all the other files. Splitting it up will make it harder to organize the
> compilation.
>

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. 
 
> Finally, VM users aren't expected to read the source code to figure out how to
> use the system. They follow the user's manual. So, the structure of the files
> isn't relevant to them at all.

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.

regards,

Tim



> 
> On 6/19/2010 8:28 AM, Tim X wrote:
>>
>> I am currently working on cleaning up VM's use of defcustom. One of the
>> things I've noticed is some inconsistency in where defcustom definitions
>> are put and wanted to know what people thought would be the best
>> approach.
>>
>> Currently, most of the user customizable variable definitions are in the
>> vm-vars.el file. However, in some cases, they are in the file that uses
>> them and in a couple of cases, some are in vm-vars.el and some are in
>> the file that mainly uses them.
>>
>> I have no particular preference, but feel it should be consistent. So
>> I'd like some feedback from others on what they feel would be best. I
>> think there are three options -
>>
>> 1. All defgroup and defcustom definitions go into vm-vars.el. For a long
>> time, the vm-vars.el has been the primary file where most people go to
>> see what things can be customized/changed. Having it all in one file
>> could be quite convenient, especially if you someone who prefers using
>> ..vm over using customize. However, this file is becoming quite large
>> (6017 lines at present).
>>
>> 2. Have the variables and groups defined in the file where they are
>> used. This has the advantage that all related things are kept together.
>> It has the disadvantage that you would have to look in multiple files
>> for customizable variables etc. Not an issue if you use custom, but
>> could be a pain for those who like to customize everythig in their .vm
>> file. In some cases, it would be difficult to decide the best 'owner'
>> file as some variables are used in multiple places etc.
>>
>> 3. Put related defgroup/defcustom definitions into their own files and
>> have vm-vars.el require those files. This would make vm-vars.el smaller
>> and probably make it easier to find specific defcustom variable
>> definitions etc.
>>
>> I personally don't have a preference, but if pushed, would probably go
>> with option 1. This will probably be what I do if nobody else has any
>> opinion. It would also appear to be the option with least potential
>> impact.
>>
>> Tim
>>
>