Re: Bug #25608 and the comment-cache branch

[martin rudalics <rudalics@gmx.at>]

 > This argument right here is why I would vote against comment-cache: I'd rather
 > have parens-in-comments-at-column-0 parsed incorrectly -- at least, until
 > syntax-ppss is fixed -- than to add another cache just to fix this problem.
 > Unless I've missed something...

It makes me rather sad that this discussion does not consider ecological
consequences at all.  IIUC it started because of a "(c)" copyright
characters sequence in the comment of some C code.  Doesn't it strike
anyone as the ultimate irony to consider this an issue in the context of
copylefted software?

Also IIUC we still adhere to the GNU coding standards which clearly say
that

   It is important to put the open-brace that starts the body of a C
   function in column one, so that they will start a defun. Several tools
   look for open-braces in column one to find the beginnings of C
   functions. These tools will not work on code not formatted that way.

   Avoid putting open-brace, open-parenthesis or open-bracket in column
   one when they are inside a function, so that they won’t start a
   defun. The open-brace that starts a struct body can go in column one
   if you find it useful to treat that definition as a defun.

The continuous attempts to deceive this standard's rules have been
harassing me for many years now.  If people do like copyrighted code and
code written according to non-GNU standards, then we should provide at
least one single option that respects an open paren in column zero where
it belongs to: At the beginning of a defun and nowhere else.

In Emacs this option is called `open-paren-in-column-0-is-defun-start'.
Emacs code should obey this option in the sense that if it is non-nil,
it should behave ecologically in terms of consumption of CPU cycles and
memory space.

martin