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 [email protected] 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. _______________________________________________ Mailing list: https://launchpad.net/~vm Post to : [email protected] Unsubscribe : https://launchpad.net/~vm More help : https://help.launchpad.net/ListHelp
