On 12.02.2017 12:14, martin rudalics
argument right here is why I would vote against comment-cache: I'd
> have parens-in-comments-at-column-0 parsed incorrectly -- at
> syntax-ppss is fixed -- than to add another cache just to fix
> Unless I've missed something...
It makes me rather sad that this discussion does not consider
consequences at all. IIUC it started because of a "(c)" copyright
characters sequence in the comment of some C code. Doesn't it
anyone as the ultimate irony to consider this an issue in the
Also IIUC we still adhere to the GNU coding standards which
It is important to put the open-brace that starts the body of a
function in column one, so that they will start a defun. Several
look for open-braces in column one to find the beginnings of C
functions. These tools will not work on code not formatted that
Avoid putting open-brace, open-parenthesis or open-bracket in
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
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 written according to non-GNU standards, then we should
least one single option that respects an open paren in column zero
it belongs to: At the beginning of a defun and nowhere else.
In Emacs this option is called
Emacs code should obey this option in the sense that if it is
it should behave ecologically in terms of consumption of CPU
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,