Re: Mysterious fontification/C++ context issue

[Stefan Monnier]

[ Expanding on my previous message ]

>     Could we revert the change to beginning-of-defun instead?
> It seems clearly incorrect for beginning-of-defun to ignore
> open-paren-in-column-0-is-defun-start.

[ The change I'd like to revert only influences the case where
  defun-prompt-regexp is nil so the non-nil case is implicitly outside of
  this discussion]

Does it?

The docstring doesn't mention anything about it.  And really, when
defun-prompt-regexp is nil, then beginning-of-defun considers that "defun
starts when there is a char with open-parenthesis syntax at the beginning of
a line".  So if open-paren-in-column-0-is-defun-start is nil, it's hard to
figure out what should be considered as a defun start.

It's kind of like saying "I won't tell you what it is, I'll just tell you
that it's not what you think".

Note that open-paren-in-column-0-is-defun-start is only used in back_comment
in syntax.c (where we should remove it by making back_comment use
syntax-ppss) and in beginning-of-defun where it was only used to add the
empty string to defun-prompt-regexp.

> For what other reason does C mode set open-paren-in-column-0-is-defun-start?

Maybe because in C defuns do not start with a paren (neither in column 0 nor
elsewhere)?

Or maybe because Alan uses beginning-of-defun for something for which it was
not designed, and thus ends up having to work around beginning-of-defun's
functionality by first setting open-paren-in-column-0-is-defun-start and
defun-prompt-regexp to some usually unused combination and then putting the
code he really wants to use in beginning-of-defun (whereas he should just
use this code directly without going through beginning-of-defun)?
[ I know this sounds like I'm accusing Alan of plotting.  I'm not.  ]


        Stefan