emacs-devel
[Top][All Lists]
Advanced

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

AW: font-locking and open parens in column 0


From: Mackenzie, Alan
Subject: AW: font-locking and open parens in column 0
Date: Fri, 3 Nov 2006 09:44:09 +0100

Hi, Martin! 

>-----Urspr√ľngliche Nachricht-----
>Von: martin rudalics [mailto:address@hidden 
>Gesendet: Donnerstag, 2. November 2006 19:32
>An: Mackenzie, Alan
>Cc: address@hidden; Richard Stallman; Alan Mackenzie
>Betreff: Re: font-locking and open parens in column 0

>Good evening, Alan

> > The cause of this (as Martin (almost) discerned) is that the handling of
> > (eq open-paren-in-column-0-is-defun-start nil) in begining-of-defun-raw
> > hasn't been implemented.  The function just looks for a "(" in C0
> > regardless of that variable.
> >
> > "Clearly", when that variable is nil, a defun can begin at no place other
> > than a paren at the outermost level.  Therefore, the function must scan
> > the entire source file from BOB, as in the earliest days.

>No!  That would be a serious regression.  Font-locking should never be
>forced to scan from BOB.

         1         2         3         4         5         6         7  3
I agree with you.  :-)  However, my patch is to do with
beginning-of-defun-raw, not font-locking.  Are you saying that
open-paren-in-column-0-is-defun-start shouldn't exist at all?  When it is
nil, a paren in column 0 may not, of itself, be regarded as a defun
start.

Richard, please say what you think about this.

I would say, rather, that font-locking should not use b-o-defun-raw when
o-p-i-c-0-i-d-s is nil, except in exceptional circumstances.  The case
you spotted in syntax.c (and I've really no idea how you did ;-), is
such an exceptional case.  CC Mode caches parenthesis structures.

My patch did fix the bug (a whole screenful of misfontified string in
syntax.c), though, didn't it?

>Observe that this would only serve to handle
>the rare case where a user puts a paren in column zero of a C comment.
>I think warning about such parens as in emacs-lisp-mode is sufficient.
>Please try to make use of Richard's `font-lock-syntax-paren-check' from
>this thread as with

>     (put font-lock-beginning-of-syntax-function
>        'font-lock-syntax-paren-check t)

>Moreover, any such code as yours should ....

You're talking about my patch to beginning-of-defun-raw, here, not the
stuff in CC Mode.  I don't have the source files to hand at the moment.

>(1) Consult `syntax-ppss' first.
>
>(2) Try to use the 9th field of the return value of 
>`parse-partial-sexp'
>to find the outermost paren instead of up-/forward-/backward-listing.
>
>(3) Crowd the cache of `syntax-ppss' in order to avoid further scans.

OK, thanks!  I'll need to learn about these optimisations.
begining-of-defun-raw, when used in font locking, could be distressingly
slow without them.

-- 
Alan Mackenzie (Ittersbach, Germany)



*******************************************
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte 
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail 
irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und 
loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe 
dieser Mail ist nicht gestattet.
 
This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and delete this e-mail. Any unauthorized copying, 
disclosure or distribution of the contents in this e-mail is strictly forbidden.
*******************************************





reply via email to

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