emacs-devel
[Top][All Lists]
Advanced

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

Re: font-locking and open parens in column zero


From: martin rudalics
Subject: Re: font-locking and open parens in column zero
Date: Sun, 17 Sep 2006 23:13:55 +0200
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

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






reply via email to

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