font-locking and open parens in column zero

font-locking and open parens in column zero

[martin rudalics]

NEWS contains the entry:


+++
*** font-lock: in modes like C and Lisp where the fontification assumes that
an open-paren in column 0 is always outside of any string or comment,
font-lock now highlights any such open-paren-in-column-zero in bold-red
if it is inside a string or a comment, to indicate that it can cause
trouble with fontification and/or indentation.


This entry is wrong: In C mode open parens in column 0 are not
highlighted in bold-red, probably due to the test

	     (eq (or syntax-begin-function
		     font-lock-beginning-of-syntax-function)
		 'beginning-of-defun)

in `font-lock-compile-keywords' which fails since
`syntax-begin-function' equals `c-beginning-of-syntax' in C mode.

I'd propose to either not mention C mode in the NEWS entry or change
`font-lock-compile-keywords' appropriately, for example, by setting and
checking a property of the involved symbols.

In addition, it might seem reasonable to check whether the settings of
`open-paren-in-column-0-is-defun-start' conflict with the approach used
by `font-lock-compile-keywords'.  Currently, any user settings for
`open-paren-in-column-0-is-defun-start' are overridden by C mode.

Re: font-locking and open parens in column zero

[Richard Stallman]

    +++
    *** font-lock: in modes like C and Lisp where the fontification assumes that
    an open-paren in column 0 is always outside of any string or comment,
    font-lock now highlights any such open-paren-in-column-zero in bold-red
    if it is inside a string or a comment, to indicate that it can cause
    trouble with fontification and/or indentation.

That is probably obsolete, from the days before C mode started using
`c-beginning-of-syntax'.  This feature is no longer needed in C mode,
since `c-beginning-of-syntax' prevents the confusion it was meant to warn
the user about.

So I will update this NEWS entry.

Thanks.

Re: font-locking and open parens in column zero

[martin rudalics]

 > That is probably obsolete, from the days before C mode started using
 > `c-beginning-of-syntax'.  This feature is no longer needed in C mode,
 > since `c-beginning-of-syntax' prevents the confusion it was meant to warn
 > the user about.

When `c-beginning-of-syntax' doesn't find a cached position it calls
`c-beginning-of-defun-1' which, on Emacs, calls `beginning-of-defun':

(1) With emacs -Q open ~/src/syntax.c

(2) Execute

(defun foo ()
   (interactive)
   (re-search-forward "string-to-syntax")
   (forward-line 6)
   (recenter 0))

This will fontify the entire body of `string_to_syntax' as a C string
due to the left paren in column zero of the doc-string.

Re: font-locking and open parens in column zero

[Stefan Monnier]

>> That is probably obsolete, from the days before C mode started using
>> `c-beginning-of-syntax'.  This feature is no longer needed in C mode,
>> since `c-beginning-of-syntax' prevents the confusion it was meant to warn
>> the user about.

> When `c-beginning-of-syntax' doesn't find a cached position it calls
> `c-beginning-of-defun-1' which, on Emacs, calls `beginning-of-defun':

> (1) With emacs -Q open ~/src/syntax.c

> (2) Execute

> (defun foo ()
>   (interactive)
>   (re-search-forward "string-to-syntax")
>   (forward-line 6)
>   (recenter 0))

> This will fontify the entire body of `string_to_syntax' as a C string
> due to the left paren in column zero of the doc-string.

Then C-mode's font-lock-keywords should highlight this open-paren.
It's not font-lock's job to figure out what c-beginning-of-defun does.
Maybe I should completely remove this tweak in font-lock.el and move it to
lisp-modes (which other modes does it work with anyway)?


        Stefan

Re: font-locking and open parens in column zero

[Richard Stallman]

    When `c-beginning-of-syntax' doesn't find a cached position it calls
    `c-beginning-of-defun-1' which, on Emacs, calls `beginning-of-defun':

Do you think that is a bug?
Is it doing the wrong thing here?

    (1) With emacs -Q open ~/src/syntax.c

    (2) Execute

    (defun foo ()
       (interactive)
       (re-search-forward "string-to-syntax")
       (forward-line 6)
       (recenter 0))

    This will fontify the entire body of `string_to_syntax' as a C string
    due to the left paren in column zero of the doc-string.

That seems like a bug to me, more or less.  But it doesn't seem to
happen often; I tried a little exploring in a C file and it usually
seems not to be fooled by open-parens in column 0.

Can you figure out what it is about this case that causes
it to fail?

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: font-locking and open parens in column zero

[martin rudalics]

Richard Stallman schrieb:
 >     When `c-beginning-of-syntax' doesn't find a cached position it calls
 >     `c-beginning-of-defun-1' which, on Emacs, calls `beginning-of-defun':
 >
 > Do you think that is a bug?
 > Is it doing the wrong thing here?

No.  But with a paren-in-column-zero within a comment, fontification may
fail just as it fails for Elisp.

 >     (1) With emacs -Q open ~/src/syntax.c
 >
 >     (2) Execute
 >
 >     (defun foo ()
 >        (interactive)
 >        (re-search-forward "string-to-syntax")
 >        (forward-line 6)
 >        (recenter 0))
 >
 >     This will fontify the entire body of `string_to_syntax' as a C string
 >     due to the left paren in column zero of the doc-string.
 >
 > That seems like a bug to me, more or less.  But it doesn't seem to
 > happen often; I tried a little exploring in a C file and it usually
 > seems not to be fooled by open-parens in column 0.
 >
 > Can you figure out what it is about this case that causes
 > it to fail?

It's the standard paren-in-column-zero problem which is decribed in the
manual and not considered a bug in Elisp fontification either.  I think,
it should happen as frequently for C as it happens for Elisp.  Hence a
warning face for such parens could be useful just as it is for Elisp.
Since I have stealth fontification turned off, this problem might bite
me more frequently.

Note also the strange dichotomy between this problem amd the
`open-paren-in-column-0-is-defun-start' option.  C mode sets this to nil
with the explanation

   ;; In Emacs 21 and later it's possible to turn off the ad-hoc
   ;; heuristic that open parens in column 0 are defun starters.  Since
   ;; we have c-state-cache, that heuristic isn't useful and only causes
   ;; trouble, so turn it off.

That motivation is strange since, if the c-state-cache does not contain
anything useful, C mode has to use `beginning-of-defun'.  Moreover, if
`defun-prompt-regexp' is nil, `open-paren-in-column-0-is-defun-start'
does _not_ affect the behavior of `beginning-of-defun' and the later
does search for an open paren in column zero.


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: font-locking and open parens in column zero

[Richard Stallman]

    It's the standard paren-in-column-zero problem which is decribed in the
    manual and not considered a bug in Elisp fontification either.  I think,
    it should happen as frequently for C as it happens for Elisp.

That seems unlikely to me.  In my (small) experiments
I did not observe this to happen at all.  You've said it
can happen, and I will take your word for it, but it appears
to be unusual in practice.

      Hence a
    warning face for such parens could be useful just as it is for Elisp.

I suppose so -- and isn't the feature available for C?
When Emacs does get confused about a ( in C mode,
does it show that ( in red?

My point is that the ( usually does not appear in red
because Emacs usually does not get confused by it.

       ;; In Emacs 21 and later it's possible to turn off the ad-hoc
       ;; heuristic that open parens in column 0 are defun starters.  Since
       ;; we have c-state-cache, that heuristic isn't useful and only causes
       ;; trouble, so turn it off.

    That motivation is strange

The reason for C mode to set this to nil
is that C mode specifies its own way to find the start of a defun.
My understanding is that if open-paren-in-column-0-is-defun-start is t
then Emacs will ALWAYS look back for the last ( in column 0.
This is clearly wrong for C mode.


    That motivation is strange since, if the c-state-cache does not contain
    anything useful, C mode has to use `beginning-of-defun'.

Are you saying that this is the case where C mode fails to be
sophisticated about finding the start of the function?

Is that a bug in CC mode?

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: font-locking and open parens in column zero

[martin rudalics]

 >     It's the standard paren-in-column-zero problem which is decribed in the
 >     manual and not considered a bug in Elisp fontification either.  I think,
 >     it should happen as frequently for C as it happens for Elisp.
 >
 > That seems unlikely to me.  In my (small) experiments
 > I did not observe this to happen at all.  You've said it
 > can happen, and I will take your word for it, but it appears
 > to be unusual in practice.

It likely happens more frequently with stealth-fontification turned off.

 >       Hence a
 >     warning face for such parens could be useful just as it is for Elisp.
 >
 > I suppose so -- and isn't the feature available for C?
 > When Emacs does get confused about a ( in C mode,
 > does it show that ( in red?

It can't.  C mode uses its own `beginning-of-defun-function' and Emacs
doesn't bother in that case (font-lock isn't clairvoyant).

 > My point is that the ( usually does not appear in red
 > because Emacs usually does not get confused by it.

With `syntax-ppss' Emacs usually doesn't get confused for Elisp either.
It will get confused iff it has to use `beginning-of-defun' when there's
no suitable cache entry.  Hence, whatever holds for Elisp holds for C.

 > The reason for C mode to set this to nil
 > is that C mode specifies its own way to find the start of a defun.
 > My understanding is that if open-paren-in-column-0-is-defun-start is t
 > then Emacs will ALWAYS look back for the last ( in column 0.
 > This is clearly wrong for C mode.

Emacs means `beginning-of-defun-raw' here, I suppose, since that's the
only place where `open-paren-in-column-0-is-defun-start' is consulted.
I think it's of no importance if this is set in one way or the other
since `beginning-of-defun-raw' ALWAYS searches for a plain open paren
in column zero when `defun-prompt-regexp' is nil.  Hence if looking back
"for the last ( in column 0" is wrong for C mode, as you say, using
`beginning-of-defun' is wrong for C mode.

BTW, I fail to understand why `open-paren-in-column-0-is-defun-start' is
a user option and what a user would be able to accomplish by setting it.
Doc-string and Info are rather misleading here and your understanding of
this confuses me even more.

 >     That motivation is strange since, if the c-state-cache does not contain
 >     anything useful, C mode has to use `beginning-of-defun'.
 >
 > Are you saying that this is the case where C mode fails to be
 > sophisticated about finding the start of the function?

Yes.  There's also an appropriate comment in cc-engine.el:

       ;; The position is far back.  Try `c-beginning-of-defun-1'
       ;; (although we can't be entirely sure it will go to a position
       ;; outside a comment or string in current emacsen).  FIXME:
       ;; Consult `syntax-ppss' here.

 > Is that a bug in CC mode?

It's been that way ever since.  It would have been nice if C mode
adopted the same convention as Elisp - namely to paint such parens red.
But my original complaint was about the NEWS entry insinuating that such
a feature existed for C mode.  Hence we probably shouldn't bother.



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: font-locking and open parens in column zero

[Richard Stallman]

     > I suppose so -- and isn't the feature available for C?
     > When Emacs does get confused about a ( in C mode,
     > does it show that ( in red?

    It can't.  C mode uses its own `beginning-of-defun-function' and Emacs
    doesn't bother in that case (font-lock isn't clairvoyant).

Where is the code which does this?  We could look at making it
handle the case where there is a beginning-of-defun-function,
if you show me which code would need to be changed.

     > My point is that the ( usually does not appear in red
     > because Emacs usually does not get confused by it.

    With `syntax-ppss' Emacs usually doesn't get confused for Elisp either.
    It will get confused iff it has to use `beginning-of-defun' when there's
    no suitable cache entry.  Hence, whatever holds for Elisp holds for C.

I can't follow what you are saying.  It sounds like you are saying that
this feature does NOT work as designed either for Lisp or for C.
Is that what you mean?

If so, can you provide a complete self-contained description of the
problem?  That is what I need in order to understand.

Can you provide a test case for the problem?

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: font-locking and open parens in column zero

[martin rudalics]

 >     It can't.  C mode uses its own `beginning-of-defun-function' and Emacs
 >     doesn't bother in that case (font-lock isn't clairvoyant).
 >
 > Where is the code which does this?  We could look at making it
 > handle the case where there is a beginning-of-defun-function,
 > if you show me which code would need to be changed.

I lied.  It fails because in the following check in font-lock.el

     (if (and regexp
	     (eq (or syntax-begin-function
		     font-lock-beginning-of-syntax-function)
		 'beginning-of-defun)
	     (not beginning-of-defun-function))
	;; Try to detect when a string or comment contains something that
	;; looks like a defun and would thus confuse font-lock.

`syntax-begin-function' eqs `c-beginning-of-syntax'.  That is, the
second conjunct fails and not the third one as I thought before.  It
would be simple to fix this, e.g., by writing

     (if (and regexp
	     (or (eq (or syntax-begin-function
			 font-lock-beginning-of-syntax-function)
		     'beginning-of-defun)
		 (get 'font-lock-beginning-of-syntax-function
		      'font-lock-warn-about-open-paren-in-column-0))
	     (not beginning-of-defun-function))

and adding

   (put 'font-lock-beginning-of-syntax-function
        'font-lock-warn-about-open-paren-in-column-0 t)

to the code of `c-font-lock-init' (or put that in `c-mode-hook').

But `font-lock-beginning-of-syntax-function' is "semi-obsolete" and it
might be therefore reasonable to have font-lock provide a buffer-local
variable, say `font-lock-warn-about-open-paren-in-column-0', let major
modes set this, and simplify the condition above accordingly.

 >      > My point is that the ( usually does not appear in red
 >      > because Emacs usually does not get confused by it.
 >
 >     With `syntax-ppss' Emacs usually doesn't get confused for Elisp either.
 >     It will get confused iff it has to use `beginning-of-defun' when there's
 >     no suitable cache entry.  Hence, whatever holds for Elisp holds for C.
 >
 > I can't follow what you are saying.  It sounds like you are saying that
 > this feature does NOT work as designed either for Lisp or for C.
 > Is that what you mean?

With the introduction of `syntax-ppss' Emacs hardly ever fails to find
strings and comments.  If and when it fails, the "paint misplaced parens
red" feature works as designed for Lisp.  It does not work at all for C.

Re: font-locking and open parens in column zero

[Richard Stallman]

What would you think of something like this?

*** font-lock.el	16 Sep 2006 13:50:14 -0400	1.306
--- font-lock.el	22 Sep 2006 17:29:23 -0400	
***************
*** 1646,1654 ****
  	  (cons t (cons keywords
  			(mapcar 'font-lock-compile-keyword keywords))))
      (if (and (not syntactic-keywords)
! 	     (eq (or syntax-begin-function
! 		     font-lock-beginning-of-syntax-function)
! 		 'beginning-of-defun)
  	     (not beginning-of-defun-function))
  	;; Try to detect when a string or comment contains something that
  	;; looks like a defun and would thus confuse font-lock.
--- 1646,1656 ----
  	  (cons t (cons keywords
  			(mapcar 'font-lock-compile-keyword keywords))))
      (if (and (not syntactic-keywords)
! 	     (let ((beg-function
! 		    (or syntax-begin-function
! 			font-lock-beginning-of-syntax-function)))
! 	       (or (eq beg-function 'beginning-of-defun)
! 		   (get beginning-of-defun 'font-lock-syntax-paren-check)))
  	     (not beginning-of-defun-function))
  	;; Try to detect when a string or comment contains something that
  	;; looks like a defun and would thus confuse font-lock.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: font-locking and open parens in column zero

[martin rudalics]

 > What would you think of something like this?
 >
 > *** font-lock.el	16 Sep 2006 13:50:14 -0400	1.306
 > --- font-lock.el	22 Sep 2006 17:29:23 -0400	
 > ***************
 > *** 1646,1654 ****
 >   	  (cons t (cons keywords
 >   			(mapcar 'font-lock-compile-keyword keywords))))
 >       (if (and (not syntactic-keywords)
 > ! 	     (eq (or syntax-begin-function
 > ! 		     font-lock-beginning-of-syntax-function)
 > ! 		 'beginning-of-defun)
 >   	     (not beginning-of-defun-function))
 >   	;; Try to detect when a string or comment contains something that
 >   	;; looks like a defun and would thus confuse font-lock.
 > --- 1646,1656 ----
 >   	  (cons t (cons keywords
 >   			(mapcar 'font-lock-compile-keyword keywords))))
 >       (if (and (not syntactic-keywords)
 > ! 	     (let ((beg-function
 > ! 		    (or syntax-begin-function
 > ! 			font-lock-beginning-of-syntax-function)))
 > ! 	       (or (eq beg-function 'beginning-of-defun)
 > ! 		   (get beginning-of-defun 'font-lock-syntax-paren-check)))
 >   	     (not beginning-of-defun-function))
 >   	;; Try to detect when a string or comment contains something that
 >   	;; looks like a defun and would thus confuse font-lock.



We presume that major modes that introduce conflicting settings for
`syntax-begin-function' and `font-lock-beginning-of-syntax-function' are
on their own?  In any case, `beginning-of-defun' is not buffer-local.
Hence, I'd prefer something like:

*** font-lock.el	Sat Sep 23 11:08:56 2006	1.306
--- font-lock.el	Sat Sep 23 16:32:08 2006
***************
*** 1646,1654 ****
   	  (cons t (cons keywords
   			(mapcar 'font-lock-compile-keyword keywords))))
       (if (and (not syntactic-keywords)
! 	     (eq (or syntax-begin-function
! 		     font-lock-beginning-of-syntax-function)
! 		 'beginning-of-defun)
   	     (not beginning-of-defun-function))
   	;; Try to detect when a string or comment contains something that
   	;; looks like a defun and would thus confuse font-lock.
--- 1646,1656 ----
   	  (cons t (cons keywords
   			(mapcar 'font-lock-compile-keyword keywords))))
       (if (and (not syntactic-keywords)
! 	     (let ((beg-function
! 		    (or 'syntax-begin-function
! 			'font-lock-beginning-of-syntax-function)))
! 	       (or (eq (eval beg-function) 'beginning-of-defun)
! 		   (get beg-function 'font-lock-syntax-paren-check)))
   	     (not beginning-of-defun-function))
   	;; Try to detect when a string or comment contains something that
   	;; looks like a defun and would thus confuse font-lock.


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: font-locking and open parens in column zero

[Richard Stallman]

    We presume that major modes that introduce conflicting settings for
    `syntax-begin-function' and `font-lock-beginning-of-syntax-function' are
    on their own?

I don't think it is right to set both, but I suppose the latter
should take precedence.

I made a M-/ error before.  Please try this version of the patch.

*** font-lock.el	16 Sep 2006 13:50:14 -0400	1.306
--- font-lock.el	23 Sep 2006 15:23:43 -0400	
***************
*** 1646,1654 ****
  	  (cons t (cons keywords
  			(mapcar 'font-lock-compile-keyword keywords))))
      (if (and (not syntactic-keywords)
! 	     (eq (or syntax-begin-function
! 		     font-lock-beginning-of-syntax-function)
! 		 'beginning-of-defun)
  	     (not beginning-of-defun-function))
  	;; Try to detect when a string or comment contains something that
  	;; looks like a defun and would thus confuse font-lock.
--- 1646,1656 ----
  	  (cons t (cons keywords
  			(mapcar 'font-lock-compile-keyword keywords))))
      (if (and (not syntactic-keywords)
! 	     (let ((beg-function
! 		    (or font-lock-beginning-of-syntax-function
! 			syntax-begin-function)))
! 	       (or (eq beg-function 'beginning-of-defun)
! 		   (get beg-function 'font-lock-syntax-paren-check)))
  	     (not beginning-of-defun-function))
  	;; Try to detect when a string or comment contains something that
  	;; looks like a defun and would thus confuse font-lock.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: font-locking and open parens in column zero

[martin rudalics]

 > I made a M-/ error before.  Please try this version of the patch.

It doesn't work for me provided I use something like

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

I'm probably too silly but using

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

instead and applying the patch below works for me.

*** font-lock.el	Sat Sep 23 11:08:56 2006	1.306
--- font-lock.el	Sun Sep 24 10:52:26 2006
***************
*** 1646,1654 ****
   	  (cons t (cons keywords
   			(mapcar 'font-lock-compile-keyword keywords))))
       (if (and (not syntactic-keywords)
! 	     (eq (or syntax-begin-function
! 		     font-lock-beginning-of-syntax-function)
! 		 'beginning-of-defun)
   	     (not beginning-of-defun-function))
   	;; Try to detect when a string or comment contains something that
   	;; looks like a defun and would thus confuse font-lock.
--- 1646,1656 ----
   	  (cons t (cons keywords
   			(mapcar 'font-lock-compile-keyword keywords))))
       (if (and (not syntactic-keywords)
! 	     (let ((beg-function
! 		    (or 'font-lock-beginning-of-syntax-function
! 			'syntax-begin-function)))
! 	       (or (eq (eval beg-function) 'beginning-of-defun)
! 		   (get beg-function 'font-lock-syntax-paren-check)))
   	     (not beginning-of-defun-function))
   	;; Try to detect when a string or comment contains something that
   	;; looks like a defun and would thus confuse font-lock.


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: font-locking and open parens in column zero

[Stefan Monnier]

>> I made a M-/ error before.  Please try this version of the patch.

> It doesn't work for me provided I use something like

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

You mean (put 'c-beginning-of-defun 'font-lock-syntax-paren-check t)?

> ! 		    (or 'font-lock-beginning-of-syntax-function
> ! 			'syntax-begin-function)))

Huh?  This is equal to just 'font-lock-beginning-of-syntax-function.

> ! 	       (or (eq (eval beg-function) 'beginning-of-defun)

I have no idea what this `eval' is about.  `beg-function' contains
a function, i.e. a symbol (whose value when interpreted as a variable should
not have any significance) or a lambda expression, so evaluating should be at
best useless.


        Stefan

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: font-locking and open parens in column zero

[martin rudalics]

 > You mean (put 'c-beginning-of-defun 'font-lock-syntax-paren-check t)?

You mean (put 'c-beginning-of-syntax 'font-lock-syntax-paren-check t)?
You're right.

 >
 >>! 		    (or 'font-lock-beginning-of-syntax-function
 >>! 			'syntax-begin-function)))
 >
 >
 > Huh?  This is equal to just 'font-lock-beginning-of-syntax-function.
 >
 >
 >>! 	       (or (eq (eval beg-function) 'beginning-of-defun)
 >
 >
 > I have no idea what this `eval' is about.  `beg-function' contains
 > a function, i.e. a symbol (whose value when interpreted as a variable should
 > not have any significance) or a lambda expression, so evaluating should be at
 > best useless.

You mean my patch was downright silly?  You're right.

martin, who must have been in really bad shape when he wrote this


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: font-locking and open parens in column zero

[Richard Stallman]

    I'm probably too silly but using

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

That makes no sense, because its effect is independent of
the value of the variable font-lock-beginning-of-syntax-function.

    It doesn't work for me provided I use something like

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

It ought to work.
Can you debug why it fails?

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: font-locking and open parens in column zero

[martin rudalics]

 >        (put font-lock-beginning-of-syntax-function
 > 	    'font-lock-syntax-paren-check t)
 >
 > It ought to work.

It does work.

 > Can you debug why it fails?

I'd probably have to debug my brain here.  Thanks for fixing this.


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: font-locking and open parens in column zero

[Stefan Monnier]

> +++
> *** font-lock: in modes like C and Lisp where the fontification assumes that
> an open-paren in column 0 is always outside of any string or comment,
> font-lock now highlights any such open-paren-in-column-zero in bold-red
> if it is inside a string or a comment, to indicate that it can cause
> trouble with fontification and/or indentation.

> This entry is wrong: In C mode open parens in column 0 are not
> highlighted in bold-red, probably due to the test

Indeed, C mode has changed since this was written.  Thanks for spotting it.

> In addition, it might seem reasonable to check whether the settings of
> `open-paren-in-column-0-is-defun-start' conflict with the approach used
> by `font-lock-compile-keywords'.  Currently, any user settings for
> `open-paren-in-column-0-is-defun-start' are overridden by C mode.

This feature is unrelated to open-paren-in-column-0-is-defun-start AFAIK.


        Stefan