From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Andreas_R=c3=b6hler?= Newsgroups: gmane.emacs.devel Subject: Re: Bug #25608 and the comment-cache branch Date: Sun, 12 Feb 2017 16:05:29 +0100 Message-ID: References: <20170202202418.GA2505@acm> <83lgtouxpf.fsf@gnu.org> <20170202215154.GB2505@acm> <83h94bvhzw.fsf@gnu.org> <20170203172952.GC2250@acm> <0a40d539-b7bc-2655-5429-6280022106ee@yandex.ru> <20170204102410.GA2047@acm> <8f9e68fc-4314-625d-b4bf-796c71c91798@yandex.ru> <58A04393.9050207@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------F72F2EB645512F9B2A31AC45" X-Trace: blaine.gmane.org 1486911344 3090 195.159.176.226 (12 Feb 2017 14:55:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 12 Feb 2017 14:55:44 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Icedove/45.6.0 Cc: martin rudalics , John Wiegley To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 12 15:55:37 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ccvYu-0000Q1-VL for ged-emacs-devel@m.gmane.org; Sun, 12 Feb 2017 15:55:37 +0100 Original-Received: from localhost ([::1]:52309 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ccvZ0-0000BT-K8 for ged-emacs-devel@m.gmane.org; Sun, 12 Feb 2017 09:55:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37786) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ccvXv-0000BE-NO for emacs-devel@gnu.org; Sun, 12 Feb 2017 09:54:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ccvXs-00084w-Kn for emacs-devel@gnu.org; Sun, 12 Feb 2017 09:54:35 -0500 Original-Received: from mout.kundenserver.de ([212.227.17.13]:51876) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ccvXs-00084G-8y; Sun, 12 Feb 2017 09:54:32 -0500 Original-Received: from [192.168.178.35] ([77.12.90.87]) by mrelayeu.kundenserver.de (mreue103 [212.227.15.183]) with ESMTPSA (Nemesis) id 0M6xID-1cR9MH3Ba9-00wiVv; Sun, 12 Feb 2017 15:54:29 +0100 In-Reply-To: <58A04393.9050207@gmx.at> X-Provags-ID: V03:K0:HGb6sn57hHfL5wFnBYVLD7GRNdv81lTQavDmuTI/5A6IQ688LIB rzwLXJ3qcQtOzIvY1BzGaYbEOvtltYPWZe9Tqq2CqULtvh1PO8py3LH84fxo+FPB3pGLkju 7xST1IIMBCdPEVOyw8g7ziOIv8sbZYlBQcR+IUV0KeZdBVVxBLbbJYRwVinId6hXDyz74b7 Zps6hranA8x1RYvhCjZgA== X-UI-Out-Filterresults: notjunk:1;V01:K0:PsWsRSVxAWI=:SSyX0FGDVS4fc33HUQT6Uj XK80dQ6QlAD101/L2TTchK8HYz/ZF+SLSnWUeDsxcouvrh7ChA7ORdUse86J2nG+saR/ModJ2 VWlZXUbTHYUzoeDXkCrLmtpz4WwDT4NCkL/qdbu9dcyBwZgSkiGplYXg8IOGNIBwiXD7Cqr6v 41+kr11KXHV4LR+EVNPzB1pxi8Ah1FrEvqFTm7huKIizKC00KBZoA4tHl/mSy9raGvBUFxXca cxQzBI4g9/Nwx7WdiXG/H0/iYCCdBDuqCHVWfd4VItHnvvrHkiFH+jHdTS4ieIyXIvDrTTKAv 3P19+A2dCIdBCA52eFnLclZcLbLMK7F9z+1qCZ1IYzdrPcrV3flYsY1Y/Vd2KFdKzJgB8+RsG +w2jH9PHENuTagKVz59L7zKd7fwwtt5KxWCkIGXXSZSvX7AAa12EtkhRWgXs/rZGawqF5Ibuo 1TQ4fv18TWxU115sI6n+8mPC798wsk/cmXb8OKQvyBABGM1RsN0ZF6/wEAQ/PuV4U8nUewwoe g6KvmNa9YMk7TSAwjJ8tMi18KbX8UvtbB5tPRPpgTLwwvzesQd/0c2r+mKeeDObKB8h/lMqfC KjSb0w+KAeJTQE+YuYQ8FWktk0YzTLjRLjhoMlOCAUwuN5OoYJgG1dHKIoXLhy6Chd0Z4IsUf XLOzQh3mTu3vei0XB4NDa3DjX/JW8db0Ebv69+HFYOYWB4Z2enWFKaygNKjy1+npoHftFHe0T swJAXv8aFAKseBGQ X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 212.227.17.13 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:212279 Archived-At: This is a multi-part message in MIME format. --------------F72F2EB645512F9B2A31AC45 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 --------------F72F2EB645512F9B2A31AC45 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



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

--------------F72F2EB645512F9B2A31AC45--