Re: font-lock-syntactic-keywords obsolet?

[Stefan Monnier]

> I've tried doing this with an actual bug, namely bug #22983 "syntax-ppss
> returns wrong result".  That was over three months ago, and still there
> is no fix.

Indeed, no fix.  A few reasons:
- Lack of a concrete case which suffers from it (not much immediate benefit).
- In many cases, it's easier to fix the other side (the caller of syntax-ppss).
- It's hard to fix it right, not because of syntax-ppss in particular,
  but because it's hard to make a generic facility which can be fast by
  using a cache, yet is not being told where is the real intended
  beginning of the buffer.  In CC-mode you just decided to punt and
  disallow the use of cc-mode where 1 is not the real beginning of the
  C code.  So your approach suffers from the same problem (just the
  other side of it) and you haven't fixed it either.

This said, a quick&dirty fix (if such was needed, e.g. because of a concrete
case which exhibits the problem) would be to make syntax-ppss
always widen (and maybe add a syntax-ppss-dont-widen).  Given that
there's no real hurry to fix it, I'd rather we fix it right.

> You don't appear to want to take any responsibility for
> getting it fixed, even though it's in "your" code.

I definitely don't want to take responsibility to fix anything in
particular, indeed.  I hate it when a core functionality is only touched
by a single individual, because it makes Emacs's development vulnerable
to the disappearance of that individual.
So I'd like for someone else to dig into syntax.el.

> I've no expectation anything would be done about more abstract design
> flaws reported as bugs.

Even more abstract than bug#22983?  No indeed, I'm not going to waste my
time on such things.

Just like you're not wasting your time trying to fix the fundamental
breakage of CC-mode relying on some relations between
before-change-functions, after-change-functions, and actual
highlighting.  As long as real concrete cases don't show up, the
motivation is very low.

> What I dislike about these things, as you well know, are the failings in
> their fundamental design and the restrictions these place upon other
> software, the way things were implemented before being thought through
> properly.

Believe me I did think about those things quite a bit before
implementing them.

> So we have bug #22983, and we have the ghastly abortion of low level
> code in syntax.c calling out to high level lisp code "just to make
> sure things are propertized properly".

There's an example of something I've thought about a lot before
implementing it.  The precise implementation is probably not perfect,
but the fundamental design is something I mulled over for a long time.
It's far from perfect, but if we want to avoid re-scanning the whole
buffer between point and point-max, we need the updates to be performed
lazily, and a call to forward-sexp can't know how far ahead to do it
until it's actually scanning.

You made a different trade off in CC-mode, of trying hard to catch most
cases where the rescan would end up not making any change.  I find it is
much too difficult to do such a thing in general to be worth the effort,
so I preferred to try and gain speed by using laziness instead.

Your trade-off also suffers from "fundamental design flaws": if
syntax-propertize wasn't lazy, major modes would be forced to try and
figure out when to optimize away the rescan, and if they don't try hard
enough, they'd suffer from poor performance on large buffers.


        Stefan