[Top][All Lists]

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

Re: Bug #25608 and the comment-cache branch

From: Andreas Röhler
Subject: Re: Bug #25608 and the comment-cache branch
Date: Sun, 12 Feb 2017 16:05:29 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Icedove/45.6.0

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

  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.


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,


reply via email to

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