Re: Mysterious fontification/C++ context issue - Patch for beginning-of-defun-raw.

[martin rudalics <rudalics@gmx.at>]

 >>I want to remove that code and go back to what it was before, unless I can
 >>find a *good* explanation for why it needs to be in beginning-of-defun-raw.
 >
 >
 > I think one of the reasons it was put in there was because it doesn't
 > look like it belongs in cc-*.el either.  Since the code should
 > probably not be deleted outright (it seems to work OK for small files,
 > so individual users might want to turn it on), what about putting in a
 > function, call it "syntax-ppss-beginning-of-defun", in syntax.el?

If we really wanted to do something about this we'd have to fix the
find_defun_start problem for `open-paren-in-column-0-is-defun-start'
equalling nil.  Everything else will be a non-issue after that.  M-v has
become unbearably slow in C mode.

Finding a good approximation for the find_defun_start problem is not
entirely trivial.  We'd have to define a `syntax-from-scratch' function
which repeatedly calls

(1) `parse-partial-sexp' on well (probably binomially) distributed
buffer positions, thereafter

(2) executes a second call from that position with a targetdepth zero
argument, before it finally

(3) executes a third call from the last position with a non-nil
stopbefore argument.

Essentially, we'd need something like

............. 1 .. 3 .........1 .. 3 ..... 1 .... 3 .. 1 . 3 .. 1 .. 3

where the "1"s correspond to the buffer positions where we asked
`parse-partial-sexp' to stop in the (1) steps, and the "3"s correspond
to the first `beginning-of-defun' found after that in a (3) step.  Next
we would have to cache the "3" positions and invalidate, in an
after-change-function, all positions following a buffer change.  And we
should reconcile this with syntax-ppss's cache to avoid duplicate work
(after all the "1" positions are similar to what syntax-ppss uses now).