emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alan Mackenzie
Subject: Re: Mysterious fontification/C++ context issue - Patch for beginning-of-defun-raw.
Date: 17 Dec 2006 12:10:41 +0100
Date: Sun, 17 Dec 2006 12:21:30 +0000
User-agent: Mutt/1.5.9i

Morning, Stefan!

On Sat, Dec 16, 2006 at 07:04:19PM -0500, Stefan Monnier wrote:
> >> I still haven't seen any explanation for why this code needs to be
> >> in beginning-of-defun-raw.
 
This isn't true, for any normal value of "needs".  I think it's more
accurate to say that you don't accept that the explanation that has been
given is a strong enough justification for the extra code in b-d-d-raw,
which is fair enough.
 
> > Well, it doesn't harm either.
 
> Huh?  Have you looked at the beginning-of-defun-raw code before the
> change and compared to the monster it has become?  All this
> (apparently) because cc-mode wants to use syntax-ppss-toplevel-pos via
> this function rather than calling it directly?
 
No, it's deeper than that.  It's to make the function match its
documentation (see "Left Margin Paren" in the Emacs manual).  It's to
make things work consistently when opic0ids is nil.  Everybody in this
discussion whose native language is English agrees on this point.  ;-)
To be explicit, here is the argument, which has already appeared in this
thread:

(i) The meaning of "beginning-of-defun" in a source file is, and always
has been, a paren at top level.  This proved too slow in early versions
of Emacs, and so the "column 0" heuristic was adopted.  This has been
documented in the Emacs manual since time immemorial; see page "Left
Margin Paren" in the Emacs 21 manual (i.e. before I made any changes to
it.  ;-)

(iii) This column 0 heuristic is just that - a heuristic, not a
definition of b-o-d.

(iv) The variable open-paren-in-column-0-is-defun-start was introduced
in the murky past, and there doesn't seem to be a record of why.  I
can't find any discussion of it in the emacs-devel archives.  However,
it's doc-string states: "Non-nil means an open paren in column 0 denotes
the start of a defun".  Otherwise put, "non-nil means that the column 0
heuristic applies".

(v) By pure logic, this MUST extend to "nil means the column 0 heuristic
does NOT apply".  Otherwise the variable would be meaningless.

(vi) When opic0ids is nil, b-o-d-raw must seek the beginning-of-defun
using the actual definition of b-o-d, namely a paren at top level.

That is the argument.  If you don't accept it, say so, and argue against
it.  But please stop saying that there is no argument.

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

Without that code, when opic0ids is nil, beginning-of-defun doesn't do
the right thing: it finds a column 0 parenthesis rather than one at top
level.  That has been the state up till now, and is _very_ confusing for
Elisp hackers.

That said, you and Martin R. have convinced me that setting opic0ids to
nil is the Wrong Thing to do in CC Mode.  Not only is it too sluggish
for big files, but bad parentheses early in a file.c would foul up the
fontification (and maybe even the syntactic analysis) of all defuns
after it.

I think we should strive to eliminate all this b-o-d confusion after
Emacs 22 has been released.

>         Stefan

-- 
Alan.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]