From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Jordon Biondo Newsgroups: gmane.emacs.devel Subject: Re: Revisiting `setq-local`s signature Date: Tue, 31 Jan 2017 14:13:59 -0500 Message-ID: References: <97d4f384-5126-4fc4-8902-0bdb59fa5ae4@default> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c1cd7a0fbca41054768bb10 X-Trace: blaine.gmane.org 1485891370 4101 195.159.176.226 (31 Jan 2017 19:36:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 31 Jan 2017 19:36:10 +0000 (UTC) Cc: Philipp Stephani , Emacs development discussions To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 31 20:36:05 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 1cYeDl-0000qM-GA for ged-emacs-devel@m.gmane.org; Tue, 31 Jan 2017 20:36:05 +0100 Original-Received: from localhost ([::1]:40766 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cYeDr-0007Ld-2z for ged-emacs-devel@m.gmane.org; Tue, 31 Jan 2017 14:36:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39261) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cYdsQ-00043t-QO for emacs-devel@gnu.org; Tue, 31 Jan 2017 14:14:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cYdsP-00021c-HZ for emacs-devel@gnu.org; Tue, 31 Jan 2017 14:14:02 -0500 Original-Received: from mail-lf0-x234.google.com ([2a00:1450:4010:c07::234]:33827) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cYdsP-00020K-6G for emacs-devel@gnu.org; Tue, 31 Jan 2017 14:14:01 -0500 Original-Received: by mail-lf0-x234.google.com with SMTP id v186so216765847lfa.1 for ; Tue, 31 Jan 2017 11:14:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XQIWDRwsZWxwevlu4ZUyqfXZNyHlvwDv4PlE0018kQM=; b=TSg9qkHW2Wpnd0qMkdN0Bqho2juxwO6vM4AnVt4YBJX4p13mg2n30Ej3pmx21rjkxV 9loQ92kuH8w7YWA3Gyc8sPDg8luxGORoIiWw6uw82kVJQ0xhL0bqjR9DCR++zO2R9obA Hqn7c0iwcmcY/V3ElaESIoAVx5L7k6qKVY2ghfMBSQrRodxEHOaaWS1o7lbWQ4xHXzRb HuvQn3k/XdsPwNrHvjMrSDeD5mv5/0oUSpPKoqyyplTfjiWD7u7ehRbQQbhJ4whxfT9t 4eOge1T9WQXAu7HJk4jVu0+iDlOfMJPtsy+KhZZOLV/X1eMVh2TF6/6dBxb32vpsmKl1 jN7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XQIWDRwsZWxwevlu4ZUyqfXZNyHlvwDv4PlE0018kQM=; b=Tv/FJCd+zRMVRFlIy2fWArWP6wccGzWIbZZu2JABdwavwMj9NJfLSr4d7pQ+dzx9jD I/9UKePuDF/eTMeVS8VE8YyBF9Q26UWWbIqeInaeJhy24wuQsGuC840q8B9rMfQFy61g M8dGrxHemUbXYZZPIvTK61YCHkuJqY9qvrddpR1IkZ6RpQxdaPnqdl07oKmrCSFlKvXQ 6rClM+Aw3Jh5y5SSfn99YogHfOsISi5THggN0B45u7XEoQ4xd9xXZDjQh3OVT7glAHOy HGGVQ6wE6YHIQdb+WknzHqGuWoDv9ml3TYpGLgQxPfX093u8u7t4XwUiZa5w3Uj2MMvS +pDw== X-Gm-Message-State: AIkVDXL1eUJczW4uzxM/YPunSuaEej9u3efiAjGBG1LuuEmATg0NQbVFZJNq+8zIPkx0nWka+SnuNf5kisRHfw== X-Received: by 10.25.145.4 with SMTP id t4mr9319774lfd.171.1485890039562; Tue, 31 Jan 2017 11:13:59 -0800 (PST) Original-Received: by 10.25.19.193 with HTTP; Tue, 31 Jan 2017 11:13:59 -0800 (PST) In-Reply-To: <97d4f384-5126-4fc4-8902-0bdb59fa5ae4@default> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c07::234 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:211816 Archived-At: --94eb2c1cd7a0fbca41054768bb10 Content-Type: text/plain; charset=UTF-8 > > As a user, I'm still opposed to this change. I don't think consistency is > important enough in this case to justify the "worse" signature. Consistency > is not a goal in itself, but should serve the goal to increase readability > and lower the barriers for new contributors. I don't think that the simpler > signature of setq-local is in any way confusing because of this > inconsistency. FWIW the reason I am bringing this up again is that I watched as a coworker, and new emacser, struggled with the inconstantly while I helped them setup their config with a new major mode. I explained the issue and that I'd try to fix it before which is when they brought up the "better to be consistently wrong" idea which I thought made a good case. On Tue, Jan 31, 2017 at 1:57 PM, Drew Adams wrote: > > As a user, I'm still opposed to this change. I don't think > > consistency is important enough in this case to justify the > > "worse" signature. > > You don't say what is "worse" about it. > > > Consistency is not a goal in itself, but should serve the > > goal to increase readability and lower the barriers for new > > contributors. > > Yes, consistency is not a goal in itself. But you do not say > how the suggested inconsistency here increases readability or > lowers the barriers for new contributors. > > > I don't think that the simpler signature of setq-local is in > > any way confusing because of this inconsistency. > > How is it simpler? What _prevents_ a user from setting only > a single variable value each time s?he uses `setq-local'? > > Additional assignments would be optional. In fact, even the > first assignment would be optional, if we follow the `setq' > model. > > Is your statement about readability based on your feeling > that the first of these two sexps is more readable than the > second? If so, there are at least some people who don't feel > that way. > > (progn > (setq-local foo 1) > (setq-local bar 2) > (setq-local fot 8) > (setq-local tof 3) > (setq-local baz 2) > (setq-local zab 4) > (setq-local flt 6)) > > (setq-local foo 1 > bar 2 > fot 8 > tof 3 > baz 2 > zab 4 > flt 6) > > I don't see an argument that points to a downside to _allowing_ > a variable number of assignments. > --94eb2c1cd7a0fbca41054768bb10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As a user, I'm still opposed to this change. I= don't think consistency is important enough in this case to justify th= e "worse" signature. Consistency is not a goal in itself, but sho= uld serve the goal to increase readability and lower the barriers for new c= ontributors. I don't think that the simpler signature of setq-local is = in any way confusing because of this inconsistency.

FWIW the reason I am bringing this up again is that I watch= ed as a coworker, and new emacser, struggled with the inconstantly while I = helped them setup their config with a new major mode. I explained the issue= and that I'd try to fix it before which is when they brought up the &q= uot;better to be consistently wrong" idea which I thought made a good = case.=C2=A0

On Tue, Jan 31, 2017 at 1:57 PM, Drew Adams <drew.adams@oracle.c= om> wrote:
> As a user, I'm still opposed to this change. I don't think > consistency is important enough in this case to justify the
> "worse" signature.

You don't say what is "worse" about it.

> Consistency is not a goal in itself, but should serve the
> goal to increase readability and lower the barriers for new
> contributors.

Yes, consistency is not a goal in itself.=C2=A0 But you do not say how the suggested inconsistency here increases readability or
lowers the barriers for new contributors.

> I don't think that the simpler signature of setq-local is in
> any way confusing because of this inconsistency.

How is it simpler?=C2=A0 What _prevents_ a user from setting only a single variable value each time s?he uses `setq-local'?

Additional assignments would be optional.=C2=A0 In fact, even the
first assignment would be optional, if we follow the `setq'
model.

Is your statement about readability based on your feeling
that the first of these two sexps is more readable than the
second?=C2=A0 If so, there are at least some people who don't feel
that way.

(progn
=C2=A0(setq-local foo 1)
=C2=A0(setq-local bar 2)
=C2=A0(setq-local fot 8)
=C2=A0(setq-local tof 3)
=C2=A0(setq-local baz 2)
=C2=A0(setq-local zab 4)
=C2=A0(setq-local flt 6))

(setq-local foo 1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bar 2
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 fot 8
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 tof 3
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 baz 2
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 zab 4
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 flt 6)

I don't see an argument that points to a downside to _allowing_
a variable number of assignments.

--94eb2c1cd7a0fbca41054768bb10--