Matt> My apologies if this is not the proper forum for this; it Matt> seemed the most appropiate at first glance. It's the right place. Matt> I've been told that some effort was made to introduce this Matt> feature to the XEmacs folks, but that there was little Matt> interest. If so, they managed to keep it a complete secret from the whole XEmacs community; there were two hits on a search for the words "overrid", "syntax", and "table" in the whole xemacs-beta archive going back to April 1998. One was a completely irrelevant patch to w3.el; the other was your message of Sept 8 2000. Matt> I'm willing to do the work required to incorporate this Matt> functionality, but I wanted to be sure that my changes would Matt> be accepted, and would be in line with the general Matt> philosophies of XEmacs development (which seem to differ Matt> from FSF's in a number of ways). _Nobody's_ changes are _sure_ to be accepted. My impression is that trying them out is almost surely acceptable, though. For one thing, most people generally support synching to the FSF API and features. The typical procedure is 1. Add the new code to the development branch conditional on a preprocessor variable. If it is visible to the Lisp level, a feature that allows conditionalization of Lisp code on its presence or absence should be created as well. 2. Add a configure option to enable or disable the new code through definitions in src/config.h. 3. If after testing no serious problems are discovered (in this case, since it would add additional processing to _each_ character for the already slow fontlock code, efficiency might be a serious gripe), either the configure option is made the default or the conditionalization and the option are removed. Alternatively, for options that are of great use to some users and a nuisance to others, either the build-time configure option can be retained or some kind of runtime switch can be created. This would be done through the normal patch-submission process (post a patch with ChangeLog entry to xemacs-patches(a)xemacs.org). In principle, all patches are reviewed, this would be no exception. If there is strong support for the feature from the existing developers, then the feature might be made the default as soon as it starts working most of the time, so that it can be tested by as many people as possible. If support is weak, or divided, then it wouldn't become default until more people were convinced of its value. I suppose the philosophy of XEmacs development should be easy to infer from this "typical procedure." Speaking only for myself, I'd very much like to see this tried (although I don't use Perl much myself). The only likely opposition I can see is that several people are starting to make noises about wanting a major release in the near term, so that the development branch may get frozen soon. I don't know how quickly a new unstable branch would get opened. Matt> FSF Emacs uses the concept of a 'global syntax state' which Matt> is maintained and updated as the pointer is moved through Matt> the buffer by the syntax handling routines. This seems Matt> overkill to me, since the correct syntax type could simply Matt> be determined for any given character position on demand. Presumably this is an optimization; text property handling at the Lisp level adds a significant amount of overhead to operations on characters, and things like fontlock are already slow. However, you could always add the global syntax state code later. The risk would be that people would decide your code was too slow without it, and that kind of impression can be hard to undo. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."