From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gustaf Waldemarson Newsgroups: gmane.emacs.bugs Subject: bug#62696: python.el: Extra indentation for conditionals Date: Thu, 20 Apr 2023 15:40:04 +0200 Message-ID: References: <83zg7355f8.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000365dfc05f9c4ae95" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2436"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 62696@debbugs.gnu.org, kobarity , npostavs@users.sourceforge.net, gastove@gmail.com, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Apr 20 15:42:11 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1ppUY6-0000Rg-SI for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 20 Apr 2023 15:42:10 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ppUX3-0004XT-TF; Thu, 20 Apr 2023 09:41:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ppUX2-0004W8-1a for bug-gnu-emacs@gnu.org; Thu, 20 Apr 2023 09:41:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ppUX1-00060X-GW for bug-gnu-emacs@gnu.org; Thu, 20 Apr 2023 09:41:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ppUX0-0007bA-2b for bug-gnu-emacs@gnu.org; Thu, 20 Apr 2023 09:41:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gustaf Waldemarson Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Apr 2023 13:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62696 X-GNU-PR-Package: emacs Original-Received: via spool by 62696-submit@debbugs.gnu.org id=B62696.168199802429158 (code B ref 62696); Thu, 20 Apr 2023 13:41:02 +0000 Original-Received: (at 62696) by debbugs.gnu.org; 20 Apr 2023 13:40:24 +0000 Original-Received: from localhost ([127.0.0.1]:36850 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ppUWN-0007aB-Lc for submit@debbugs.gnu.org; Thu, 20 Apr 2023 09:40:24 -0400 Original-Received: from mail-yw1-f170.google.com ([209.85.128.170]:34320) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ppUWL-0007Zu-5b for 62696@debbugs.gnu.org; Thu, 20 Apr 2023 09:40:21 -0400 Original-Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-54fa9da5e5bso42460677b3.1 for <62696@debbugs.gnu.org>; Thu, 20 Apr 2023 06:40:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681998015; x=1684590015; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=j4p4Zje/XxXjeTxXgXDwIkYRF4FndGMR5No6oufbLsw=; b=OteEVPNhar4LWdmMkjzkNgL5rJSSNBvMI+bHi33N8W1Q0CskO06a9wO61N89NUNaH3 6cv9NxPAQag3zywOBAJ8B0JXwjXLnSUqnpZ95ya72F+XLJlOyM03BC7xH1CLoz+J4Qrq LXpC5VFjXhc998NMqHZUYXGQNtRIKRWVUf0IR6CoF5f2JaEcst3/BVvh3YyK+v2w08iQ 29vFfPYFmKoxDypdS6aNfv9PbOpz7/0MfI4DibhI+DkZdOeCxrH45qVLACvXcok6jyrN WccoRUCLSjFK9GNFHalO2hS/4dxKPOYHPgc8nsLdqExPQeMXbJQivUPD2ocWUtxZAObZ PTFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681998015; x=1684590015; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=j4p4Zje/XxXjeTxXgXDwIkYRF4FndGMR5No6oufbLsw=; b=j9k0rX/JYyGRlVHSVJLhv/P9neD6l5z/uydn4izkLDrP5GPdEdLF1zQ2Pmzp90QpTV swfgkhYN0YzycnOt1vdnL1wX5sWBJk/52sV1LsWvU/CWz9mGle0sKgBoRvUpvGHycYjV vAVJILrulOYMqv4Jf/AgskK6rbcZMNbwXna/8CNvgZ7m50IwESDkEHMWYuBWowZsrZsm qPeH8f2ShMoSMfKuE+HHswOmdbqnn9CrrRSzkfZmufg+tgYzfW5B05z9QT/UgcK6Xs9V QguOdeu+u1cfZIcPjIUC44ITYf8+gN9/AMcPZGnP0XLI1Z1Ci/+JuwicSTBduhBkq8Ur pfFg== X-Gm-Message-State: AAQBX9cW56Gs0zfmozOXoCygys7vA4Uq7ouUArSxeOD9eWiFvEk1Yce1 h5FjaAVM0I2+AgRVb2i3f/NJs2Z/KSieYTOdUJM= X-Google-Smtp-Source: AKy350bBxWhZmFlS2LBUYSTOAo4lsHaGixPuQ/6Yw1XTyhB5Jly+jdcricVRx/c2RX3vEhq4OuY3tUr6+ys9a6WCGaY= X-Received: by 2002:a81:4988:0:b0:54f:7971:4f75 with SMTP id w130-20020a814988000000b0054f79714f75mr873048ywa.22.1681998015256; Thu, 20 Apr 2023 06:40:15 -0700 (PDT) In-Reply-To: <83zg7355f8.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:260333 Archived-At: --000000000000365dfc05f9c4ae95 Content-Type: text/plain; charset="UTF-8" Apologies, I think Kobarity was waiting for a response from me and thus held these up: > I made a separate patch to update the docstring of > `python-indent-def-block-scale'. I think the name > `python-indent-def-block-scale' itself is a bit misleading, but I have > left it as is for compatibility. The following is my proposal of the > docstring. What do you think? It mostly looks good to me, but perhaps it would make sense to still output the closing paren on the same line as the first example? I suppose it might not make sense from a style-perspective, but I guess someone reading through this mostly care about comparing indentation depths > Do these two patches replace every other patch posted in this > discussion? > Are these two patches ready to be installed, or are you still > discussing the issue? I believe that's the case, but I would wait for a response from Kobarity following this. Best regards, Gustaf Den tors 20 apr. 2023 kl 10:22 skrev Eli Zaretskii : > > Cc: 62696@debbugs.gnu.org, Dmitry Gutov , > > Ross Donaldson , > > Noam Postavsky > > Date: Tue, 18 Apr 2023 23:23:35 +0900 > > From: kobarity > > > > Gustaf Waldemarson wrote: > > > I think that's a really good idea actually. It might also be a good > idea to add a > > > negative example (i.e., the black-indentation style you mentioned > earlier), or > > > a reference to one (maybe to the tests?) > > > > I think the best way is to update the docstring of > > `python-indent-def-block-scale'. So, I am also CC'ing this mail to > > the members of Bug#28475, where `python-indent-def-block-scale' was > > introduced. > > > > I made a separate patch to update the docstring of > > `python-indent-def-block-scale'. I think the name > > `python-indent-def-block-scale' itself is a bit misleading, but I have > > left it as is for compatibility. The following is my proposal of the > > docstring. What do you think? > > > > "Multiplier applied to indentation inside multi-line blocks. > > The indentation in parens in the block header will be the current > > indentation plus `python-indent-offset' multiplied by this > > variable. For example, the arguments are indented as follows if > > this variable is 1: > > > > def do_something( > > arg1, > > arg2 > > ): > > print('hello') > > > > if this variable is 2 (default): > > > > def do_something( > > arg1, > > arg2): > > print('hello') > > > > This variable has an effect on all blocks, not just def block. > > This variable only works if the opening paren is not followed by > > non-whitespace characters on the same line. Modify > > `python-indent-block-paren-deeper' to customize the case where > > non-whitespace characters follow the opening paren on the same > > line." > > Do these two patches replace every other patch posted in this > discussion? > > Are these two patches ready to be installed, or are you still > discussing the issue? > > Thanks. > --000000000000365dfc05f9c4ae95 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Apologies, I think Kobarity was waiting for a respons= e from me and
thus held these up:

