>>>> "Matt" == Matt Tucker
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
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."