vm team mailing list archive

[Tim Cross <tcross@xxxxxxxxxxxxxxx>]

From: Uday Reddy <u.s.reddy@xxxxxxxxxxxxx>
Subject: Re: Compiler warnings
Date: Sat, 19 Jun 2010 15:35:56 +0100

> On 6/19/2010 6:26 AM, Tim X wrote:
> 
>> I looked at some of the warnings. Although I may be wrong, I think a few
>> of them, especially the faces related ones and some of the ones with
>> wrong number of arguments are due to differences between GNU Emacs and
>> Xemacs. Not sure what we should do. Probably the most reliable method
>> would be to either test for type of emacs and call whichever is
>> appropriate. Another possiblity may be to break things up into xemacs
>> and gnu emacs code files - this might be particularly useful for the
>> faces stuff. While it has been sometime since I checked, there was
>> considerable difference between emacs and xemcs in that area (in fact,
>> emacspeak no longer works with xemacs largely because of this. Emacspeak
>> uses face information to alter speech properties. A sort of voice
>> locking, where different voices are used to indicate differences in text
>> in a similar way to colors ini font-locking. Differences in how xemacs
>> and emacs dealt with this area made it very difficult to maintain a
>> version that would run on both).
> 
> What we generally do is to define functions with vm- prefix, and put in
> vm-misc.el the case-based implementations for different versions of Emacs. If
> you look in lp:~reddyuday/vm/warnings, you will see a few definitions I have
> added to vm-misc.el. There are others there already.
>

OK, I'll check them out.
 
>> The other thing I was wondering about is if there is any position on
>> backwards compatibility? Many of the warnings are probably due to
>> changes occuring in versions. While not a big issue yet, it is likely to
>> become more so as time passes. This could be especially so with the
>> improved support for multibyte characters and encodings etc. We probably
>> should have some standard on this so that anyone who wants to contribute
>> can make a call on whether they need to add code to support an older
>> version or just ignore possible negative impact on an older version in
>> exchange for cleaner and more maintainiable code for later versions. For
>> example, I would think only supporting emacs 21 onwards would be
>> reasonable for future versions. Anyone running emacs 20 or less (would
>> anyone be still running emacs 19?) can always stick with earlier
>> versions. Is this something we should canvas with the user community?
> 
> There is an older thread by Ulrich in the newsgroup, where we declared which
> version we will support for VM 8.2.0. I think Gnu Emacs 21 won't be supported.
>

Should we have something on either the homepage or the launchpad page that
makes this explicit. The only problem with newsgroups is getting to old
threads is a pain. While you can use google groups, I find the itnerface
pretty nasty. 

So, we will be supporting from emacs 22. That seems reasonable given the
increased developments that appear to be happening in GNU Emacs these days.
Knowing that helps with the code cleanup. 
 
>> BTW, did you get any response to your request for Xemacs user
>> assistance? Would be really handy to have an xemacs user to at least
>> test some of the work that will need to be done to cleanup some of those
>> compiler warnings.
> 
> No, I haven't received any responses.  The XEmacs users are a quite bunch.
> 
> On the other hand, I have negotiated with Aidan Kehoe on the XEmacs team that
> he will maintain the XEmacs package provided we won't give him more than two
> releases a year to work with. He is going to put in 8.1.1 right now. So, we
> will have another chance when we want to add 8.2.x.
> 
> There are a few XEmacs users who do download the recent releases. But it is
> hopeless to get them to do any work ahead of time. However, after downloading
> a release, they will no doubt report problems they run into.
>

I think as long as people report problems, that will help. We can probably
trace down version issues fairly easily once we know they are there!

Tim