Re: Mysterious fontification/C++ context issue

[martin rudalics]

> Evening, Martin!

Evening, Alan!

>>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.

No, I mean you have to widen _before_ calling `syntax-ppss'.

>
>
>>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.

In my example `beginning-of-defun' would move to the beginning of the
line and thus not to the outermost level.

>>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?

I don't know.  But it is used in `syntax-ppss' and since you already
call that we probably shouldn't care.  Just add the same comment as
`syntax-ppss' does and let things evolve.

> 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.)

You win, mine is a 1 GHz Athlon.

> 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".

That's what I meant by "tentative" ;-) you'll find more of that.

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

Depends on your mileage, parsing backward is not entirely trivial, you
always have to check for stray comments.

>>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 don't think so.

> 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.

In any case, it should be the user's responsibility - and I'm a user
here myself ...