From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Oleh Krehel Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] emacs-25 b6d6304: Comment on last change to define-derived-mode Date: Mon, 07 Mar 2016 16:26:00 +0100 Message-ID: <874mcicnsn.fsf@oremacs.com> References: <87wppgax5o.fsf@oremacs.com> <874mciekrq.fsf@oremacs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1457364387 17523 80.91.229.3 (7 Mar 2016 15:26:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 7 Mar 2016 15:26:27 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 07 16:26:18 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1acx32-00030J-AS for ged-emacs-devel@m.gmane.org; Mon, 07 Mar 2016 16:26:16 +0100 Original-Received: from localhost ([::1]:56433 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1acx31-0005HS-LZ for ged-emacs-devel@m.gmane.org; Mon, 07 Mar 2016 10:26:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36994) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1acx2t-0005GI-QB for emacs-devel@gnu.org; Mon, 07 Mar 2016 10:26:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1acx2n-0007Tn-QB for emacs-devel@gnu.org; Mon, 07 Mar 2016 10:26:07 -0500 Original-Received: from mail-wm0-f45.google.com ([74.125.82.45]:34618) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1acx2n-0007Te-Jt for emacs-devel@gnu.org; Mon, 07 Mar 2016 10:26:01 -0500 Original-Received: by mail-wm0-f45.google.com with SMTP id p65so112913876wmp.1 for ; Mon, 07 Mar 2016 07:26:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=/uKYlH5A0kB+H60DFqV9Mmgq3AeB/60mwC7cbgp4CZI=; b=YeT6A0KbHdTyMV3yg9wNX03EXZ6NzhT+ZW/7NWRaI9LwPahALz6ZzQbvMxDASUW7Vy vtbJqo3loZW1+LuQNV4M7xNie8UkqAgAKPW8cJSYM5fkkl5rBdoAh0tLyVkx9nDsFGyd cW/C+qg84DsTWgnvXEY37wPUgl/vSdHH+y3+CZujbIEmjy/eHhDRGV/7IFjfkSTD2POD iSfh/2Qsy/98ymQ+Rqjf+LEpwveURJjLAO9LT7wT7Bnqrk+egEuROtfCVfu6OVsbXlP/ mQPlnmpQaOp6Q1BUkT2Vg0Y4mbfLqoD80pW15a8nyDvflVEJPlf+Ciqo1TRal/3krkMj 9R5g== X-Gm-Message-State: AD7BkJJVC8UHxLCavxZcMHB6AITT3PZs46Q10k9MW1QOD+zkgB/RfD6yBfOfudPDQOMyEA== X-Received: by 10.194.7.201 with SMTP id l9mr23471223wja.16.1457364360899; Mon, 07 Mar 2016 07:26:00 -0800 (PST) Original-Received: from firefly ([91.219.111.102]) by smtp.gmail.com with ESMTPSA id lz5sm18461718wjb.5.2016.03.07.07.25.59 for (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 07 Mar 2016 07:25:59 -0800 (PST) In-Reply-To: (John Wiegley's message of "Mon, 07 Mar 2016 06:51:44 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 74.125.82.45 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:201041 Archived-At: John Wiegley writes: >>>>>> Oleh Krehel writes: > >> So I've added an indentation hint that 94% of the code already follows, >> while 6% doesn't. It's up to you as the maintainer to decide if we want to >> have a 94/6 split just to not ruffle any feathers. Or we want to enforce a >> rule to make all code uniform - easier to read and contribute to. > > If we're formalizing what 94% of our code already does, that can helpful for > setting expected standards. However, that's 94% of our code, not 94% of > everything that's out there. Like I said, it's up to you to decide what to do. You've already shown favor to the testing and bug-squashing directions for the Emacs development. In my opinion, the coding style could be another useful direction. By this I mean: - Removing the ambiguity about `indent-tabs-mode'. - Working on something like `pretty-print-buffer': a command to automatically eliminate hanging parens, consecutive spaces, multi-variable `setq'; and re-indent everything. - Extending the checkdoc to find more warnings in the code style, like unresolved declarations etc. - Formalizing the C code style, tutorials, contribution guidelines etc. Maybe we could have a linter for C. I think it would be great if at some moment we could stop thinking how a code looks, and only think about what it does. And ignoring how it looks isn't really a great solution - it may work for some, doesn't work for me at the moment.