On 12.02.2017 12:14, martin rudalics wrote:
> > 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
>
>

Hi Martin,

thanks. IMO you addressed two core-issues of Emacs' future: a political 
and a technical one.

As for the copyright, conceive it as contradicting to the idea of free 
software - whilst the paperworks reached out here rely on it.

open-paren-in-column-0-is-defun-start ignores the fact functions 
commonly might be nested.
That way Emacs can't handle nested definitions reliably.

Why not have a purely GPL-based Emacs with the 
open-paren-in-column-0-is-defun-start hampering removed?

Make Emacs still greater,

Andreas