-- Damien Neil <neild(a)misago.org> spake thusly:
Matt Tucker <tuck(a)whistlingfish.net> wrote:
> I notice that three of them are dependant on the variable
> 'parse-sexp-lookup-properties being bound. Unfortunately when I
> ported syntax-table properties (extents) from Emacs I changed some
> variable names, this one included. Presumably cperl-mode needs to be
> patched to check for the correct variable on XEmacs.
Do you have a complete list of the symbol names that were changed?
No, but I could compile one.
Also, is it really wise to introduce an additional incompatability
between Emacs and XEmacs here? I've patched my local copy of
cperl-mode to use either the new name ('lookup-syntax-properties,
right?) or the old one, depending on which is bound; this introduces
a significant ugliness into the code. It also makes using syntax
table properties harder for anyone who is interested in portability.
True, and that thought did cross my mind, although I was primarily
concerned with using names that made sense. For instance,
parse-sexp-lookup-properties is used by more than just the sexp parsing
functions.
However, I can certainly see the value in compatibility. Presumably the
best thing to do would be to either rename the variable(s) in question
or provide aliases to them to maintain GNU Emacs compatibility. Of the
two, I think I prefer the aliasing unless someone has a strong argument
against it.
After patching cperl-mode.el, things do seem to work much better.
Constructs like "$foo = q{troz ' }" are handled properly. There
seem to be some problems with font-lock. When I first load a file,
the amount of decoration is higher than what is applied when editing
the file. For example, the word "new" in the phrase "sub new {}"
is rendered using font-lock-function-name-face when I first load
a Perl file, but is rendered with the default face when I type it
into an existing buffer.
I don't have this issue, so there must be further differences between
my system and yours. What version of cperl-mode are you using?