From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: adding to emacs coding standard / formatting Date: Mon, 19 Oct 2020 10:24:49 -0400 Message-ID: References: <20201019031002.iulr45ztrkwsiqlo@E15-2016.optimum.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5495"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Emacs-Devel List To: Boruch Baum Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 19 16:28:36 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kUW9L-0001GU-Vj for ged-emacs-devel@m.gmane-mx.org; Mon, 19 Oct 2020 16:28:35 +0200 Original-Received: from localhost ([::1]:35318 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kUW9K-0006Ti-VF for ged-emacs-devel@m.gmane-mx.org; Mon, 19 Oct 2020 10:28:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57440) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kUW5o-0002yP-Bz for emacs-devel@gnu.org; Mon, 19 Oct 2020 10:24:56 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:50100) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kUW5l-0004TY-Gy for emacs-devel@gnu.org; Mon, 19 Oct 2020 10:24:55 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id E2BB010022A; Mon, 19 Oct 2020 10:24:51 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 6819910001F; Mon, 19 Oct 2020 10:24:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1603117490; bh=PkUxS2sIHzDREsDHycJelNcxhGd1X1TtxHzay14FWqI=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=D7vh+cTVD3dNcRrPERytg5NcNi2qGe3mEz3LAd+YfKbmbeseRrT3nP0PJ26BKFmv0 XL1ZJXpjg5JjKvFcfuKLjUXHIyoag5FtL0xHRGBz/TpntfkWc45m3FN49C6xFSWEww DdhHBX0L8EUqmz5uX3XL49skjdDYrSbtEK4nm73ghYVLuwGhlaTYq0z/51oz9AirHF LPhvbHGEg033W9Cx2zYDNxhDNb8y5ZKl5DcnPuyL7/n7+Wo3P3q0HgFNGZU6G7ao48 +GzTQDlZ0Aaegt7XOd5ulvdawpbHd2TvJO5P5D1UKaRCPhH2BbtMPWnCG5QfXdLDuo TuaeKoYCCvruQ== Original-Received: from alfajor (unknown [157.52.9.240]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 45D411202FF; Mon, 19 Oct 2020 10:24:50 -0400 (EDT) In-Reply-To: <20201019031002.iulr45ztrkwsiqlo@E15-2016.optimum.net> (Boruch Baum's message of "Sun, 18 Oct 2020 23:10:02 -0400") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/19 10:05:03 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:258116 Archived-At: > That isn't the case in package time.el, so that's probably also the case > in other packages. Should doing so be added to the coding standard? While this can work well for some files, I think it would work poorly for others, so I'd rather not require this specific standard (and I expect it will be difficult to get enough agreement on any specific proposal anyway). But I'd be in favor of encouraging such structure, e.g. by "leading by example", or by having `C-h P` give better result for packages which do follow such a structure, or by providing good templates (hooked into the auto-insert system), ... Maybe we can also mention the importance of such a structure *in general*, without recommending any one particular structure but just showing a few good examples. > Also, this is an opportunity to address a pet peeve: I occasionally see > code either defining keybindings to lambda functions, or setting lambda > functions as elements of function lists (eg. lists of hook functions). > I'd like to propose that those uses be banned because of their > difficulty to modify. I think I mostly agree, but as always there will be exceptions where using a symbol is impossible or wouldn't help (typically because the function really can't be predefined once and for all). Maybe you could start by adding compiler warnings for those, and then submit patches that address the easy-to-fix cases. Stefan