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

[Alan Mackenzie]

Hi, Chong!

On Thu, Dec 14, 2006 at 03:35:45PM -0500, Chong Yidong wrote:
> Alan Mackenzie <address@hidden> writes:

> > I say we should GIVE THE USER THE CHOICE.  I have proposed a way of
> > doing this to which nobody's commented yet:  Have three values for
> > the variable with the furlong long name, namely (t nil mode).  t and
> > nil will carry on meaning what they mean, and the symbol 'mode, the
> > default, will mean "Major mode may set its own default here".

> We should also introduce a new variable, call it
> c-open-paren-in-column-0-is-defun-start, defaulting to t.

This approach was tried with c-require-final-newline.  It lead to a lot
of confusion (with require-final-newline) and even resentment.  A
consensus was reached that c-require-final-newline was a bad solution to
a problem.

What problems do you see with open-paren-in-column-0-is-defun-start
having the default 'mode?

> Furthermore, C-mode should define its own beginning-of-defun-function,
> and the syntax-pps code that was inserted into beginning-of-defun-raw
> should be relocated to that function.  Furthermore, the syntax-pps
> code should not be the default behavior, taking effect only if
> c-o-p-i-c-0-i-d-s is nil.

CC Mode has its own b-o-d-f, c-beginning-of-defun.  However, it relies
on a beginning-of-defun before it has filled its own structure cache.
The ppss version of b-o-d expresses the original intent of that
function, namely to find an outermost open-paren.  The Emacs core is
surely the right place for this, since it is a generally useful
functionality.

> (As I and other people have pointed out, defaulting to nil leads to
> unacceptable slowness for moderately big C files on even fast
> machines.  People can set it to t if they are running on 1000000 Ghz
> machines and want to put there parens where they please.)

Well, xdisp.c is a massive file, not a moderately big one, and I
wouldn't find the slowness unacceptable, though that's obviously a
personal thing.  If it were 15 seconds rather than 4, I would freak out
like you're doing now.  I would find massive misfontification (as
happened in syntax.c, the bug for which the pertinent patch is a repair)
totally unacceptable.

This is why I have suggested making the thing configurable.

Another possibility would be a variable like this in place of opic0ids:

(defvar threshold-ppss-bod 200000
  "The buffer size above which a paren in column0 will signal a defun start.
Below this size, a paren at the top level signals a defun start.
If this variable is nil, a paren at top level is always used.  If t, a
paren in column 0 is always used.")

What do you think?

With the patch I suggested last night, you still find an initial M-> in
xdisp.c too slow (~4 seconds on your 1.7 GHz PC).  That's a massively
large file.  How fast must this operation be before you'd find it
acceptable?  In emacs/src, there are files.c of all sizes, ranging from
pre-crt0.c (484 bytes) to xdisp.c (722032 bytes).  If David Kastrup's
conjectured "quadratic dependency" were true (I don't think it is), then
a "typical" sized file.c (say, eval.c at just over 100k) would take ~0.1
seconds for this.  If the dependency is linear, it would take ~0.5
seconds.

Please satisfy my curiosity, experiment with decreasing file sizes, and
tell me at what file size the reaction becomes too slow for you.

-- 
Alan.