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
|