Re: syntax-table text properties
Matt Tucker <tuck(a)whistlingfish.net> writes:
-- Hrvoje Niksic <hniksic(a)arsdigita.com> spake thusly:
> Do you plan to add the support for this to the regex code? I have no
> idea how hard that is, or whether the FSF had done it?
Absolutely. In fact, it's next on my list of things to do.
Excellent. After that, I think your patch should just go in.
I don't think we even need the configure-time switch, heavens know we
have too many of these already. We can keep the Lisp variable for
font-lock, though, to bring us through the debugging stage.
FSF supports it, but my impression is that that support might not be
complete. (I've noticed there are a few places in the FSF code where
they don't correctly lookup the syntax table property. My suspicion
is that since this is not a heavily used feature, this hasn't ever
been noticed. I'm trying to clean up these instances as I go.)
That's one of the rare good things about "merges" with FSF Emacs: the
code gets better debugging because it goes through at least another
pair of careful eyes.
I can certainly see the value in it. I'm a bit concerned about
the
cost of having to calculate that each time through the parse (on top
of lookup up all the extents in the first place).
I agree.
I suppose the right way to do it is instead of keeping a single
syntax table, keep a list of all syntax tables (from innermost out
to the buffer's) and when doing the lookup for a character run
through this list until a match is hit.
Yes. Also, you could optimize things by caching these lists in
internal hash tables, at the time when they're added to the extent
(you have control over the extents code, so you can do that).
One question would be whether a specified code could be overridden
by a more specific table. For example:
This is some text with custom syntax tables.
^---- custom table ---------------^
^-- whitespace --------------^
^ -- custom table -^
Would "custom syntax tables" be whitespace, or would it use the
second custom table for its lookups, and only be whitespace in the
case of characters that don't have a match in the second table?
I would say the latter.
I'll probably end up implementing overlappable extents in the
next
version, despite the fact that I don't see a need for it yet.
(Perhaps someone else will, if the feature is there.)
That would be cool. You might want to look if adding the overlapping
support would break compatibility with the FSF for the common cases.
And there's the speed issue again. XEmacs is very complex. We should
always be extremely careful with adding this kind of stuff.