Re: font-locking and open parens in column 0

[Mackenzie, Alan]

Hi, Martin! 

>-----Ursprüngliche Nachricht-----
>Von: martin rudalics [mailto:address@hidden 
>Gesendet: Freitag, 3. November 2006 15:03
>An: Mackenzie, Alan
>Cc: Richard Stallman; address@hidden; Alan Mackenzie
>Betreff: Re: AW: font-locking and open parens in column 0
>
>Good afternoon, Alan
>

[ .... ]

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

>I fail to understand the present state of things.  On the one hand,
>`open-paren-in-column-0-is-defun-start' is customizable which means a
>user should be able to set it and a major mode should respect that.  On
>the other hand, c-mode deliberately sets this to nil.  I think users
>should be free to express their choice here if they consider their
>machine inapt for scanning from bob.

As far as I can see, the purpose of open-p-i-c-0-i-d-start wasn't
clearly recorded in the ChangeLog.  The value t is clear; I can't think
of any meaning for nil other than the one I've given it.  Certainly,
Martin Stjernholm assumed that meaning (goto a brace at top level) when
he coded up c-beginning-of-defun.  If this meaning is not given to it,
there doesn't seem to be any point in having the variable.

I think it was made customizable so that a user could set it for
"efficiency" (when his perl files' functions all have { at column 0) or
"rigour" (when he uses "k&r" placement of braces in his files.pl).  It
doesn't seem to have worked very well, so far.

CC Mode always sets o-p-i-c-0-i-d-start to nil, and caches the brace
structure to prevent excessive scanning from BOB.  After all, opic0id
being nil will always find BO-defun.  Setting it to t was an optimisation
for when computers were much less powerful than they are now - and this
causes quite a bit of inconvenience.

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

>Font-lock uses `syntax-ppss' which may call `syntax-begin-function'
>which may be defined as `beginning-of-defun' which usually calls
>`beginning-of-defun-raw'.  When I open a C file and jump to a position
>before stealth fontification gets there, that's the way things behave.

OK

> > The case
> > you spotted in syntax.c (and I've really no idea how you did ;-), is
> > such an exceptional case.

>I spotted that incidentally when scrolling backwards through syntax.c.
>Anyway, it *is* exceptional and thus should not warrant any major
>change.  Richard's patch just comes in handy.

I confess I'm not familiar with this.  I've been without net access for
several weeks.  I'm currently at the mercy of Deutsche Telekom, who have
promised to get my new DSL connection working real soon now.  :-(

> > CC Mode caches parenthesis structures.

>... which parallels the work of `syntax-ppss', hence we currently end up
>with two caches for the same structures - I know c-mode has to work hard
>to handle all sorts of older (X)Emacsen ...

Not only that, CC Mode uses its cache for things other than font-locking.

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

>It does fix it, and it's even pretty fast ;-).  But I still think the
>"bug" is with the author who put the left paren in column zero of that
>comment.  That author should be warned just as in emacs-lisp-mode.

Should _HAVE_ been warned.  Martin Stjernholm has worked very hard to
remove that restriction from C Mode without sacrificing (much) speed.  It
would be a shame now to leave the restriction in Emacs 22.

[ .... ]

-- 
Alan.



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