Re: Mysterious fontification/C++ context issue

[Alan Mackenzie <acm@muc.de>]

Evening, Martin!

On Wed, Dec 06, 2006 at 10:04:23AM +0100, martin rudalics wrote:

[ .... ]

> Thanks for taking care of this.  Please note:

> 1. You don't widen the buffer before calling `syntax-ppss'.

You mean I don't have to, and would get the same result without
widening?  I need to widen anyway, in case point is inside a
comment/string and (point-min) is after the c/s's start.

> 2. A construct built along

> (foo
> ) (bar)

> with point at "bar" might derail font-lock (remember,
> `c-beginning-of-defun-1' calls `beginning-of-defun', not
> `beginning-of-defun-raw').

I think it's best to keep the discussion of beginning-of-defun and the CC
Mode stuff separate.  Once b-o-d works right, the question is then how CC
Mode should use it.  You discuss this below.

> 3. All this is still awfully slow and expensive: Open a larger buffer
> like xdisp.c, jump to its end, hit M-v a couple of times, and look at
> CPU consumption.

UURRRKkk!!  That's not good!  It took me ~6 seconds, and that's not even
on my (deceased) 166 MHz box.  That file is the best part of a megabyte,
though.

> 4. You could avoid the tedious `up-list' steps by using a variant of the
> tentative fix I attached.

(nth 9 ppss) is "Internal data for continuing the parsing".  If we're
going to be using that thing's car as "the least nested paren", why
don't we give up the pretence of an "internal" variable and document it
properly?  I know it's used in some other places too, but it seems to
be being economical with our integrity to use it ourselves whilst
telling everybody else "it's internal stuff".  Or has this been
discussed already?

Your patch is more compact than mine was, and makes scrolling in xdisp.c
acceptably (to me) fast.  In fact, that 6 seconds has been reduced to
about half a second.  So it gets my vote.  (I've got a 1.2 GHz Athlon
machine, by the way.)  Just a small point, though: your patch doesn't
handle the silly case (beginning-of-defun 0).  I think this should mean
"point doesn't move".

Is it the `up-list' calls which slow my version down so much?

> 5. Consider making `open-paren-in-column-0-is-defun-start' a real user
> option in C mode.  Let, for example, users decide whether they want to
> respect GNU coding standards [ .... ].

I think I might agree with this, now.  Or is your version of
beginning-of-defun-raw fast enough so that this doesn't really matter?
I think there are lots of programmers who hang braces which open defuns.
I think Java hackers do it a lot.  But we need to implement this in a
way which doesn't repeat the unholy hassle we had with
`require-final-newline'.

I don't think there should be a variable `c-open-paren....-start" - the
name's long enough already.  ;-)  Maybe CC Mode should make
o-p-i-c-o-i-d-s local in each of its buffers.  

> This should also permit binding C-M-a / C-M-e to `c-beginning-of-defun'
> / `c-end-of-defun' when `open-paren-in-column-0-is-defun-start' is nil.

Indeed.

> 6. In any case, the new behavior should be documented since it applies
> whenever `open-paren-in-column-0-is-defun-start' is set to nil.

What new behaviour?  But Richard asked that.

-- 
Alan Mackenzie (Ittersbach, Germany)