Kim> Possible improvements: > - Put the line number in the left display margin. > - Use a smaller font for the line numbers. > > Making such improvements would be much easier if the package > was targeted for GNU Emacs 22.
The argument that you can do more with a newer Emacs release is an argument I echoed. My point was that if you are *not* doing more, then it makes little sense to gratuitously prevent users of older Emacs releases from taking advantage of your library. The key phrase I used was "if other things are equal". In this case, they are. Leo> Another way of looking at it is that it will get more users to use the > newer versions of emacs and help with the development and testing. I > see no reason not to do that. A specious argument, IMO. Most people who use Emacs 20 have little choice; it is mandated in their place of work or they have no way to install a later version on a captive machine. The obsolescence in question, as you pointed out, was introduced in release *21.1* - many, many moon ago. Surely you don't suggest that we need to encourage testing of that release? Not using `make-local-hook' is no special support for Emacs 22, and it will in no way cause users to leave Emacs 21 to test Emacs 22. Nothing is gained by losing Emacs 20 users of this library. Show me a library that takes advantage of the truly new features of a new release, and I'll likely agree that it should make no attempt to be backward compatible - in fact I already said that. And there are degrees of backward compatibility. Some library authors make an attempt to at least allow some use by older Emacs releases, even as they provide some features that can only be taken advantage of in recent releases. The Emacs user community is not synonymous with the Emacs developers. Emacs developers such as Kim are primarily concerned with the latest and greatest stuff they are developing - they don't often look back. Writers of libraries that are not part of the Emacs distribution are often more concerned about compatibility for users of different releases and even different flavors of Emacs (e.g. XEmacs). If Markus's library will become part of GNU Emacs someday (and I hope it does), then it will in any case undergo a face lift at that time, to make sure that it follows all recommended conventions. As long as it is not part of the Emacs distribution, I'd recommend not locking out users gratuitously, that is, when there is no real gain. _______________________________________________ gnu-emacs-sources mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-emacs-sources
