From: "Andreas Röhler" <andreas.roehler@online.de>
To: emacs-devel@gnu.org
Cc: martin rudalics <rudalics@gmx.at>, John Wiegley <johnw@gnu.org>
Subject: Re: Bug #25608 and the comment-cache branch
Date: Sun, 12 Feb 2017 16:05:29 +0100 [thread overview]
Message-ID: <cea1cec1-4f6e-430b-5434-eb9913f4b282@online.de> (raw)
In-Reply-To: <58A04393.9050207@gmx.at>
[-- Attachment #1: Type: text/plain, Size: 2445 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 3546 bytes --]
next prev parent reply other threads:[~2017-02-12 15:05 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-02 20:24 Bug #25608 and the comment-cache branch Alan Mackenzie
2017-02-02 20:47 ` Eli Zaretskii
2017-02-02 21:51 ` Alan Mackenzie
2017-02-02 22:15 ` Dmitry Gutov
2017-02-03 7:41 ` Eli Zaretskii
2017-02-03 17:29 ` Alan Mackenzie
2017-02-03 22:08 ` Dmitry Gutov
2017-02-04 10:24 ` Alan Mackenzie
2017-02-06 2:09 ` Dmitry Gutov
2017-02-06 19:24 ` Alan Mackenzie
2017-02-07 1:42 ` Dmitry Gutov
2017-02-07 19:21 ` Alan Mackenzie
2017-02-14 15:28 ` Dmitry Gutov
2017-02-14 16:38 ` Stefan Monnier
2017-02-22 2:25 ` Dmitry Gutov
2017-02-22 3:53 ` Stefan Monnier
2017-02-23 14:23 ` Dmitry Gutov
2017-02-23 14:48 ` Stefan Monnier
2017-02-24 7:46 ` Tom Tromey
2017-02-14 21:14 ` Alan Mackenzie
2017-02-16 14:10 ` Stefan Monnier
2017-02-18 10:44 ` Alan Mackenzie
2017-02-18 13:49 ` Stefan Monnier
2017-02-12 2:53 ` John Wiegley
2017-02-12 8:20 ` Elias Mårtenson
2017-02-12 10:47 ` Alan Mackenzie
2017-02-12 11:14 ` martin rudalics
2017-02-12 15:05 ` Andreas Röhler [this message]
2017-02-12 15:39 ` Eli Zaretskii
2017-02-05 22:00 ` Alan Mackenzie
2017-02-06 1:12 ` Stefan Monnier
2017-02-06 18:37 ` Alan Mackenzie
2017-02-08 17:20 ` Eli Zaretskii
2017-02-11 23:25 ` Alan Mackenzie
2017-02-12 0:55 ` Stefan Monnier
2017-02-12 12:05 ` Alan Mackenzie
2017-02-12 13:13 ` Juanma Barranquero
2017-02-12 15:57 ` Dmitry Gutov
2017-02-12 17:29 ` Alan Mackenzie
2017-02-12 20:35 ` Dmitry Gutov
2017-02-13 1:47 ` zhanghj
2017-02-13 5:50 ` Stefan Monnier
2017-02-13 6:45 ` zhanghj
2017-02-13 7:24 ` Stefan Monnier
2017-02-13 7:59 ` zhanghj
2017-02-13 9:25 ` Stefan Monnier
2017-02-13 16:14 ` Drew Adams
2017-02-13 7:05 ` zhanghj
2017-02-13 7:16 ` zhanghj
2017-02-13 14:57 ` Dmitry Gutov
2017-02-12 17:49 ` Stefan Monnier
2017-02-13 18:09 ` Alan Mackenzie
2017-02-13 19:34 ` Eli Zaretskii
2017-02-13 21:21 ` Stefan Monnier
2017-02-02 22:14 ` Dmitry Gutov
2017-02-03 16:44 ` Alan Mackenzie
2017-02-03 21:53 ` Dmitry Gutov
2017-02-04 11:02 ` Alan Mackenzie
2017-02-06 1:28 ` Dmitry Gutov
2017-02-06 19:37 ` Alan Mackenzie
2017-02-06 2:08 ` Stefan Monnier
2017-02-06 20:01 ` Alan Mackenzie
2017-02-06 22:33 ` Stefan Monnier
2017-02-07 21:24 ` Alan Mackenzie
2017-02-08 12:54 ` Stefan Monnier
2017-02-07 15:29 ` Eli Zaretskii
2017-02-07 21:09 ` Alan Mackenzie
2017-02-08 17:28 ` Eli Zaretskii
2017-02-02 23:57 ` Stefan Monnier
2017-02-03 16:19 ` Alan Mackenzie
2017-02-04 9:06 ` Andreas Röhler
2017-02-04 18:18 ` Stefan Monnier
2017-02-04 18:28 ` Alan Mackenzie
2017-02-03 7:49 ` Yuri Khan
2017-02-03 18:30 ` Andreas Röhler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cea1cec1-4f6e-430b-5434-eb9913f4b282@online.de \
--to=andreas.roehler@online.de \
--cc=emacs-devel@gnu.org \
--cc=johnw@gnu.org \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.