&g= t; I made a separate patch to update the docstring of
> `python-indent-def-block-scale'.=C2=A0 I think the name
> `python-indent-def-block-scale' itself is a bit misleading, but I = have
> left it as is for compatibility.=C2=A0 The following is my proposal of= the
> docstring.=C2=A0 What do you think?

It mostly= looks good to me, but perhaps it would make sense to still output
the closing paren on the same line as the first example? I suppose it mig= ht
not make sense from a style-perspective, but I guess someone r= eading through
this mostly care about comparing indentation depth= s

> Do these two patches replace every othe= r patch posted in this
> discussion?

> Are these two patches ready to be installed, or are you still
> discussing the issue?

I believe that's th= e case, but I would wait for a response from Kobarity
followi= ng this.

Best regards,
Gustaf

= Den tors 20 apr. 2023 kl 10:22 skrev Eli Zaretskii <eliz@gnu.org>:
> Cc: 62696@debbugs.gnu.org, Dmitry Gutov <dgutov@yandex.ru>= ;,
>=C2=A0 Ross Donaldson <gastove@gmail.com>,
>=C2=A0 Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Tue, 18 Apr 2023 23:23:35 +0900
> From: kobarity <kobarity@gmail.com>
>
> Gustaf Waldemarson wrote:
> > I think that's a really good idea actually. It might also be = a good idea to add a
> > negative example (i.e., the black-indentation style you mentioned= earlier), or
> > a reference to one (maybe to the tests?)
>
> I think the best way is to update the docstring of
> `python-indent-def-block-scale'.=C2=A0 So, I am also CC'ing th= is mail to
> the members of Bug#28475, where `python-indent-def-block-scale' wa= s
> introduced.
>
> I made a separate patch to update the docstring of
> `python-indent-def-block-scale'.=C2=A0 I think the name
> `python-indent-def-block-scale' itself is a bit misleading, but I = have
> left it as is for compatibility.=C2=A0 The following is my proposal of= the
> docstring.=C2=A0 What do you think?
>
> "Multiplier applied to indentation inside multi-line blocks.
> The indentation in parens in the block header will be the current
> indentation plus `python-indent-offset' multiplied by this
> variable.=C2=A0 For example, the arguments are indented as follows if<= br> > this variable is 1:
>
>=C2=A0 =C2=A0 =C2=A0def do_something(
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0arg1,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0arg2
>=C2=A0 =C2=A0 =C2=A0):
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0print('hello')
>
> if this variable is 2 (default):
>
>=C2=A0 =C2=A0 =C2=A0def do_something(
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0arg1,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0arg2):
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0print('hello')
>
> This variable has an effect on all blocks, not just def block.
> This variable only works if the opening paren is not followed by
> non-whitespace characters on the same line.=C2=A0 Modify
> `python-indent-block-paren-deeper' to customize the case where
> non-whitespace characters follow the opening paren on the same
> line."

Do these two patches replace every other patch posted in this
discussion?

Are these two patches ready to be installed, or are you still
discussing the issue?

Thanks.
--000000000000365dfc05f9c4ae95--